CASE STUDY · LOGISTICS & SUPPLY CHAIN VISIBILITY
A real-time shipment visibility platform for a logistics network.
- 45%Status enquiries down 45%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised logistics network. Name withheld under confidentiality.
Carrier integrations and a tracking portal.
We connected the main carriers and the client's own systems into one integration layer. Each source was translated into a common set of events: picked up, in transit, at hub, out for delivery, delivered, delayed, exception. The tracking portal showed customers the status, expected arrival and key documents. An internal view gave customer service the same picture, so staff and customers looked at the same facts.
- 1Customers phoned or emailed for shipment status.
- 2The network worked with many carriers and partners, and each reported progress in its own way.
- 3Customer service staff opened several portals and inboxes to answer one question.
- 4Replies were slow, and the same customer often asked again a few hours later.
- 5The operations team saw this as a cost, and customers saw it as a sign that the network did not know where their goods were.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01One carrier sent events in batches once a day, with timestamps in a local time zone and no offset
Shipments appeared to move backwards, and the portal showed "delivered" before "out for delivery". Customers noticed within days of the pilot. We stored every timestamp with an explicit zone, set the zone per carrier in configuration, and added an ordering rule that prevented a status from going backwards without a flag.
- PROBLEM 02We also marked batch-fed carriers in the portal as "updated daily", so expectations matched reality
- PROBLEM 03A second hurdle appeared after launch
A port delay caused many shipments to be marked late at once, and the system sent hundreds of notices within minutes. Some customers received several messages for one disruption, and customer service took calls about the notices. We grouped alerts by cause, so one message covered all affected shipments of a customer, and we added a short quiet period before repeating an alert.
- PROBLEM 04Staff could also post a single note against an incident that appeared on every affected tracking page
03 · THE PROCESS
How we ran it.
We met the operations lead weekly and held a short demo every second week. Customer service staff tested each release and told us which questions still sent them to other tools.
- 01Step 1
Weeks 1 to 2: review of enquiry types, carrier list, data samples and event definitions.
- 02Step 2
Weeks 3 to 6: first carrier integrations and internal dashboard, tested on live shipments.
- 03Step 3
Weeks 7 to 10: customer portal, delay detection and notification rules, pilot with a group of customers.
- 04Step 4
Weeks 11 to 14: remaining carriers, monitoring, support training and wider rollout.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Customer service starts from the internal tracking view and rarely opens a carrier portal.
- NOW 02
Delay notices go out before customers ask.
- NOW 03
Operations review carrier feed quality each month and raise it in carrier meetings, using data instead of impressions.
- NOW 04
New carriers are added through a standard onboarding checklist.
- 45%
Status enquiries down 45%
05 · WHAT WE BUILT
How it works.
- Each carrier has its own adapter that fetches or receives updates by API, EDI, file or email.
- Adapters write raw messages to storage first, then a mapping step converts them into the common event model.
- That order means a mapping fix can be replayed on old messages.
- Events are de-duplicated and ordered by event time, not arrival time, because carriers often report late and out of sequence.
- An ETA service combines the carrier's own estimate with route history to produce a predicted arrival.
- The portal reads from a separate query store, so heavy traffic cannot slow ingestion.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Customers phoned or emailed for shipment status. The network worked with many carriers and partners, and each reported progress in its own way. Customer service staff opened several portals and inboxes to answer one question. Replies were slow, and the same customer often asked again a few hours later. The operations team saw this as a cost, and customers saw it as a sign that the network did not know where their goods were.
- What did Brandsmashers build?
- Carrier integrations and a tracking portal. We connected the main carriers and the client's own systems into one integration layer. Each source was translated into a common set of events: picked up, in transit, at hub, out for delivery, delivered, delayed, exception. The tracking portal showed customers the status, expected arrival and key documents. An internal view gave customer service the same picture, so staff and customers looked at the same facts.
- How was the work run?
- We met the operations lead weekly and held a short demo every second week. Customer service staff tested each release and told us which questions still sent them to other tools.
- What were the results?
- Status enquiries down 45%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
