Route optimization won't fix a badly planned day

Route optimization is the most oversold feature in delivery software and one of the most useful. Both things are true, and the gap between them is where fleets get disappointed.

The pitch is that you press a button and the day gets better. What actually happens is narrower: a solver takes the stops you gave it, the constraints you told it about, and the assumptions it made about everything you didn’t, and returns a shorter sequence. Shorter is good. Shorter is not the same as workable.

What it genuinely solves

Ordering stops is a problem humans are bad at and computers are good at. Past about fifteen stops, no dispatcher is finding the best sequence by eye, and past thirty nobody is close. A solver will routinely take 10–20% out of the distance on a route a person sequenced by hand, and it does it in seconds rather than the twenty minutes a careful dispatcher would spend.

It is also very good at the boring version of the same problem: re-sequencing after a change. Add three stops at 11am, and re-optimizing costs nothing. Re-planning by hand costs the rest of the morning.

Take those wins. They are real, and on a forty-stop day the distance saved is fuel, driver hours and one or two extra deliveries of capacity.

Where it goes wrong: the constraints it never knew

A solver optimizes what you told it to optimize, subject to what you told it. Every complaint about optimization output traces back to something the solver was not told.

Delivery windows. If windows are not in the data, you get a beautifully short route that arrives at the 9–11am stop at 2pm. Windows are the single most important constraint and the one most often missing.

Service time. The time spent at the stop, not driving to it. A solver that assumes three minutes everywhere will build an impossible day for a fleet whose average is eleven. This is the number that quietly wrecks more plans than traffic does.

Vehicle capacity. Volume, weight, pallet spaces, whether the load is refrigerated. Without it you get routes that cannot physically be loaded.

Driver and zone rules. Who is certified for controlled goods, who has the tail lift, who does not drive the north side. A solver with no rules will happily hand the pharmacy run to the driver who cannot legally do it.

Depot returns and breaks. A route that never returns to reload, and a driver who never eats, will both look excellent on a screen.

If the output looks wrong, the first question is not “is the algorithm bad?” It is “what did I forget to tell it?”

Service time is the number everyone guesses

Most fleets have never measured it. They assume, and they assume low.

You can get it in an afternoon. Take a week of completed stops and compute the median gap between arrival and completion, split by stop type — residential, business, apartment building, loading dock. The numbers usually surprise people: an apartment block with a buzzer and a lift can run three times a suburban doorstep.

Feed real service times back into planning and two things happen. Routes get slightly longer on paper and dramatically more achievable in practice, and your ETAs stop drifting after stop six.

Shortest is not always what you want

The solver minimizes what it is pointed at, usually distance or time. That is not always the business goal.

A fleet with tight windows wants the plan most likely to hit them, which may be longer. A fleet paying per mile wants distance down. A fleet with a fragile 4pm cutoff wants the risky stops early, even at a cost. A grocery run wants the frozen goods delivered first regardless of geography.

Know which one you are asking for. “Make it shorter” is a specific instruction and sometimes the wrong one.

Where the dispatcher still wins

A dispatcher knows the things that are not in the data and probably never will be. That the Tuesday delivery to the school has to land before the bell. That the customer on Oak Street signs for the whole terrace. That the new driver should not get the industrial estate on day one. That the loading bay on Mill Road is impossible after 3pm.

This is why optimization should propose, not apply. The right workflow is: solver produces a plan, dispatcher sees it as a list and on a map alongside the current one, changes the two stops that local knowledge says are wrong, applies it. That takes ninety seconds and it is the difference between a tool that people trust and one that gets switched off after a fortnight.

Any tool that re-sequences the day without a review step will eventually make one confident, expensive mistake, and after that nobody uses it.

The honest test

Run it in parallel for a week before you believe anything. Plan the day as you always do. Then optimize the same day and record what it proposed. At the end of the week compare four numbers: planned distance, actual distance, stops completed, and windows missed.

If optimization would have saved distance without costing windows, adopt it. If it saved distance and cost windows, your constraints are incomplete — go back and add service time and windows before you judge the tool. If it saved nothing, your routes are already dense and well sequenced, which is worth knowing too.

What to do about it

1. Put real delivery windows on orders. Nothing else matters as much.
2. Measure service time by stop type and use the measured number.
3. Encode vehicle capacity and driver rules once, properly.
4. Optimize as a proposal, reviewed on a map, applied by a human.
5. Re-optimize freely during the day — that is where the compounding value is.

Do those five and optimization stops being a demo feature and starts taking real time out of the day. Skip them and you have a button that produces short, impossible routes.

PrivateMile proposes a shorter stop order that respects delivery windows, shows it as a list and on the map next to the current plan, and applies it only when you say so — then updates the driver’s app and recalculates ETAs. But the five points above apply to whatever you run.