Somewhere in most software implementations there is a meeting where the agency is told, politely, that it is working incorrectly.
Not in those words. It arrives as a best practice, a standard workflow, a recommended process. The message underneath is the same: the system knows how this should be done, and the way you do it now is an obstacle to be managed.
We think that is the wrong way round, and it is worth saying plainly because so much of this market is sold the other way.
Your process is not arbitrary
A port agency's way of working is not a preference someone picked. It is the accumulated result of the port it works in, the principals it serves, the suppliers who answer the phone at three in the morning, and the people it employs.
You order the launch before the pilot is confirmed because in your port that is the sequence that works. You keep two tariffs for the same crane because one customer settled on a rate three years ago and has earned it. You check the crew list twice because of the time you did not. None of that is in a manual. It is the difference between an agency that gets the call handled and one that gets it handled again.
Software that standardises those things away is not removing inefficiency. It is removing information.
What happens when the system wins
The process does not actually change. It moves.
The exceptions become workarounds, the workarounds move into a spreadsheet beside the system, and within a year the spreadsheet is where the real work lives. The system holds a tidy version of events, and the person who knows how the two relate is one specific colleague. That is not one system, it is two, and the second one is undocumented.
Then someone concludes that digitising the operation did not work, when what did not work was being asked to describe the operation in somebody else's vocabulary.
What fits looks like in practice
Take the port call file: the record of one vessel's visit, with orders, documents, costs and messages hanging off it. For a port agency it is where everything starts, and it is usually the first thing we set up.
A terminal does not necessarily have one at all. The vessel comes to them; what they need is a berth, a schedule, staff and equipment against a clock, and a great many billable service lines per call. A boatmen company needs something different again, because their scarce resource is people and boats, not documents.
Same platform, three shapes. Not three products, and not three custom builds: the objects and workflows are configured out of the same generic parts. That is what "made to fit" is supposed to mean, and it is a description of how the software is built rather than a promise about how accommodating we are.
And the honest limit
There is one, and a position piece that leaves it out is just advertising.
We do not write one-off code for a single customer's request unless the change is generically useful — worth having on the platform, and therefore useful to other customers too. Configuration goes deep; private forks do not exist.
That is a real boundary, and it is the reason the price stays at subscription level rather than project level. It also means every improvement anyone asks for arrives for everyone, in the subscription, instead of as a quote. If what you need is genuinely yours alone and cannot live in a shared platform, we will tell you that in the first conversation rather than the third month.
Three questions worth asking any vendor
Whoever you are talking to, including us:
- Show me a setup for a company that does something different from mine. If every customer's screen looks the same, that is the answer.
- What happens when our process does not match yours? Listen for whether the answer is configuration or persuasion.
- What do you say no to? A vendor who says yes to everything is either about to bill you for it or about to disappoint you.
If you would like to see what a setup shaped around your operation looks like rather than around ours, ask for a demo and bring your most awkward port call.