Route optimisation gets sold as magic and bought as maths. It is neither. It is a search process that trades one cost against another according to rules you set — and if you set them badly, it will confidently produce a terrible plan.
The problem in one paragraph
You have a set of customers to visit, each at a location, each needing a certain amount of time and space in a vehicle, some of them only available in certain hours. You have vehicles with capacities, drivers with shift limits, and one or more depots. There are astronomically many ways to divide the work and sequence it. Optimisation is the process of searching that space intelligently and stopping when further searching is not worth the time.
For twenty stops there are more possible sequences than atoms in the observable universe. This is why nobody solves it exactly and why "optimal" in vendor marketing always means "very good, found quickly".
Spending a month cleaning master data will improve your routes more than spending a year choosing between two optimisation engines.
Why the shortest route is usually the wrong target
Ask an engine to minimise distance and it will happily produce a plan that arrives at three customers outside their windows, keeps two drivers on overtime and leaves one van 90% empty. Distance is easy to measure, which is why it dominates demos, and it is rarely the thing you actually pay for.
The costs a real operation cares about:
| Cost | Why it matters | How it changes the plan |
|---|---|---|
| Driver hours | Usually the largest line | Favours fewer, denser routes |
| Overtime premium | Non-linear and painful | Pushes work off long routes onto short ones |
| Fuel and distance | Visible and easily measured | Favours geographic compactness |
| Vehicle count | Fixed cost per van per day | Favours fuller vehicles, longer days |
| Failed deliveries | Redelivery cost plus goodwill | Favours respecting time windows |
| Service consistency | Same driver, same time, same customer | Constrains the optimiser deliberately |
Good products let you weight these. Great products let you weight them differently by day, depot or customer segment. Weak products give you a single "optimise" button and hide the objective function entirely — which is fine right up to the moment the plan looks wrong and nobody can explain why.
The five inputs that decide plan quality
In practice, plan quality is determined far more by input quality than by algorithm quality. In roughly this order:
- Geocode accuracy. A pin dropped on the postcode centroid instead of the loading bay puts a stop on the wrong side of a dual carriageway and quietly adds ten minutes. See address data quality.
- Service time. If you model every stop at a flat 8 minutes and the real spread is 3 to 40, no algorithm can save the plan. See service time estimation.
- Travel time model. Time-of-day-dependent road speeds versus a flat average is typically worth more accuracy than any solver upgrade.
- Constraints that reflect reality. Vehicle access restrictions, customer-specific requirements, driver skills and licences, legally mandated breaks.
- Demand data. Correct weights, volumes and pallet counts. Capacity constraints built on guessed volumes produce plans that fail at the loading dock.
How the engines actually work
You do not need to implement one, but knowing the vocabulary stops vendors hiding behind it.
Construction heuristics build an initial solution fast. Savings algorithms, nearest-neighbour insertion and sweep methods are the classics. They get you to "reasonable" in milliseconds.
Local search then improves the solution by trying small changes: move a stop to another route, swap two stops, reverse a segment. Repeat until no small change helps.
Metaheuristics stop local search getting trapped in a mediocre solution. Tabu search forbids recently-undone moves; simulated annealing occasionally accepts a worse solution to escape a dead end; large neighbourhood search destroys part of the solution and rebuilds it. Most commercial engines use some blend of these.
Exact methods — branch and bound, column generation — prove optimality but only for small or specially structured problems. If a vendor claims mathematically optimal solutions for 800 stops in 30 seconds, ask what they mean.
More detail in our routing algorithms explainer.
Assignment versus sequencing
Two different decisions get conflated constantly:
- Assignment decides which vehicle serves which customers. It is the high-value decision and the one most affected by territory design.
- Sequencing decides the order within a route. It is the visible decision, the one drivers argue about, and usually worth a few percent.
If your operation runs fixed territories with stable customers, you have already made the assignment decision — possibly years ago, possibly badly. Re-optimising sequence within a bad territory is polishing. Look at territory design first.
What good looks like in a demo
Give the vendor 200 of your real stops with your real constraints and watch for:
- Does it produce a plan a planner would recognise as sensible?
- When you add an impossible constraint, does it explain the infeasibility or silently drop the stop?
- Can you lock a stop to a driver and re-optimise everything else around it?
- How long does a full re-run take at your real volume, not their sample?
- Can you compare two scenarios side by side with cost, distance, time and vehicle count?
The last one matters more than it sounds. Optimisation is only useful if you can see what you traded away.
Realistic expectations
Published results and operator experience converge on a similar picture. Moving from unstructured manual planning to a competent engine commonly yields 5–15% distance reduction and 5–10% fewer vehicle-hours in the first year. Where planning is already good, gains fall to low single digits — and the real return shifts to consistency, planner time saved, and the ability to absorb volume growth without adding routes.
Anyone quoting you 30% without asking about your current planning maturity is quoting a marketing number.
Frequently asked questions
How long does an optimisation run take?
For a few hundred stops, seconds to a minute or two. For several thousand stops with complex constraints, minutes to tens of minutes. What matters operationally is whether a re-run fits inside your planning window after a late order batch arrives — test that, not the headline speed.
Should I optimise every day or keep fixed routes?
Depends on demand volatility. If the same customers need the same service most weeks, fixed master routes with periodic re-optimisation give you consistency, driver familiarity and easier settlement. If order sets change substantially day to day, dynamic planning wins. Many operations run a hybrid: fixed backbone, dynamic overflow.
Can the engine take traffic into account?
Modern engines use historical speed profiles by road segment and time of day, which is what you want for planning. Live traffic matters for execution and ETAs rather than for the overnight plan, since conditions will have changed by the time the driver gets there.
Why does the optimiser keep sending drivers past each other?
Usually a time-window or capacity constraint forcing it, or a service-time model that makes one route artificially short. Sometimes it is correct and counter-intuitive. A product that cannot explain the reason is a product your planners will eventually stop using.
Do I need optimisation if I only have three vans?
Probably not for the routing itself. At that scale you need the execution layer — manifests, proof of delivery, ETAs — and a sensible territory split you can review twice a year.
