The Router Is Not the Clever Part. Your Address Data Is

A salesperson shows you a map with lines on it that reorder themselves, calls it AI, and quotes a monthly figure per vehicle. Before you sign anything, it is worth knowing that the mathematics behind that animation has a name, a research literature going back to 1959, and a free reference implementation maintained by Google. The interesting question is not whether the product works. It is which part of it is the part you are paying for.

This is not a debunking. Route optimisation genuinely saves money, often a lot of it. But the savings come from the solver and from your data, and the word AI on the invoice is usually describing the former with a newer noun.

What problem are you actually solving?

One of about five, and naming yours correctly is the most useful thing you can do before talking to a vendor. They are variants of the same underlying problem and they need different things.

Capacitated routing is the base case. Vehicles have a limit, stops have a demand, and the question is how to cover every stop without exceeding any vehicle. If your constraint is pallets, kilos or crates, this is you.

Time windows arrive the moment customers can only receive between certain hours. This is a much harder problem, because a route that is efficient in distance can be infeasible in time.

Pickup and delivery adds precedence: you cannot drop something you have not collected, and both stops must be on the same vehicle. Anything that moves an item from A to B rather than out from a depot lives here.

Multi depot applies when you load from more than one place, which changes the shape of the answer rather than just its size.

Dynamic routing is the one people underestimate. Orders arrive after the vans have left. This is where daily operations actually live and where most software quietly reverts to manual intervention.

How small is a real example?

Smaller than you would think, which is why you can sanity check a vendor's claims yourself. Google publishes worked examples for its open source solver and they are concrete enough to reason about.

In the capacitated example there are 17 locations with demands running from 0 up to 8 units, and four vehicles each capped at 15. Total demand is 60, which is exactly four full vehicles, so the problem has no slack at all. The solver reports a total distance of 6,208 metres, with each vehicle covering 1,552 metres. Every vehicle finishes full.

The time windows example uses the same 17 locations and four vehicles, but swaps distances for a travel time matrix, allows 30 units of slack and caps each route at 30 time units, producing a total of 82 minutes across all four routes. It also introduces the concept that trips up every newcomer.

Why does a stop have two different time windows?

Because the window you promised the customer and the window the plan can actually honour are not the same interval, and confusing them is the most common misreading of a solver's output.

The constraint window is what you told the customer: this location must be served between these hours. The solution window is narrower, and it is computed. Google's documentation gives a clean case: a location with a constraint window of 0 to 3 gets a solution window of 2 to 3, because the vehicle takes two units to reach it from the depot and cannot physically arrive earlier. The solution window sits inside the constraint window and is usually smaller.

That distinction has an operational meaning worth stating in plain terms. When a driver is running eleven minutes late, the question is not whether they are still inside the customer's window. It is whether they are still inside the solution window, because the solution window is what the rest of the day was built on. Software that shows only the first number will tell you everything is fine right up until the last three stops fail.

Where does learning genuinely help?

In a narrow band, and the research is more measured about it than the marketing. An experimental survey of learning based optimisation for vehicle routing, published by Bingjie Li and colleagues, divides the field into end to end approaches that emit a whole solution and step by step approaches that build one incrementally, then evaluates representatives of each. Its stated motivation is telling: existing learning approaches are limited in problem size or need manual intervention in choosing parameters.

Read that alongside the state of classical solvers and the practitioner conclusion follows. For the instance sizes a small or mid sized operation actually faces, a mature constraint solver is the default and a learned method is not obviously better. Where learning becomes interesting is when the same shaped instance recurs every single day and you need a new answer in under a second because a van broke down at eleven. A trained model can produce a good route almost instantly; a solver has to search again.

So the question to ask a vendor is not whether they use machine learning. It is how long a re solve takes at your instance size when the day changes, and what the plan does with the stops already completed.

What each variant needs from you

The part that decides whether any of it works

Your inputs, and specifically three of them. This is where these projects fail, and it never looks like a failure of the optimiser.

The travel time matrix. A solver needs the cost of going from every stop to every other stop, and that matrix is an assumption you supply. Routing engines are explicit that what they return is not the shortest geometric distance but the distance of the fastest route along real roads. The OSRM table service returns durations in seconds and distances in metres for each pair, along with a flag marking cells where no route exists and a fallback value was used. If your matrix ignores time of day, your morning routes are optimistic and your afternoon ones are pessimistic, and the plan will be wrong in a way that looks like driver performance.

Service time at the stop. How long does it take to park, carry, hand over and get back in the van? Almost everyone guesses this once and never revisits it. On a route with forty stops, a three minute error per stop is two hours, which is larger than any saving the optimiser will find. This is the single cheapest measurement to improve and the one most often skipped.

Geocoding. An address that resolves to the wrong side of a river, or to a street centroid rather than a building, inserts a plausible error into every route touching it. These errors are invisible on a map at normal zoom and they are permanent until someone fixes the record.

What the savings actually come from

Three sources, and they are not equally available to everyone. Knowing which one applies to you tells you whether the business case is real before you run a trial.

Fewer kilometres for the same stops. This is the saving everyone quotes and the smallest one for most operations. If a human planner who knows the territory has been doing this for years, a solver typically finds a modest improvement rather than a dramatic one. The dramatic numbers in case studies usually come from operations that were routing alphabetically or by postcode, which is a real starting point and not a common one.

Fewer vehicles for the same work. Much larger, and much harder to realise. If the optimiser shows that four vans can do what five are doing, the saving is a whole vehicle and a whole driver, but only if you can actually shed one. Most businesses cannot do that in the same month, and some cannot do it at all because the fifth van is the buffer that absorbs bad days.

Less planning labour. Consistently underrated. If someone spends ninety minutes every evening building tomorrow's routes, that is roughly two working weeks a year of a skilled person's time, and it is time spent on a task with a right answer. Automating it also removes the risk that the person who holds the territory knowledge in their head goes on holiday.

Work out which of the three is yours before the trial, because it determines what you should measure during it. A pilot that reports a distance reduction to a business whose real constraint is planner time has measured the wrong thing and will read as a disappointment.

Where the driver fits

Badly, if you skip this part, and it is the most common reason a good deployment gets quietly abandoned.

Experienced drivers know things the model does not: which loading bay is blocked at school run time, which customer needs the buzzer twice, which turn is legal on paper and impossible with a long wheelbase. A plan that overrides all of that without explanation gets treated as a suggestion within a fortnight, and once drivers are resequencing on the road your completion data stops matching your plan and the whole feedback loop dies.

The fix is not to make the software more insistent. It is to capture the exceptions as data. Every stop a driver reorders is a constraint somebody knows and the system does not, and a short weekly conversation about which stops moved and why converts folklore into rules the solver can respect. That is unglamorous change management rather than technology, and it is what separates the deployments that stick from the ones that produce a beautiful plan nobody follows.

How should you judge a vendor?

On three questions, and the answers are more revealing than any demo.

Ask which constraints they model natively rather than through workarounds. A product that handles capacity and time windows properly but fakes pickup and delivery with clever ordering will fall over on your first split job. Native means the constraint is in the model, not in the operator's head.

Ask what happens at eleven in the morning when a vehicle fails or a customer moves a slot. Every product routes well overnight when it has all night. The one that matters is the re solve with half the stops completed and the rest still promised.

Ask what the objective actually is. Minimising total distance, total time, total cost and driver fairness produce genuinely different plans, and only one of them is what your business wants. A product that will not tell you what it is minimising is a product whose plan you cannot argue with.

What this shares with the rest of your operation

The pattern is the one that keeps recurring in operational software. The clever component is commoditised and free; the value sits in whether your own records are accurate enough to feed it. We made the same argument about demand planning in a piece on what a forecast needs before it is worth trusting, and about method selection in the walkthrough of how to choose a forecasting method without a benchmark. Routing is the same shape: mature mathematics, freely available, bottlenecked on data hygiene.

There is a practical corollary for anyone whose stops come from online orders. The delivery address, the requested window and the order contents all originate at checkout, which means the quality of your routing is decided by what your store captures and how cleanly it exports. If that layer is a black box you cannot query, every routing improvement has a ceiling you did not choose. That is part of the argument for a store whose order data is yours to read and export, and it applies well before anyone mentions optimisation.

A note on what the free tools cost you

Nothing in licence fees and something real in attention, which is the trade worth understanding before treating open source as the obvious answer.

The reference solver is genuinely free and genuinely good. What it does not come with is a way for a planner to look at tomorrow, drag one stop, and see the consequences. It does not send the driver a sequence on a phone, it does not track completion, and it does not know that a vehicle is off the road. Those are the parts a commercial product is really selling, and they are the parts that take months to build badly.

So the honest framing of the buy decision is not solver against solver. It is whether you want to own the operational surface around a solver everyone shares. For an operation running two or three vehicles with a planner who already has a system, running the solver directly against a weekly export is often enough, and the results land in a spreadsheet the planner already reads. Somewhere above ten vehicles, or the moment drivers need live sequences, the surrounding software stops being optional and the build against buy question becomes real.

One thing to insist on either way: whatever you use, keep the ability to export your stop history with timestamps. That history is what lets you measure service time properly, calibrate your travel time matrix against what actually happened, and evaluate any future vendor on your own numbers. A product that will not give it back is charging you rent on your own operating record.

What to do first

Not buy anything, and certainly not a delivery route product on the strength of a demo. Measure service time on twenty real stops with a stopwatch, and compare the answer to whatever number your current planning assumes. Then export a week of stops and check ten geocoded points against a satellite view. Most operations find enough error in those two exercises to change their plans more than a solver would.

After that, download the open source solver and run your own week through the capacitated example structure. It takes an afternoon, it costs nothing, and it produces a number: the distance your current routes actually cost against what a competent optimiser finds. That number is the size of the prize, and it is the only honest basis for deciding what the software is worth to you. If it comes back small, that is a genuine result rather than a failed experiment: it means your planner is good and your money belongs somewhere else in the operation. If it comes back large, you now have a figure to negotiate against instead of a per vehicle price you have no way to evaluate.