Client
A UK trust port authority managing commercial berths, pilotage and vessel traffic services for a mixed cargo and bulk freight harbour
Sector
Transport & Infrastructure
Engagement
Consolidated berth and vessel scheduling platform linking vessel traffic services, pilotage booking and customs pre-lodgement status, plus a shared planning view for the harbour master's office and terminal operators - multi-quarter programme.
What the client needed
A vessel's turnaround at berth depends on three things lining up: a pilot being booked to bring it in, a berth actually being free when it arrives, and its cargo being cleared to move once it's alongside. At our client's harbour, each of those sat with a different team running a different system. Pilotage bookings were confirmed by phone and logged in a scheduling spreadsheet the harbour master's office maintained by hand. Berth occupancy was tracked by the terminal operators themselves, each on their own booking sheet, with no shared view back to the harbour master. Customs pre-lodgement status - whether HMRC had cleared a cargo manifest to move once alongside - sat in a separate portal that nobody outside the agent handling that particular vessel routinely checked. A vessel could arrive on schedule, with its pilot booked and its berth notionally free, and still sit waiting at anchor for hours because nobody had confirmed the customs status until the agent got round to a phone call. The port's own harbour dues data showed the pattern repeating vessel after vessel, and it wasn't any single team's fault - it was that the fix needed all three of them looking at the same facts at the same time, which no system currently gave them.
How we worked
- Built a live berth occupancy view fed directly from terminal operators' own booking systems, replacing the harbour master's manual cross-checking of separate sheets.
- Integrated pilotage booking status into the same view, so a confirmed booking, a delay, or a cancellation surfaced automatically rather than requiring a phone call to find out.
- Connected to HMRC's customs pre-lodgement status via the agents' existing declarations, giving the harbour master and terminal operators a shared, real-time read on whether a vessel's cargo was actually cleared to move.
- Designed a single planning screen that put pilotage, berth and customs status side by side against tide windows, so a vessel wasn't scheduled to arrive against a berth or clearance status that wasn't genuinely ready.
- Ran the platform alongside the existing phone-and-spreadsheet process for a full quarter before cutover, comparing its status view against what the harbour master's office confirmed manually.
- Trained terminal operator staff and duty pilots directly on the shared view, since the tool only closes the gap if every party is checking the same screen rather than their own separate record.
Measured results
All figures verified with the client. Specific berth, vessel and customer detail withheld in line with our standard confidentiality terms.
- Average vessel waiting time at anchor for a confirmed berth fell from most of a tide cycle to under two hours for vessels tracked through the new planning view.
- Customs pre-lodgement status is now visible to the harbour master and terminal operators directly, rather than depending on an agent's phone call to surface a hold.
- Terminal operators report a marked drop in berth double-booking incidents, since occupancy is now confirmed against one shared view rather than three separate sheets.
- The trial quarter surfaced a recurring gap where pilotage cancellations weren't reliably reaching the terminal operators at all under the old process, since corrected in the shared view's alerting.
- The harbour master's office is now extending the same planning view to smaller commercial berths beyond the original programme scope.
"We used to find out a vessel was stuck the same way everyone else did, when someone rang to ask why. Now the three things that have to line up are on one screen before the vessel's even in the estuary, not discovered one phone call at a time after it's already waiting."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
A trust port authority occupies a coordinating role rather than an operational monopoly: the harbour master's office controls the water and the tide windows, but berths, cargo handling and customs declarations are each run by separate commercial parties with their own systems and their own priorities. That structure meant this was never going to be a single system replacing three others, since none of the three owning parties was going to give up their own booking tool for a harbour authority's dashboard. The brief that shaped the whole programme was to build a shared view fed by each party's existing system rather than a replacement for any of them, which meant the integration work, not the interface, was where almost all of the real engineering effort went.
The customs integration in particular took longer than the berth and pilotage feeds combined, because pre-lodgement status wasn't something any single system exposed cleanly - it existed as a status an agent could see inside their own HMRC-facing tooling, not as a feed built for a third party like a port authority to consume. We worked with the agents handling the harbour's regular cargo traffic to get consistent, timely visibility into that status rather than trying to build a direct customs integration that wasn't realistically available to us, which meant the solution's reliability depended on agent cooperation as much as on the technology - a dependency we made explicit to the client rather than a detail buried in an architecture diagram.
Building a shared view three separate organisations would actually trust
The harder problem wasn't technical, it was that terminal operators, pilots and the harbour master's office had no history of working from one shared source of truth, and a new screen showing berth status doesn't earn trust just by existing. We ran the platform in parallel with the existing phone-and-spreadsheet process for a full quarter, comparing what the shared view showed against what each party confirmed manually, before asking anyone to plan a vessel's arrival against it alone. That parallel period surfaced a gap nobody had previously had reason to notice: pilotage cancellations were being logged in the harbour master's own scheduling spreadsheet but weren't reliably reaching terminal operators at all, who'd sometimes only find out a pilot booking had fallen through when the vessel failed to appear on schedule. That's now built directly into the shared view's alerting.
Designing for tide windows, not just for status
A berth being nominally free and a vessel being nominally clear to move both matter less than whether both facts are true inside the same tide window, since a harbour's usable arrival and departure times are constrained by water depth in a way office-hours scheduling isn't. The planning screen was built around tide windows as the organising unit from the outset, showing pilotage, berth and customs status against the specific window a vessel needed rather than as three separate always-on statuses a planner had to mentally line up themselves. That reframing, more than any single integration, is what let the harbour master's office plan proactively rather than reactively.
Lessons learned
The first lesson was that a shared view across three independently-run organisations only earns trust once it's been checked against the old manual process side by side, not the day it goes live - the parallel quarter cost time but is the reason cutover didn't produce a wave of disputed status calls.
The second lesson was that the hardest integration is rarely the one with the clearest technical interface - the customs pre-lodgement feed depended on agent cooperation more than on any system boundary, and treating that dependency as a design constraint from the start avoided building something that looked complete but wasn't operationally reliable.
The third lesson was that organising a planning tool around the physical constraint that actually governs the operation, in this case the tide window, produces a genuinely more useful view than simply digitising each party's existing status separately.
If your organisation is coordinating time-critical decisions across several independently-run parties who each hold one piece of the picture, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.