Route planning rebuilt on live telemetry
Planning ran on yesterday's data. We moved the feed to near-real-time and rebuilt the optimiser around capacity that actually exists.
- Empty miles
- -7%
- Fuel saving
- $1.4M
- Routes per day
- 3,100
- Data latency
- 4 min
The situation
Route planning ran overnight against yesterday’s positions. By the time drivers received a plan it reflected a fleet that had already moved, so dispatchers overrode it constantly and planned by phone instead.
Constraints
The optimiser could not be replaced wholesale mid-season. Whatever we built had to run alongside the existing process until dispatchers trusted it.
What we did
We shortened the telemetry path from 24 hours to about four minutes, then rebuilt the planning inputs around capacity that actually exists rather than capacity assumed the previous evening.
For two months both systems ran in parallel and dispatchers compared them. Adoption followed the evidence rather than a mandate.
Result
Empty miles fell from 18% to 11%, worth roughly $1.4M a year in fuel alone. The dispatchers stopped overriding, which was the real signal that it worked.
Results
| Measure | Before | After |
|---|---|---|
| Empty miles | 18% | 11% |
| Planning data latency | 24 hrs | 4 min |
| Routes replanned per day | 0 | 3,100 |
| Annual fuel cost | $19.8M | $18.4M |
What we left behind
- A project in the client's own repository, with tests and CI
- Documented definitions with named owners
- Runbooks for every scheduled job, written for a non-engineer
- Two weeks of training for the team taking it over
Other engagements you might want to read
Tell us which number you cannot trust
Send one paragraph about the report that always starts an argument. A data lead, not a salesperson, replies within one business day.



