Real-time visibility platform for a regional carrier
Key result: −31% missed delivery windows Illustrative
What was actually going wrong.
The carrier knew where a shipment was only when somebody asked. Status arrived from four places — an EDI feed from line-haul partners, a warehouse scanning system, a driver app and a customer service inbox — each on its own schedule and each with its own idea of what “delivered” meant. A missed delivery window was usually discovered when the customer called, by which point the recovery options had narrowed to an apology.
Exceptions found by the customer
The first notification of a failed delivery was normally the customer, which is the most expensive way to learn it.
No true cost per shipment
Fuel, surcharges and redelivery sat in different systems, so margin per lane was reconstructed monthly at best.
Four versions of the truth
Operations, customer service and finance each trusted a different system, and reconciling them was a person’s week.
The route we chose, and what we ruled out.
We deliberately did not replace the TMS. The constraint was not execution — it was that no single place held a shipment’s current state. So the first slice was a read-only event layer beside the existing systems: cheap to build, impossible to break dispatch with, and enough to establish whether one reconciled timeline actually changed behaviour before anyone committed to more.
Decisions taken up front
- Integrate around the TMS rather than replace it
- Read-only first, so the first release could not affect dispatch
- Two partners in the pilot, chosen for messy data rather than clean
What we designed and built.
An event pipeline normalises every partner feed to one shipment event model, and a reconciliation service assembles the timeline from partial and conflicting updates instead of assuming the last message wins. On top of that, an exception engine flags a shipment at risk while there is still time to act, and customer notifications fire from real events rather than from a nightly schedule.
The stack behind it.
Nothing exotic. The interesting engineering was in handling late, duplicate and out-of-order events as the normal case rather than as errors.
Python
Airflow
PostgreSQL
AWSHow it went live.
Sequenced so that the first release could not break the operation, and so that each step earned the next one.
Two partners first
The messiest EDI feed and one portal-only partner, so the event model met the hard cases before the easy ones.
Run in parallel
The new timeline ran beside the existing reports for six weeks with a daily diff, until every disagreement was explainable.
Exceptions to the people who act
Alerts routed to the dispatchers who could still recover a delivery, rather than to a dashboard nobody owned.
Then the rest of the network
Remaining partners onboarded against the established pattern, which is where the cost per integration dropped.
What moved, and how it was measured.
Missed delivery windows fell 31% across the two quarters after the exception engine went live, measured against the previous two quarters using the same definition of a miss. The less quantifiable change mattered more to the operations team: the recovery conversation moved from after the failure to before it.
What we would do differently
We would put the daily diff in front of operations from week one rather than week three. Trust in the new timeline was the real dependency, and we built confidence in it later than we should have.
- One shipment timeline reconciled from every partner feed
- Exceptions raised while recovery was still possible
- Customer notifications driven by events rather than a nightly job
- Landed cost captured per shipment instead of reconstructed monthly
- A repeatable onboarding pattern for each new carrier
Other studies.
FinTechRebuilt onboarding for a digital lending product
An onboarding journey where every applicant reached manual review, rebuilt so straight-through cases clear on their own and only genuine exceptions land with an underwriter.
2.4× faster approvals Sample
RetailUnified commerce for a multi-brand retailer
Stock, pricing and customer records that disagreed between channels, unified behind one commerce platform so the site and the stores stopped telling customers different things.
+18% online revenue Sample
Logistics & Transportation in depth
The constraints that shape technology work in this sector, and how we approach them.
Open sector pageHave a problem shaped like this one?
Tell us what is not working and what it is costing. We will tell you whether we are the right team for it.