A 4-container shipment from Ningbo to Norfolk, booked on a transpacific service with a Singapore transshipment. Plan looked clean on day one. By the time it arrived, the ops team had updated the customer three times — twice with information that turned out to be wrong.
Nothing failed in the carrier’s data. The tracking team failed to switch identifiers as the shipment moved through phases. They tracked by booking number after the booking had been split. They tracked one container’s progress and reported it as the shipment’s progress. They missed a transshipment divergence because they were watching the B/L-level summary instead of container-level events.
This is one of the most common patterns behind tracking dead ends — and it’s almost always preventable with a phase-based identifier rule.
The shipment, end to end
Composite case, drawn from patterns we see repeatedly across forwarder and BCO operations. The lane and dates are illustrative; the failure modes are not.
- Origin: Ningbo, China
- Destination: Norfolk, US East Coast
- Routing: direct service to Singapore, transshipment to a separate transpacific vessel, discharge at Norfolk
- Equipment: 4× 40′ high cube containers under a single Master B/L
- Customer: a US importer expecting all 4 containers to arrive together for a single inland move
Walk through it phase by phase. At each phase, the right identifier exists. The team using the wrong one creates the failure.
Phase 1: Booking confirmed, no containers assigned
What’s happening: The carrier issues a booking reference. Sailing is scheduled. SI cutoff and VGM cutoff are set. No containers have been assigned to this booking yet — that comes later, at the depot.
What the team should track with: Booking reference. It’s the only stable identifier that exists right now. It maps to the planned vessel, the cutoff dates, and the service.
What the team often does instead: Asks the shipper for container numbers prematurely, then logs partial or wrong numbers into the tracking system. When real container numbers are assigned later, the system shows two “shipments” — one with junk numbers, one with real ones. Reconciling this manually eats hours.
Failure prevented by: Logging the booking reference as the primary identifier. Leaving container fields empty until the carrier confirms them.
Phase 2: Vessel rolled, booking rebooked
What’s happening: Three days before cutoff, the originally booked vessel becomes overbooked. The carrier rolls this shipment to the next sailing — same service, different vessel, two days later. A new booking reference is issued. The old one is closed.
This is where most “missing shipment” tickets come from. The tracking system still references the original booking. Searches return nothing. The customer asks “where is my shipment?” and the ops team has no answer.
What the team should track with: The new booking reference. The B/L hasn’t been issued yet, so booking is still the only key.
What the team often does instead: Doesn’t update the tracking record. Continues to query the old booking. Reports “no movement” to the customer. When the actual vessel sails, the team scrambles to figure out what happened.
Failure prevented by: Treating the booking reference as a mutable field. When the carrier confirms a rebooking, the new reference replaces the old one in the primary tracking field, with the old one preserved in history.
If you’re managing this manually across carrier portals — checking each one for status, then reconciling against your system when something changes — a 30-minute walkthrough of how teams automate booking-reference reconciliation may save you the spreadsheet.
Phase 3: Containers gated in, B/L issued
What’s happening: All 4 containers are gated in at Ningbo. They’re loaded onto the new vessel. A few days after departure, the Master B/L is issued. House B/Ls are issued separately by the forwarder.
What the team should track with: Master B/L as the primary identifier. Container numbers logged as a secondary set, all 4 of them.
The Master B/L is now the most stable shipment-level reference. It will not change. It maps to all 4 containers. It returns shipment-wide events.
What the team often does instead: Logs only one container number — usually the first one returned by the carrier — and tracks that as a proxy for the whole shipment. This works as long as all 4 containers stay together. It fails the moment they don’t.
Failure prevented by: Logging all container numbers, not just the first. Making the Master B/L the primary view, with container-level detail accessible for exception investigation.
Phase 4: Singapore transshipment — one container diverges
What’s happening: The vessel arrives at Singapore for transshipment. Three of the 4 containers are discharged and loaded onto the planned onward vessel. One container misses the connection — there’s a gate-out timing issue, or the onward vessel is full, or the container is held for inspection. It rolls to the next sailing, 6 days later.
The B/L-level summary still shows “in transit.” The customer hasn’t been told anything is wrong, because at the shipment level, nothing looks wrong.
What the team should track with: Container-level events. This is where the B/L view stops being sufficient. The B/L returns the shipment’s overall status — which is still “in transit” because 3 of 4 containers are progressing normally. The 4th container’s divergence only shows up at the container level.
What the team often does instead: Continues to track at B/L level. Misses the divergence entirely. The customer is told “on track” right up until the moment 3 of 4 containers arrive at Norfolk and the 4th is somewhere south of Tokyo.
Failure prevented by: Routine container-level checks at known risk points (transshipment hubs, port-pair changes, multi-leg services). Or automated exception alerts at the container level that surface divergence the B/L view masks.
Phase 5: Norfolk arrival, three of four available
What’s happening: The vessel arrives at Norfolk. Three containers are discharged. One container is on a different vessel, six days behind. The customer expected all 4 for a single inland move; they now need to arrange a second move for the late container, or hold the 3 in storage waiting for the 4th.
D&D exposure starts on each container at terminal availability. The customer wants to know: which containers are released, which have holds, when can each be picked up.
What the team should track with: Container-level availability and release status. The B/L view is no longer the primary reference — at this stage, every operational decision is per-container.
What the team often does instead: Reports B/L-level “arrived” status. Customer asks operational questions the B/L view can’t answer. Ops scrambles back to container-level data, but by then the late container’s situation has changed and the team has to call the carrier directly.
Failure prevented by: Switching to container-level monitoring at terminal arrival. Customer-facing updates at this stage list per-container availability, not shipment-level summary.
The phase-by-phase rule, summarized
Every phase has a primary identifier and a backup. The team’s job is to switch as the shipment moves.
| Phase | Primary identifier | Backup | What you’re protecting against |
|---|---|---|---|
| Booking confirmed, pre-loading | Booking reference | — | Logging junk container data prematurely |
| Rollover or rebooking | New booking reference | Old reference (history) | Tracking a closed reference |
| Loaded, B/L issued | Master B/L | All container numbers | Single-container proxy errors |
| Transshipment leg in progress | Container numbers | Master B/L | Divergence masked by B/L summary |
| Arrival, terminal handling | Container numbers | Master B/L | B/L-level “arrived” hides per-container availability |
Why this happens, and why fixing it is structural
Every failure in the example traces to the same root cause: the team had one tracking record per shipment with one identifier field, and they didn’t update which identifier was primary as the shipment progressed.
This isn’t a discipline problem. It’s a workflow problem. When ops teams check carrier portals manually, the cognitive load of “which identifier am I supposed to be using right now” is real, and it’s the first thing that breaks when the team is busy or when a single person owns dozens of active shipments.
The structural fix is to maintain all three identifiers — booking, B/L, container set — on every active shipment record, with the system surfacing whichever one is most relevant for the current phase. Booking-level updates roll up. B/L-level events show shipment progression. Container-level events surface divergence.
That’s how the example failures don’t happen. Not because anyone remembered to switch identifiers — because the system did.
A two-minute intake checklist
If you do nothing else, capture these fields when a shipment enters your tracking workflow. They take two minutes and they prevent most of the failures above.
- Booking reference — carrier and service noted
- B/L reference(s) — Master and House noted separately, with which one your workflow uses for tracking
- All container numbers — once assigned, every one of them, not just the first
- Current phase — pre-loading, in transit, transshipment, arrival
- Next expected milestone and date — so silence after that date is a real signal
The “next expected milestone” field is the most undervalued one. Without it, you don’t know whether “no update for 3 days” means something is wrong or that nothing was supposed to happen yet.
What to tell customers
Customer communication breaks at the same identifier seams as internal tracking. When you have to explain why an update changed:
- “Booking references reflect planned movements. They can change if the carrier rebooks.”
- “Once the B/L is issued, shipment-level updates stabilize.”
- “For multi-container shipments, we monitor each container — they can diverge at transshipment, even when the shipment as a whole is on track.”
This framing is honest and removes the most common interpretation disputes before they happen.
Further reading
- BL vs Container vs Vessel vs Booking: When To Use Each Key — the quick decision-tree companion to this post
- What is a Master Bill of Lading (MBL) and Why Does It Matter?
- DCSA — Track & Trace standards overview
- ISO 6346 — Container identification standard
Need help interpreting this disruption or your shipment?
For a quick question, chat with Tradlinx on WhatsApp. For a deeper discussion, book a time below.
Prefer email? Contact us directly at min.so@tradlinx.com (Americas), sondre.lyndon@tradlinx.com (Europe), or henry.jo@tradlinx.com (EMEA/Asia).
Leave a Reply