What the Customer Director
Actually Does.

We wrote a post a while back about why everyone at Sealution holds the title director. The short version: each director owns a distinct part of how the platform actually behaves, not a department, not a headcount. If you have not read it, it is here.

This post is about one of those four directions specifically: Market and Numbers, which is what we call the Customer Director's territory. It is worth explaining on its own because it is the hardest one to summarise in a title, and the one most likely to be misread.

What this role is not

It is not a support function. There is no ticket queue to manage, no SLA clock running in the background, no escalation matrix. When a client has a question about the platform, they call someone who knows the answer, usually the person who built that part of the system. That is true for every director, not just this one.

It is not sales in the traditional sense either. There is no pipeline to manage, no targets to hit by the end of the quarter, no deck to walk a prospect through. SEALUTION does not sell that way. Every conversation with a potential client starts with the same question: tell us how you actually operate. The demo follows from that, not the other way around.

And it is not a product manager role, at least not the kind that sits in sprint planning and writes acceptance criteria. What gets built at Sealution gets built because someone identified a real, recurring problem in how maritime operators run their businesses, not because a roadmap spreadsheet said it was next.

What it actually is

The Customer Director's job is to stay close enough to real operators that the gap between how they describe their problems and how the platform solves them stays as small as possible.

Maritime operators do not usually walk in asking for a feature by its technical description. They describe a headache. A freight forwarder says their client keeps calling to ask where the cargo is, and nobody has a good answer. A fleet manager says their invoicing is always late because finance does not find out a voyage has sailed until after the fact. A shipping company says their corporate clients book completely differently from their retail clients and they cannot handle both in the same system.

None of those are feature requests. They are operational problems with software implications. The Customer Director's job is to hear the problem clearly enough to know what the software implication actually is, and to make sure the team is building the right thing in response to it, not the nearest thing that sounds right.

Operators describe a headache. The job is recognising what is actually causing it, before the market has a name for the fix yet.

Why this matters in maritime specifically

Maritime operations are not a homogeneous market. A ten-vessel inter-island carrier in Eastern Indonesia runs their business very differently from a freight forwarder in Batam who handles corporate container bookings. Both of them use ships. Almost nothing else about how they work is the same.

Generic software handles this by building for the middle. It covers the cases that apply to the largest number of operators and treats everything else as a customisation someone else will have to figure out. That is a reasonable approach for a product built to serve thousands of different industries. It is a poor approach for software built specifically for maritime operations, where the variation between operators is real and significant and the cost of a bad fit is not a workflow inconvenience but a disruption to an actual sailing schedule.

SEALUTION is configurable at the level that actually matters: ports, routes, rates, currencies, tax rules, document templates, booking flows, and role permissions. The Customer Director's job is understanding which of those configurations a given operator actually needs, and making sure the platform can handle it before the installation, not after.

The numbers side

Market and Numbers is the full description of this direction, and the numbers half is worth addressing directly. Pricing, currencies, and tax rules are not glamorous parts of a maritime software platform. They are also the parts that break an operator's confidence in the system the fastest if they are wrong.

A quotation that comes out in the wrong currency is not a minor display issue. It is a document that goes to a client, reflects on the operator's professionalism, and potentially creates a contractual problem. A tax calculation that does not match local rules is not a rounding error. It is a compliance exposure.

Getting those things right requires knowing how different markets actually work, not in the abstract, but in the specific. Different tax regimes, different invoicing conventions, different expectations about what a bill of lading should contain and in what order. The Customer Director holds that knowledge and makes sure it is reflected in how the platform behaves for each operator's configuration.

What changes when you have this function

The honest answer is that the platform reflects what real operators actually need rather than what a development team imagined they might need from a distance.

One concrete example: a corporate booking flow now ships with every SEALUTION installation. It was not on the original roadmap. It came directly from one client whose corporate customers booked freight in a way that did not fit the standard flow at all. That problem got heard, translated into a platform requirement, and built. And because the underlying problem was not unique to that one client, it turned out to be useful for operators across the board.

That is what the Customer Director function produces at its best: features that arrived because someone was listening carefully to what operators were struggling with, not features that arrived because they were interesting to build.

The part that does not change

The platform suggests. The captain decides, always. That is true for routing, and it is equally true for everything the Customer Director's work touches. Better information, better configuration, a system that fits the way an operator actually works. What the operator does with that is still entirely theirs.

Getting the fit right is the whole point of having someone whose direction is explicitly the market and the numbers, rather than assuming the engineering will figure it out on its own.