Transport management system
Dispatch, route planning and a driver app that keeps working without signal, for a logistics fleet of 200+ vehicles that had outgrown its spreadsheets.
- Logistics operator
- 200+ vehicles
- 2023 · in daily use
- 2023
Dispatch ran on spreadsheets and phone calls
A logistics operator running more than 200 vehicles planned every day in spreadsheets. Assignments went out by phone, changes during the day existed only in the dispatcher’s head, and the numbers that reached accounting at the end of the month were re-typed by hand from whatever had been written down.
The spreadsheet had become load-bearing: it worked, but only while the people who understood it were at their desks. Nothing about it could be checked, and nothing about a finished day could be reconstructed a week later.
What we could not change
- Drivers are offline for half the day. Routes cross places with no coverage. Anything that assumed a live connection would have failed exactly where the work happens, so the driver app had to hold a day of work on the device and reconcile when signal returned.
- The accounting system stays. It was not in scope and not going to be replaced. Dispatch had to agree with it rather than own the numbers, which made reconciliation part of the design instead of an afterthought.
- Operations never stop. There was no window in which the fleet could pause while a new system arrived. The rollout ran alongside the old process until the new one was demonstrably right.
- The existing data was inconsistent. Years of manual entry left the same vehicle, route and client written several ways. Cleaning that up was part of the project, not a prerequisite someone else would handle.
One place to look, and one that survives no signal
Dispatch and route planning moved into a single system: who goes where, in what order, and what changed since the plan was made. Assignments reach drivers through a mobile app built to work offline first — it holds the day’s work locally, records what happened, and reconciles when the device is back on a network rather than losing the entries made in between.
Background processing runs through a job queue, which is what makes reconciliation and the integration with accounting observable: work that fails is visible and retried rather than quietly dropped. The heavier processing sits in separate services, so the parts under load can be scaled and deployed without touching dispatch itself.
In daily use since 2023
The system has run the operator’s dispatch every working day since 2023. Planning, changes during the day and the handover to accounting happen in one place, and a finished day can be reconstructed afterwards — which was not possible before.
We are not publishing efficiency figures. The operator has them; we do not have permission to quote them, and a number we cannot show the workings for is worth less than saying so.
More on this kind of system
- Offline-first when drivers lose signal for half the dayDrivers lose signal for half the day, so the app has to hold a day of work on the device. What that costs, and the conflict nobody designs for up front.
- When a spreadsheet becomes load-bearingA spreadsheet becomes a system the moment it starts holding rules rather than numbers. The observable signs, and the honest case for leaving it alone.
- Declare maintenance jobs as data, not as codeA maintenance tool that can run any command is one nobody should trust with admin rights. What changes when the job is declarative data instead of code.
Have a system shaped like this one?
Send us the shape of the problem — what it has to do, what it must not break, and what is already in place. We will tell you whether we are the right team for it.
Start a projectWe reply within 1 business day. No sales calls unless you ask for one.