Everything downstream depends on knowing where it actually is.
Logistics runs on position and status. When those are late, wrong or held in someone's inbox, every decision built on top of them (routing, labour, customer promise) is made on stale information.
- 01VisibilityOne status, not four systems
- 02IntegrationEDI, carrier APIs, telematics
- 03ExceptionsSurfaced early, not discovered late
- 04OptimisationRouting, loading, labour planning
- 05DevicesRugged scanners and driver apps
- 06LegacySystems that predate the current fleet
A late status is worse than no status.
In most operations we look at, the data exists somewhere, in a carrier portal, an EDI file that lands overnight, a telematics feed, a driver's message. The problem is that it arrives at different times and in different shapes, so nobody can answer a simple question about a consignment without checking three places.
That gap is where the cost sits. Customer service cannot answer, planning works from yesterday's picture, and exceptions are discovered when someone chases rather than when they happen.
Fixing it is rarely glamorous. It is normalising a dozen feeds into one status model, deciding what each status means, and then surfacing deviation rather than streaming everything at everyone.
Once that exists, the interesting work becomes possible: predicting a late arrival before it is late, planning labour against a realistic picture, and letting an agent handle the routine chase entirely.
Six pieces of logistics work we do repeatedly.
Real-time tracking & visibility
One consignment status assembled from carrier, telematics and scan data, with the provenance of each update kept.
Carrier APIs · EDI · telematicsTMS & WMS integration
Connecting transport and warehouse systems that were bought years apart and never properly introduced.
TMS · WMS · ERP · middlewareRoute & load optimisation
Planning that accounts for the constraints your planners work around, not a textbook version of them.
Planning · constraints · telematicsDriver & warehouse apps
Offline-first applications for rugged devices, poor coverage and gloved hands.
Android · scanners · offline syncException & delay prediction
Flagging the consignment that will be late while there is still time to act on it.
History · live feeds · alertsCustomer status automation
Answering where-is-it enquiries end to end, and proactively telling customers before they ask.
Ticketing · tracking · notificationsSix realities that separate logistics software that works from software that demos.
| Reality on the ground | What it forces in the build |
|---|---|
| Connectivity is not guaranteed Warehouses have dead zones and vehicles leave coverage. | Offline-first apps with local persistence, queued actions and conflict resolution when the network returns. |
| Devices are not phones Rugged scanners, older Android, gloved hands, cold stores. | Large targets, high contrast, very few taps, and testing on the hardware the operation uses. |
| Exceptions are the job The clean path is not where the time goes. | Exception flows designed first. Software that only handles the happy path is bypassed within a month. |
| Data arrives out of order A scan can land after the delivery confirmation. | A status model that tolerates late and duplicate events without corrupting the consignment record. |
| Planners know things the system does not The undocumented constraint is usually real. | Optimisation presented as a suggestion that can be overridden, with the override captured as a signal. |
| Peak is not an edge case The operation is judged on its worst week. | Capacity, queueing and failure behaviour designed for peak, and load-tested against its actual shape. |
Before you buy more visibility software.
Three questions we are asked by almost every logistics client.
We already have a tracking portal. Why is nobody using it?
Usually because it shows everything, not what changed. A portal that requires someone to go and look is a portal that gets checked when there is already a problem. The versions that get used push deviation (this consignment will miss its window, this one has no scan in six hours) into the place the person already works, which is often the customer service queue instead of a separate screen. The second common reason is trust: if the portal has ever been wrong about a status, people go back to phoning the depot and never come back.
Can you integrate with carriers who only support EDI?
Yes, and a large share of this sector still runs that way. EDI is not the problem it is often presented as; it is well-specified and stable. The real work is in the variation between partners, because everyone implements the standard slightly differently, and in handling the files that arrive malformed or late without silently dropping a consignment. We normalise carrier feeds into one internal model so the rest of your systems never need to know which partner a shipment is with.
Is route optimisation worth it if our planners are good?
Often not for the routing itself, and it is worth saying that plainly. Experienced planners beat naive optimisation because they hold constraints nobody wrote down. Where the return usually appears is in giving those planners a faster feedback loop (letting them test a scenario in seconds instead of an afternoon) and in absorbing the volume they do not have time to review at all. Optimisation that presents itself as a suggestion your planner can override gets adopted; optimisation that presents itself as the answer does not.