Route optimisation gets almost all the attention in delivery software. But in commercial terms, building the route is a small share of the problem. Executing it well through a live, chaotic day is where the cost, the service, and the margin are actually won or lost.
The plan is the opening move, not the game
Route planning remains a core capability. But once drivers depart, outcomes are shaped by dwell time, traffic, customer responsiveness, access constraints, same-day inserts, returns, proof quality, and exception handling. The common claim that route optimisation is the heart of delivery software is incomplete: planning may define a small share of the problem while execution accounts for most of the operating challenge.
There is a reason the industry keeps overweighting the solve. It is the part of the problem that is clean. A routing engine takes a fixed set of stops, vehicles and constraints and returns an answer that can be benchmarked, demoed and marketed. Every serious vendor now produces a competent morning plan, which is exactly why the plan has stopped being the differentiator. The moment the first driver pulls away, the tidy mathematical problem becomes a messy operational one, and most platforms quietly hand that part back to the dispatcher.
The 5% and the 95%
A useful way to test the thesis is to count decisions, not features.
The 5% is everything decided before departure: which stops go on which route, in what sequence, respecting which time windows, balanced across which vehicles. Call it one large decision per route per day. It matters, and it should be done well. It is also finished by 7am.
The 95% is every decision the day demands after that:
- Does the route still hold after a 25-minute dwell at stop three, or does the back half need resequencing?
- The 11:40 urgent order: which route absorbs it with the least damage, or does it wait for the afternoon wave?
- A customer will not be home until 4pm: skip, reattempt, redirect to a neighbour, or rebook?
- This proof-of-delivery photo is a doorstep with no parcel visible: accept it, or challenge it now while the driver is still on site?
- Two routes are drifting towards overtime: pull stops off now, or gamble on the traffic clearing?
- Who tells the customer their slot has moved, and when?
A 20-vehicle operation faces hundreds of these calls every single day. Each one moves cost, service or risk. Software that answers only the first question has opted out of nearly all the decisions that determine the P&L. That is not a rhetorical flourish; it is the arithmetic behind the title of this article.
Where the value actually leaks
The expensive part of delivery mostly sits outside the route solve: overtime, failed deliveries, idle capacity, reactive customer messages, manual dispatch touches, and weak proof of delivery. A platform that can produce a beautiful morning plan but cannot change the day when it drifts leaves that value on the table, and hands the recovery back to people.
Notice what these leaks have in common: none of them are visible in the plan view. The plan showed no overtime, no failed stops, no claims. The leaks only exist in the gap between the plan and the day, which is precisely the gap most delivery software does not operate in. It is also why operators who fix execution rather than re-tendering their routing engine see the compounding gains we describe in Reducing Delivery Costs by 30-40% with Real-Time Execution: no single lever produces the improvement, the levers stack.
Three ways a good plan dies
These vignettes are illustrative composites drawn from patterns we see across delivery operations, not named case studies. Each one starts with a perfectly optimised route.
The cascade. A driver hits a 25-minute dwell at an office building with a broken goods lift. The plan absorbs none of it. By stop nine he is 40 minutes behind, so he starts improvising his own sequence to "make up time", skipping a time-windowed stop he assumes he has already missed. He had not. The operation ends the day with one avoidable failed delivery, 50 minutes of overtime, and a route history nobody can reconstruct, because the software only ever knew about the plan, not the day.
The eyeballed insert. An urgent B2B order lands at 11:40. The dispatcher does what dispatchers do: glances at the map and gives it to the nearest van. Nearest is not the same as cheapest to disrupt. The insert pushes two SLA-bound stops on that route past their windows, while a van two miles further away had slack that would have absorbed the job cleanly. Nobody notices until the key account calls at 3pm. The routing engine was never consulted, because the routing engine only runs in the morning.
The proof that wasn't. The day closes green on every dashboard. Ten days later a claim arrives for a missing consignment. The proof on file is a photo of a closed door, no parcel in frame, logged 200 metres from the delivery point. The operator credits the customer, absorbs the stock loss, and adds a manual POD-checking step for the whole team, permanently. Weak proof was accepted in real time because nothing in the software was judging proof in real time.
Three different failures, one root cause: the day drifted and the software watched.
What "execution-first" changes
An execution-first system still plans well, then keeps re-reading the day and acting on it: resequencing a stop, inserting an urgent job, rejecting weak proof before it becomes a claim, updating a customer before they call. That is the difference between a tool that plans and a system that executes, and it is why buyers increasingly compare platforms on live intervention rather than solver speed.
Run the three vignettes back through that lens. The cascade gets caught at stop three, when the dwell first breaks the plan, and the back half is resequenced before the driver starts improvising. The 11:40 insert is priced against every live route, not eyeballed against a map. The doorstep photo is challenged while the driver is still standing at the door. This is what dynamic route optimisation means in practice, and it is the layer visibility alone never provides: a tracking screen would have displayed all three failures beautifully, in real time, while changing nothing.
It is also where the outcomes Finmile publishes actually come from. A 99.9% on-time rate is not the product of a better morning solve; it is the product of catching drift early enough to act on it. Cutting "Where is my order?" enquiries by 91% comes from updating customers before they ask. Taking POD approval from 12 hours to 15 minutes comes from judging proof at the doorstep, not at invoicing. Planning contributes; execution through the live day delivers.
What to ask vendors instead of watching the demo
Every routing demo looks the same: a map, coloured pins, an impressive solve time. If you accept that the 95% is where your money goes, your evaluation questions should live there too.
- "Walk me through 11:40, not 7am." An urgent order arrives mid-day. Show me, on screen, how the system chooses which route absorbs it, and what it does to the stops around it.
- "Who notices drift first, your software or my dispatcher?" If the honest answer is the dispatcher, you are buying a planning tool with a tracking screen attached.
- "Show me a bad POD being caught." Not the proof capture flow; the moment weak proof is rejected and the driver is asked to retake it, while they are still on site.
- "What can the system do without a human approving it?" Ask for the list of actions it takes autonomously under policy, and the list where it only recommends. The gap between those lists is your dispatchers' workload.
- "How many dispatcher touches per hundred stops, before and after?" Vendors serious about execution measure this. Vendors selling solvers will not know what you mean.
- "When the plan and reality disagree at 2pm, which one does your software believe?" It sounds philosophical. It is the whole category in one question.
A vendor that handles these comfortably is selling execution. A vendor that steers you back to the solve benchmark has just told you where their product stops.
Frequently Asked Questions
Isn't route optimisation the most important part of delivery software?
It is important, but it is the opening move. Most delivery cost and most service failures appear after the route is published, so the platform's ability to manage the live day usually matters more to the outcome than the initial solve.
What does "execution" mean in logistics software?
Execution is the software's ability to change outcomes during the day, taking or guiding the next action when routes, proof, dwell time, or promises start to drift, rather than only showing status after the fact.
How do I test a vendor on execution, not just planning?
Ask to see route-change handling, weak-proof handling, urgent-insert handling, and policy-based exception decisions, not just the initial plan screen. Ask how many dispatcher touches disappear after go-live.
Is the 95% figure a measured statistic?
No, it is an operator's shorthand, and we use it deliberately. Count the decisions a delivery day demands: one route solve per vehicle in the morning against hundreds of live calls on inserts, drift, proof, and customer promises after departure. The exact ratio varies by operation; the imbalance does not.
If execution matters more, does the quality of the route solver still matter?
Yes, because a weak plan forces the execution layer to spend its capacity correcting avoidable errors instead of absorbing genuine surprises. The point is not that planning is worthless; it is that planning quality has converged across serious vendors while execution capability has not, so execution is where platforms now actually differ.