Most freight visibility platforms will tell you that your container is at a terminal in Rotterdam, that it arrived at 07:43, and that the vessel it was booked on is showing an ETA delay of six hours. That information is accurate. It is also completely useless if your desk has no way to act on it before the detention clock starts.
The visibility data problem, stated plainly
Real-time freight visibility has become a baseline expectation for logistics technology. Shippers, forwarders, and 3PLs now routinely pull tracking feeds from ocean carrier APIs, terminal operating systems, and port authority databases. The question is not whether you can see where your cargo is. The question is what your desk can actually do with that information in the 15 minutes after it matters.
Visibility platforms answer one question: where is my container right now? A well-run ops desk needs the answer to a different question: my port window just closed -- which carrier can take this load, at what cost, and can we move before the free time clock runs out?
These are not the same question. Answering the second requires a different class of tooling.
Where the gap shows up in practice
When a vessel ETA shifts by eight hours and pushes your nominated slot into the next morning's window, your visibility data tells you the slot is gone. But the desk still has to identify alternative routing options, check available carrier capacity on those lanes, calculate whether rerouting saves money compared to absorbing detention, and confirm changes with the shipper. Done manually, that process takes 45 to 90 minutes for a coordinator who knows the carriers well. It takes longer for someone covering an unfamiliar lane.
Consider a 3PL managing 80 to 120 active loads per month on North Sea and Bay of Biscay lanes. Their visibility platform fires a disruption alert at 11:15 -- a slot closure at a major hub port affecting three loads due to arrive that evening. The coordinator sees the alert at 11:22. By 11:55 she has identified two possible rerouting options by phone, confirmed availability with one carrier, and notified the customer. That is 33 minutes of productive response time. But only because she had the carrier contacts in memory, knew the alternative lanes, and was not simultaneously handling two other disruptions.
Remove any one of those conditions and response time stretches past the point where rerouting prevents detention.
The metric that reveals where your problem actually lives
If you want to know whether your desk has a visibility problem or a decision-support problem, look at your detention invoice frequency relative to your disruption event frequency.
If your tracking feed records 20 disruption events per month and you are paying detention on 14 or 15 of them, visibility is working. The gap is response capability. A desk with effective decision support pays detention on two or three events from that same pool -- typically the ones where carrier capacity genuinely was not available, or where the disruption window was under four hours with no reasonable reroute.
| Scenario | Disruption alerts per month | Detention events paid | Root problem |
|---|---|---|---|
| Desk A | 20 | 14-15 | Decision support gap |
| Desk B | 20 | 2-3 | Mostly unavoidable events |
| Desk C | 8 | 7 | Visibility gap and decision gap |
Desk C is the worst position: limited event detection combined with poor response capability. Desk A sees everything but acts too slowly. Desk B is where good freight operations tooling gets you.
What decision support actually requires
The tools that close this gap share three characteristics. First, they ingest tracking feeds but also hold your carrier capacity data, committed rates, and current load allocation. Second, they score rerouting options before presenting them to the desk -- not just "Carrier A has capacity on this lane" but "Carrier A at plus four hours and minus $180 per load versus Carrier B at plus seven hours and minus $95 per load, given your current free time window." Third, they write back to your TMS so confirmed reroutes do not require manual re-entry and the coordinator stays in one system.
The output is a recommended plan with carrier allocations and a cost comparison. The coordinator confirms or adjusts it. The desk does not do the analysis -- the tools do.
This is what we built Kilimanjaria around. The visibility layer was not the hard part. The hard part was building the replanning engine that scores carrier options in real time and writes the confirmed plan back into the workflow without adding a second system to manage.
Visibility is necessary, not sufficient
We are not arguing that visibility platforms are the wrong investment. Port event data, vessel ETA feeds, and terminal system integrations are essential inputs. A replanning tool cannot function without accurate position and schedule data underneath it. The point is that visibility is the foundation, not the finished structure.
Freight desks that consistently prevent detention fees are not the ones with the best tracking dashboards. They are the ones where the time between seeing a disruption and confirming a reroute is under 10 minutes. That requires the tools to carry the analytical load, not just surface the information.
One question to ask your current setup
If your port slot just closed, can your coordinator look at her screen and see a rerouted plan with carrier options and cost comparisons? Or does she see an alert that something went wrong and then start making phone calls?
That single question tells you more about your freight operations risk profile than any visibility platform benchmark or tracking uptime SLA. The desk that can answer yes to the first version of that question is the desk that stops paying detention invoices three weeks after the damage was already done.