Route optimization for a real fleet

The solver is not the problem

A fleet of ten to two hundred vehicles — a food distributor, a linen service, an HVAC contractor, a beverage wholesaler, a waste hauler — has a genuine routing problem worth real money. It is almost never a mathematics problem. Good vehicle routing solvers are open source, mature, and will produce an excellent answer to the question you give them in a few seconds. The trouble is that the question you give them is usually wrong in ways nobody notices, and the plan then fails on contact with a driver who knows something the model does not.

Every routing project we have seen fail did so in one of three places: the service times were fiction, a constraint that mattered was never written down, or the savings existed on paper and never appeared in a cost account. None of the three is fixed by a better algorithm.

Service time is the number that decides everything

On a dense route with thirty to fifty stops, drive time is often the smaller half of the day. Three hours of driving against four or five hours of service is a common shape for a delivery route inside a metro area. Yet almost every routing setup we are asked to look at uses a single flat service time for every stop, usually a round number somebody chose years ago.

The real distribution is wide and it is not random. A ground-floor dock with a waiting receiver is six minutes. The same case count into a basement kitchen down an alley with a freight elevator and a manager who has to count every carton is thirty-five. A restaurant that will not sign before ten. A grocery with one receiving bay where three carriers arrive at seven and two of them wait. That spread is not noise — it is a property of the customer, and it is stable enough to estimate.

Which makes this the highest-return work in the entire project and the least interesting. If you have telematics or electronic logs, you already have arrival and departure timestamps for every stop for the last year or two. Fit per-customer service times from that history, with the case or unit count as a driver, and keep an uncertainty band. A route built on estimated service times that are right within a few minutes is a route drivers can run. A route built on a flat eight minutes when the truth ranges from four to thirty-five is a plan that fails around two in the afternoon, every day, and gets blamed on the drivers.

The constraints nobody wrote down

Sit with a dispatcher for two days and write down every reason they move a stop. The list is longer than anyone expects and almost none of it is in any system.

This customer only accepts deliveries between six and nine. That one has a gate code that only one driver has. This restaurant will not take a delivery during lunch service and the owner will call your general manager if you try. The turn into that industrial park cannot be made by a fifty-three foot trailer, so that stop goes on a straight truck. Tuesday is a double for the west side because of a standing order. This account is on credit hold and the driver has to collect. That driver has been running the north territory for eleven years and knows which docks flood.

Every one of those is a constraint, and a solver that does not know about them will produce a plan that is better on paper and worse in practice. The remedy is boring: capture them as data, one at a time, with an owner and a reason attached. Vehicle-customer compatibility, driver-customer familiarity, mandatory sequencing, standing appointment windows, equipment requirements. Most fleets need thirty to eighty such rules, and collecting them is a few weeks of somebody's attention rather than an engineering task.

The failure to plan for is discovering them one at a time after go-live, because each discovery costs you credibility with dispatch and after four or five of them the plan gets ignored.

Time windows are mostly negotiable, and that is where the savings are

Customer time windows are the most binding constraint in most routing models and the least examined. A large share of them were set once, years ago, often by a customer who had been burned by a late delivery and asked for a tight window as insurance. Nobody has revisited them since.

Before improving the algorithm, run a simple experiment: relax the windows on the twenty accounts that constrain the most routes and see what the plan does. If widening fifteen windows by two hours saves more than any solver tuning you can do — and it frequently does — then the project is a customer conversation, not a software build. Some of those customers will say no. Several will not care, because the person who asked for the window left in 2019.

This is the kind of finding that makes a routing engagement worth the money even when no software gets built, and it is also the finding a software vendor has no incentive to surface.

Drivers decide whether the plan is real

A route that is six percent shorter but reverses the order a driver has run for eight years will not be run. The driver will do it their way, deliveries will still happen, and your system will report compliance against a plan nobody followed. That is worse than no system, because now the reporting is fiction too.

Three things help, and none of them is persuasion. Put territory and sequence stability into the objective as a real penalty rather than an afterthought, so the optimizer only breaks a familiar pattern when the gain is worth it. Show the driver why the change was made, at the stop level, in one line. And give dispatch a first-class edit: move a stop, then re-optimize the remainder around that decision rather than throwing the plan away.

Then log every override. A dispatcher moving the same stop back every morning for two weeks is telling you about a constraint you failed to capture, and that log is the cheapest requirements-gathering instrument you will ever build. Review it weekly for the first two months and the override rate should fall as the model learns what the building already knew.

Measure against what dispatch actually did

The most common way a routing project overstates itself is the baseline. A comparison against a naive sequence, or against a solver run with the constraints removed, produces a large and meaningless number. The only baseline worth reporting is the routes your dispatchers actually built and ran, on the same orders, in the same weeks.

Re-run history. Take last quarter's actual orders, run them through the new planner with the real constraints, and compare plan against actual on miles, hours, stops per route and vehicles used. Then be honest about what the comparison omits — the day it snowed, the truck that broke down, the customer who called at ten to add a pallet.

Honest expectations, from experience rather than a brochure. A fleet that has never optimized, running routes inherited from a retired dispatcher, will commonly find high single digits to mid teens in miles. A fleet with an engaged dispatcher and stable, well-understood territories may find low single digits, and at that level the change management can genuinely cost more than the savings. Both outcomes are worth knowing before the software is bought, and finding out takes a few weeks of analysis rather than a deployment.

Turning miles into money, which is the part that gets skipped

A routing study that reports a twelve percent mileage reduction has not reported a saving. Mileage-linked cost — fuel, tyres, maintenance, some depreciation — is real but it is the smaller share of what a route costs. The larger shares are the driver's hours and the vehicle itself, and neither falls because a route got shorter.

There are three ways the saving becomes real, and every project should name which one it is targeting on day one.

The overtime one deserves emphasis because it is where mid-size fleets usually find the money and because it changes what you optimize for. Minimizing total miles and minimizing the number of routes that run long are different objectives. If overtime is the target, the model should be penalizing the tail of the duration distribution, not the mean, and the plan should be built with enough slack that a bad Tuesday does not push three routes past the shift.

The absorb-growth case is real and it is the hardest to defend internally, because the saving is a truck you did not buy. Write the counterfactual down before the project starts — here is the volume forecast, here is the vehicle count it would have required — or you will be arguing about it a year later with no evidence.

Start static, and be suspicious of real-time

Three levels, and most fleets should stop at the second for a good while.

Master route rebuild. Rebuild the standing territories and day-of-week assignments once or twice a year. For a fleet with recurring customers on fixed schedules — most distribution, most service businesses — this captures the large majority of the available improvement and requires no daily system at all. It is a project, not a product.

Daily planning. Optimize tomorrow's orders inside today's territories overnight, with dispatch reviewing in the morning. This is the right target for most fleets in the ten-to-two-hundred range, and it fits the way the work already flows.

Dynamic re-routing. Re-planning during the day as orders arrive and traffic changes. This is where projects die. It demands live position data everyone trusts, a way to communicate changes drivers accept mid-route, and an answer to what happens when a driver is already ninety seconds from a stop you just moved. There are businesses that need it — same-day courier, on-demand service dispatch. Most distribution fleets do not, and adopting it early converts a manageable project into a hard one.

Buy before you build, usually

Commercial routing software is a mature category and most fleets should buy it. That is an unhelpful thing for an engineering firm to say and it is true. Building a routing product from scratch to compete with packages that have had twenty years of edge cases poured into them is rarely a good use of anyone's capital.

Building or heavily customizing earns its place in specific situations. Constraints the packages cannot express — multi-day routes, mixed fleets with unusual compatibility rules, technician skill matching, regulated equipment. Deep integration with an order system where the routing is one step in a longer automated flow. Cases where the routing decision is inseparable from a pricing or capacity decision the package knows nothing about. And the very common case of needing the analysis, the service-time model and the constraint capture, and then feeding those into a package you already own — which is frequently the highest-value engagement available, because most fleets are running good software on bad inputs.

When you should not do this at all

Under about ten vehicles with stable routes. A good dispatcher with local knowledge will beat a badly implemented system, and the coordination cost of a new tool is a real expense. Spend the money on service-time data and better time windows instead.

Highly variable one-off work. If every day is a different set of locations with no repeat customers, the master-route logic does not apply and the value shifts to dispatch tooling and communication rather than optimization.

The constraint is capacity, not routing. If you are turning away work because you do not have trucks or drivers, no sequencing improvement fixes that, and a routing project will produce a plan that says you are already efficient.

Nobody owns dispatch. If routing decisions are made by four people with different rules, unify that first. An optimizer with four owners will be overridden by all of them in different directions.

A sequence that works

Steps three and four routinely settle the question of whether to proceed. A fleet that finds three percent against its real baseline, with binding windows that customers will not move, has learned something valuable for the cost of six weeks of analysis rather than a year of implementation.

The mistakes we get called in to fix

• One flat service time for every stop, so every plan collapses in the afternoon
• Savings measured against a naive baseline nobody would ever have run
• Miles reported as money, with no route removed and no overtime hour eliminated
• Sequence churn every morning, so drivers stopped reading the plan in week two
• Constraints discovered one at a time after go-live, each one costing credibility
• Dynamic re-routing attempted first, before daily planning was working
• No override log, so eighteen months on nobody can say what the model keeps getting wrong

Before you start

• Per-customer service times are estimated from history, not assumed
• The unwritten constraints are captured as data with an owner for each
• The baseline is what dispatch actually ran, on the same orders
• The savings mechanism is named: remove a route, cut overtime, or absorb growth
• Territory and sequence stability carry a real penalty in the objective
• Dispatch can move a stop and re-optimize the rest, not just accept or reject
• Overrides are logged and reviewed weekly for the first two months
• Time windows were tested for negotiability before the model was tuned
• Someone owns dispatch, and that person is in the project

Bottom line

Fleet routing is an operations project with a small algorithmic component in the middle of it. The three things that decide the outcome are whether you know how long a stop takes, whether you captured what the dispatcher knows, and whether you named in advance how a shorter route turns into a smaller cost. Get those and a commodity solver is more than enough. Skip them and the best optimizer available will hand you a beautiful plan that the drivers quietly ignore, and a report that says it is working.

Frequently asked questions