Industries

Terminals, ports and container logistics

Offerings and example engagements for Terminals, ports and container logistics — not published client case studies.

Why · How · What

Why

In this sector the message is the cargo. A box that physically exists but whose EDI message failed is, commercially, a box that does not exist — and a returnable asset nobody can locate is working capital that has quietly left the business.

How

Reconcile the message record against the physical record continuously, and design for the exception, because here the exception is the operation.

What

EDIFACT and API interchange, TOS integration, gate and yard data, returnable asset tracking and pooling, billing and revenue assurance, visibility, platform operations.

Scopes of work

Example engagement — illustrative. Typical scopes of work, not named client case studies.

The message record and the physical record diverge

Why it happens: BAPLIE, COPRAR, CODECO and COARRI exchanges pass between carrier, terminal operating system and port community system, each of which was integrated bilaterally and none of which reconciles to the others. Failures are intermittent rather than total, so they never trigger an outage — they surface at the gate, an hour of phone calls at a time.
How we work it: Functional acknowledgements go in at every hop with a correlation ID carried from booking through to gate event. TOS positions are reconciled against EDI stow and discharge lists on a schedule, an operational tracker answers “where is this container in every system” from one query, and operations is alerted on divergence rather than waiting for the physical mismatch.
What you end up with: A single cross-system container view with scheduled reconciliation and divergence alerted ahead of the gate.

Capabilities engaged B2B and EDI · middleware and integration · observability

A returnable asset fleet you cannot locate

Why it happens: The pool is tracked through customer declarations, scan events and depot counts that were never designed to agree, and each is incomplete in a different way. Loss rate, utilisation and cycle time end up estimated rather than measured, and significant working capital is committed on the estimate.
How we work it: We build a single asset event history from scans, declarations, depot movements and telemetry where it exists, define the asset lifecycle states explicitly, and infer transitions from events rather than from what customers declare. Cycle time, dwell by location and loss rate by customer and lane become measurable, the points in the cycle where assets actually disappear become visible, and per-customer utilisation goes to the commercial team.
What you end up with: Measured cycle time and loss rate by customer and lane, replacing estimates, with the loss points located rather than aggregated.

Capabilities engaged data engineering · data science · middleware and integration

Billing that leaks

Why it happens: Storage, demurrage, detention, handling and accessorial charges are derived from operational events spread across several systems, and the charging logic accumulated tariff by tariff. Leakage is suspected because everyone in the industry has it, but nobody has quantified their own.
How we work it: We rebuild the charge calculation independently from raw operational events and compare it against what was actually billed, classifying differences by charge type, customer and cause — missed event, tariff misapplication, waiver, timing. Annual leakage is quantified by category, the highest-value causes are fixed at source rather than disputed at the invoice, and the comparison is automated as an ongoing control.
What you end up with: Quantified leakage by charge type and cause, the top causes fixed at source, and an automated revenue assurance check.

Capabilities engaged data engineering · ERP · middleware and integration · data quality audit

Onboarding a partner takes months

Why it happens: Every shipping line, customer and depot has its own message variant, and each was implemented as a bespoke project because there was never a canonical internal model to map to. The variation is real; the cost is that it reaches all the way into the core rather than stopping at the edge.
How we work it: We standardise on a canonical internal document model with partner-specific maps at the edge, and build a reusable onboarding kit with test harness, sample data and a certification checklist. Partner communications and test plans are templated, and an API is published alongside EDI for partners who want it, over the same business logic rather than a second implementation.
What you end up with: A repeatable onboarding path with a stated typical duration, variation isolated at the edge, and one business logic path serving both protocols.

Capabilities engaged B2B and EDI · Dell Boomi · middleware and integration

Operational metrics nobody can compare

Why it happens: Each terminal or depot defined truck turnaround, crane productivity and yard utilisation locally, usually years ago and usually sensibly for its own layout. Rolled up to group level the numbers look comparable and are not, so improvement cannot be prioritised and sites reasonably dispute their ranking.
How we work it: We compare the current definitions site by site and surface exactly where they diverge, then agree a common taxonomy with the sites rather than imposing one. Capture is automated from TOS and gate systems rather than entered by hand, and drill-down from the group figure to the individual move is preserved so a site can interrogate its own number.
What you end up with: A common taxonomy the sites have signed, automated capture, and every group figure traceable to individual moves.

Capabilities engaged data engineering · observability · data science

Round-the-clock operations, office-hours support

Why it happens: The terminal never stops but the platform team was sized against a corporate IT model in one timezone. Overnight incidents get handled by whoever answers, which works until it doesn’t, and the same failures recur because nobody owns the investigation.
How we work it: We assess the estate and document runbooks per service before accepting any coverage, then define coverage tiers against actual incident patterns rather than a generic SLA. Named on-call engineers get a written authority boundary describing what may be done without escalation. Recurrence is instrumented, structured RCA runs on repeat classes, and monthly reporting carries the evidence.
What you end up with: Coverage matched to operating hours with named on-call, a written authority boundary, and recurrence reported as the measure of whether fixes worked.

Capabilities engaged cloud managed services · observability · DevOps and platform engineering

Questions we ask in a first conversation

When a container’s EDI record and TOS position disagree, who finds out first and how?
Is your asset loss rate measured or inferred?
How long does onboarding a new shipping line take end to end?
Do two terminals define truck turnaround the same way?
What happens at 3am when the gate system stops?

Start with clarity.

What would make your business easier to run?

Tell us the operational challenge. We will discuss whether a short conversation, a scoped assessment or a delivery engagement is the right next step.

Discuss your business challenge