Ocean visibility for freight forwarders: milestone tracking that actually works at container level
Freight forwarders running ocean volumes on Shipsy get container-level milestone visibility normalized across 100+ carriers, vessel AIS feeds, and terminal events — with Astra flagging deviations against the promised schedule before the customer notices. The unlock is not a nicer dashboard. It is the ability to act on drift while there is still time to act.
The finding
Ocean visibility is still the single worst-performing data layer in freight forwarding. Carrier portals report at vessel-event granularity — gate-in, loaded, departed, arrived, gate-out — on inconsistent lag, in inconsistent formats, for inconsistent subsets of the booked containers. Forwarders stitch this manually for top customers and leave the rest blind. Shipsy aggregate data across global forwarders shows the typical container has six to twelve tracked milestones if you rely on a single carrier feed, versus eighteen to twenty-four when you blend carrier API, EDI, terminal feeds, and vessel AIS into one normalized timeline. That density difference is the gap between reactive and proactive ops.
Why it’s happening
Three mechanics drive the gap, and they need to be solved together rather than one at a time.
1. Carrier API coverage is fragmented. Major carriers publish milestone APIs but with different schemas, different latency, and different completeness. Mid-tier and regional carriers often only expose tracking via web portals. Shipsy normalizes 100+ carriers into one schema — API first, EDI fallback, screen-scrape as a last resort — so the forwarder’s ops team sees the same timeline regardless of who carries the box.
2. Vessel-level data is decoupled from container-level status. AIS feeds tell you where the vessel is; they don’t tell you what is on it. Shipsy binds vessel position to the container’s booked voyage leg, so when a vessel is slow-steaming or diverts, every container on it gets a re-estimated ETA automatically.
3. Terminal events rarely make it to the forwarder. Gate-in, discharge, and stripping events live in port community systems. Shipsy ingests these where available and infers them where they are not, closing the visibility gap at the most exception-heavy part of the journey.
Stitched together, the forwarder stops asking “where is my container?” and starts asking “which containers are drifting enough to hurt the customer?” That is the question Astra answers autonomously.
What it means for ocean forwarders
The operating model splits cleanly.
Reactive forwarders learn about problems when the customer calls. Their ops teams spend most of the day on status queries instead of exception handling. Their NPS scores track carrier service, not forwarder service.
Proactive forwarders detect drift early and notify the consignee before the consignee asks. Clara handles the routine status queries autonomously — tracking updates, document requests, ETA confirmations — freeing ops to work the exceptions that actually need human judgment. The operational signature of a proactive forwarder is that the customer portal gets more views than the phone line.
| Ocean visibility capability | Traditional FF approach | AI-native approach (Shipsy) |
|---|---|---|
| Carrier milestone ingestion | Manual portal checks, 1-2x/day | 100+ carriers normalized, near-real-time |
| Vessel position tracking | Not tracked or separate tool | AIS feeds bound to container booking |
| Terminal gate events | Missed or delayed | Ingested from port community systems |
| ETA re-estimation | Static at booking, updated manually | Dynamic per-leg, recomputed on drift |
| Drift detection | Customer notices first | Astra flags against promised schedule |
| Customer status queries | Ops team answers by email | Clara resolves autonomously in seconds |
Three implications follow.
- Container-level beats shipment-level. A shipment can be “on track” while individual containers are drifting. Container-level granularity is what lets you triage.
- Proactive notification is a moat. Forwarders that notify before the customer asks compound NPS faster than those who invest in a prettier portal.
- Visibility data is a settlement input. When the timeline is trustworthy, Nexa can reconcile detention and demurrage claims automatically against actual terminal events — not against carrier-supplied summaries.
What to do about it
Audit your ocean visibility by counting milestones per container, not by counting carrier integrations. Most forwarders discover that their average container has half the milestone density they thought, because fallback logic is silently failing. Pilot one trade lane end-to-end with normalized milestones plus Astra drift detection plus Clara customer comms — the lane-level metric that matters is percentage of exceptions detected before the customer reports them. And treat detention and demurrage reconciliation as the follow-on unlock; the same milestone feed that powers visibility also powers autonomous settlement through Nexa.
For how agent-run forwarders reshape the P&L, read our FF digitization playbook. Explore Shipsy for freight forwarders and the Transportation Management System.