TL;DR
Most logistics teams reach for route optimization too early. Before optimization, you need visibility. Before visibility, you need clean dispatch data. We rebuilt a regional logistics provider’s operations stack from chat-group dispatch and spreadsheet ETAs to a live console in eight weeks. The lift was not the routing algorithm. It was finally seeing what the fleet was doing.
The problem nobody admits
The dispatch desk we walked into was not lacking software. It had three tools: a fleet GPS provider, a spreadsheet of shipments, and a Viber group with the drivers. None of them talked to each other.
When a customer called about a late delivery, the dispatcher had to:
- Search the spreadsheet for the shipment ID
- Open the GPS provider’s web portal and find the truck
- Message the driver directly to confirm
- Reply to the customer
Each call took three to seven minutes. The desk handled forty calls on a normal Wednesday. That is two and a half hours of a senior dispatcher’s day spent on data archaeology before any operational decision gets made.
The team’s instinct was to fix the routing. The routing was fine. The visibility was the bottleneck.
What we shipped first, deliberately
Before we touched optimization, we built three things that are unglamorous and load-bearing:
A unified shipment record. Every shipment got an identifier the dispatcher, the driver, and the customer-care team all referenced the same way. No more “the second Cebu run today.” Same ID, every conversation.
A live status feed for each shipment. Not GPS coordinates, just status: scheduled, dispatched, in transit, delivered, exception. The status changed automatically when the driver reported a state on their app, plus manual override for the dispatcher when the app failed.
A dispatcher console that put the live shipment list, the GPS positions, and the driver chat in one screen. Not a dashboard for leadership yet, the operating console for the desk that runs the day.
That was phase one. Six weeks of work. The team was skeptical because none of it looked like the AI-routing demos they had seen at trade shows. Then they used it for a week.
The actual lift
Two numbers moved in the first month after rollout:
The customer-care reply time dropped from average four minutes to under thirty seconds. Most calls were answered with a glance at the console.
Late ETAs as reported by customers dropped by about a third, even though we had not changed routing yet. The reason: the dispatcher could now spot a delay developing two hours earlier than before, which gave them time to swap a load, reroute, or proactively warn the customer. Visibility creates time. Time is what lets you intervene.
Then we did the routing
Phase two was the algorithm work, eight more weeks. By then the data was clean enough to actually use. Routing optimization on dirty data is worse than no optimization, because the algorithm picks the route based on bad assumptions and the dispatcher loses trust.
We added route suggestions, ETA modeling, and cost-per-mile reporting. The team adopted the suggestions in stages. They overrode the algorithm freely for the first month while we tuned the cost function for their reality. By month three, override rate dropped below ten percent.
What this is not
This is not a story about replacing dispatchers. The dispatcher is still there. They are doing fewer Viber lookups and more decisions about exceptions. The console did not save headcount. It bought capacity for a desk that was choking on data plumbing.
It is also not a story about a six-figure SaaS. The whole operating console runs on a stack a senior engineer can understand: a Node API, a React console, the existing GPS provider’s webhook feed, a Postgres database. Operationally cheap. Architecturally honest.
When you actually need a TMS
If you are a logistics business doing more than fifty shipments a day and your dispatcher’s screen has more than three tabs open at once, you need a TMS. Not a SaaS subscription. A console designed around your operating model. The off-the-shelf options force your team to adapt to them; we build it the other way around because the operation already exists and the system has to fit it.
If you are doing fewer than fifty shipments and the dispatcher can hold the whole picture in their head, you do not need a TMS yet. You need a clean shipment record and a single source of truth for status. Spreadsheet plus Viber works at that scale, if you discipline how you use them.
The trap is the middle: somewhere between a hundred and three hundred shipments a day, where the chaos becomes systemic but the team has not budgeted for the platform. That is when reaction time degrades, customer complaints rise, and senior people start spending all day on data archaeology instead of operations.
What to do this quarter
Before you talk to a TMS vendor or hire a routing consultant, do this:
- Time-track your dispatch desk for one week. How much of the day is data lookup versus decisions?
- Audit your shipment IDs. Does every team use the same one for the same shipment?
- Ask your dispatcher what they would change first if they could change one thing. The answer is rarely “better routing.” It is usually some version of “I want to see what is happening without asking three people.”
Fix that. Then talk about routing.
If you want to talk through what this looks like for your operation, book a consultation. We bring the system, but the work starts with understanding yours.