Who this was for
A mid-size cross-border freight operator in the UAE, running scheduled road freight between Dubai, Abu Dhabi and Muscat with a fleet supported by partner carriers. Details withheld under NDA; the account was handled through the client's operations leadership and an internal IT function of four people.
The problem pattern
Dispatch ran in one system, shipment milestones arrived through four separate carrier portals, and customer service answered status questions from memory. Exceptions were discovered when a customer called, which meant the business learned about problems from the people least able to help fix them.
What made it hard
Carrier data arrived in incompatible shapes, at inconsistent intervals, and sometimes twice for the same event. The integration had to reconcile duplicates, preserve an audit trail of what was known at any point in time, and keep working when a depot's connectivity dropped — without asking dispatchers to change the tools they used to move freight.
How the work was sequenced
- Mapped the shipment lifecycle with dispatch and customer-service staff, naming the twelve events that actually mattered and the owner of each data source.
- Built an idempotent ingestion layer with de-duplication keys and per-carrier mapping, so replaying a feed could never double-count a milestone.
- Delivered an exception-first control view: shipments needing attention ranked by dwell time and ETA drift, with everything else available but quiet.
- Released customer-facing status sharing behind a staged rollout to a pilot customer group, then widened it once reconciliation reports matched operations' expectations for three consecutive weeks.
The solution in operation
A single service ingests carrier and telematics events, reconciles them into an explicit shipment timeline, and feeds three surfaces: a dispatcher control view ranked by exception risk, an automated customer status notification with timestamps and confidence, and a reconciliation report that flags feeds which stopped or drifted. Everything runs with local buffering at depots so a network interruption queues rather than loses events.
Solution architecture
Timeline
22 weeks end to end: four weeks of joint discovery, eight weeks to the internal control view, six weeks to customer-facing tracking, then a six-week stabilisation running alongside the legacy process before decommissioning it.
Reported results
- Exception detection moved from next-morning reports to within fifteen minutes of the triggering event.
- Customer status enquiries by phone fell by roughly a third over the first quarter after rollout.
- Milestone data reconciled automatically across four carrier feeds, removing about two hours of daily manual checking per depot.
- All shipment state changes carry a timestamp and source, so dispute conversations now start from a shared record.
What we took from it
- Reconciling duplicate carrier events early is cheaper than explaining a wrong ETA to a customer later — and depots need to keep working when the link drops, by default rather than by exception.
- The control surface had to be ranked by exception, not by volume; a screen showing all shipments equally was used for a week and then ignored.
- Keeping the legacy process running in parallel for six weeks turned cutover from an argument into a routine.
Tools and technologies
TypeScript · Node.js · PostgreSQL · Managed message queue · React · AWS