Marked as Delivered but the Container Never Arrived: The Drayage Visibility Problem
The container shows “delivered” at 2:47 PM. The warehouse manager walks the yard at 4 PM looking for it. Nothing. He pulls up the TMS, sees the green checkmark, calls the drayage dispatcher, who confirms the driver swore he dropped it. Three days and 14 phone calls later, the chassis turns up at a competitor’s yard six miles away. The driver had hit “delivered” on his phone when he pulled into what he thought was the right gate.
Talk to any BCO running 500+ containers a month through Long Beach, Savannah, or Newark and you’ll hear a version of this story from the last quarter. The drayage visibility problem isn’t missing data. The data is confidently wrong, and nothing in the standard stack is built to catch it.
What “Delivered” Actually Means in Drayage
Walk the data flow from terminal to dock and the word “delivered” starts to look thin.
A container is released from the port terminal operating system (typically Navis N4 or similar) to a drayage carrier. The carrier dispatches a driver, who hauls the box to the consignee. Along the way, the carrier’s TMS pushes EDI 214 status messages upstream: CLA (container available), AF (arrived at facility), CD (delivered), X3 (arrived at consignee).
Here’s the part that gets glossed over in vendor decks: the CD status is generated by the drayage carrier’s system, based on the driver’s input. It’s a carrier claim, not a consignee confirmation. The WMS at the receiving DC has its own “received” event, gated by an inbound check-in, and those two events can disagree by hours, days, or in bad cases, permanently.
EDI 214 is structured data. Structured data can still be wrong. If the driver taps “delivered” in the wrong geofence (or with no geofence at all), the entire downstream chain inherits a lie that looks like a fact.
The Three-System Handoff Problem
Three systems own three slices of the move, and none of them owns the container.
PORT TERMINAL DRAYAGE CARRIER CONSIGNEE / DC
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ TOS / N4 │ ─────► │ TMS / ELD │ ─────► │ WMS / Yard │
│ │ │ │ │ │
│ "Released" │ │ "Delivered" │ │ "Received" │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└──────────────────────┴──────────────────────┘
NO SHARED CONTAINER-LEVEL TRUTHThe TOS optimizes for terminal throughput. The TMS optimizes for driver utilization and billing. The WMS optimizes for dock door scheduling and inventory accuracy. Each system has a different definition of “done,” a different timestamp authority, and a different operator pressing the button.
The container itself, the physical 40-foot box that holds the cargo your business runs on, has no voice in any of these systems. It can’t tell the TOS it was actually picked up. It can’t tell the TMS it was dropped at the wrong yard. It can’t tell the WMS it’s sitting 200 yards away behind the trailer pool. It’s a passive asset in a chain that assumes every operator handoff produces accurate data.
When the operators disagree (or worse, when one of them is guessing), there’s no referee. The BCO sees three systems, three statuses, and no way to know which one is true without sending someone to physically look.
Where the Container Actually Goes Wrong
FAILURE MODE VISIBLE IN TMS? VISIBLE TO BCO?
──────────────────────── ───────────────── ─────────────────
Misdelivered facility No No
Staged at carrier yard As "delivered" No
Chassis swap error Partial No
In-transit theft No Days later
False driver POD As "delivered" NoMisdelivery to the wrong yard happens more often than carriers want to admit, particularly in dense port markets where consignee facilities cluster within a few miles of each other. Carrier-yard staging is the next common failure: a driver drops at the drayage yard to clear his slot but taps the move complete, and the billing artifact propagates as truth. Chassis swap errors corrupt the link between move record and physical container. Then there’s in-transit theft, especially the strategic-fraud variety that’s grown sharply since 2022, which can occur entirely inside the window where everyone thinks the box is fine.
In every case, the TMS reports “delivered” with full confidence. The BCO finds out when the inventory doesn’t show up in the WMS, when the customer doesn’t get their order, or when the insurance adjuster starts asking questions.
The True Cost of the Visibility Gap
Detention and demurrage are the obvious line items. FMC rulings over the past 18 months have tightened the rules on what carriers can charge, but disputes still consume operations time, and a contested invoice doesn’t get refunded automatically.
Cargo theft losses reported to CargoNet exceeded $450M in 2023. Strategic theft, including fictitious pickups, identity fraud, and double-brokering, climbed past 400% year-over-year, and most of those incidents happen in the gap between port-out and consignee-in.
Then there’s the soft cost: chargeback disputes between BCOs and 3PLs that take weeks to resolve, insurance claim friction when the POD is contested, and the labor cost of investigation. A logistics manager spending half a day chasing one container isn’t a budget line, but multiply it across an annual volume and the number gets uncomfortable.
The worst part isn’t the loss itself. The loss is unattributable. When a director asks why the company is bleeding 1.2% of inbound value to “miscellaneous logistics shrinkage,” nobody can point at a system and say it failed, because no system was responsible for the truth in the first place.
Why Existing Tools Don’t Close the Gap
This isn’t a knock on the visibility category. Each tool does what it was built for. The category just wasn’t built for this specific question.
GPS on tractors tracks the truck. Once the chassis is dropped and the tractor leaves, the container is invisible. EDI 214 is structured data, only as accurate as the human or system entering it. Yard management systems start at the gate; they don’t see the in-transit gap. Port community systems end at the gate, mirror image of the same blind spot. Driver apps depend on driver compliance, and compliance is uneven at 2 AM after a 10-hour shift. Real-time transportation visibility platforms (the Project44 / FourKites category) aggregate carrier-reported data beautifully, but they’re aggregating the same upstream signals (EDI, ELD, carrier API feeds) that produced the bad “delivered” status in the first place.
Aggregating five carrier-claimed feeds produces a confident average of carrier claims, not an independent check on them.
What Closing the Gap Actually Requires
- Container-level telemetry, not tractor-level. The sensor travels with the box, not the cab.
- Independent of carrier-reported status. The data path doesn’t pass through the system that might be wrong.
- Geofence-verified arrival at the actual consignee facility, not a driver’s tap.
- Tamper and door-open detection to catch in-transit interference.
- Battery life that survives the full intermodal cycle, including weeks of ocean transit and port dwell.
- Coverage that works across carriers, chassis pools, and facilities without requiring infrastructure at every site.
That last point is what’s historically broken container-level IoT. Cellular trackers burn battery and cost a fortune in roaming. Proprietary RF networks need readers at every yard. The economics didn’t work for a single-use or low-margin move.
Hardware and network economics have shifted recently. Low-power BLE devices that beacon to satellite and terrestrial networks have brought per-unit cost and battery profile to a point where container-level tracking can be applied at scale, not just on high-value loads. Analyst coverage from Gartner and ARC has been pointing in this direction, framing container-level IoT as the missing data layer underneath the existing visibility stack rather than a replacement for it.
Where Hubble Fits
Hubble makes container-level tracking work economically across the full intermodal cycle. Small BLE-based trackers report through satellite and terrestrial gateways without per-device cellular cost, with battery life measured in years, not weeks. Data flows directly to your systems through a packet webhook integration so the container’s own signal sits alongside (and can independently verify) your existing TMS and WMS feeds. If you’d like to see the technical architecture or talk through a pilot on a specific lane, our asset tracking implementation guide is a good starting point.
Hubble Network makes container-level tracking economically viable across every lane, not just the high-value ones. See how it works →