Why AI delivery route optimization breaks on real data
Classic failure: the algorithm produces a beautiful plan for 40 vehicles, and by noon the dispatcher is manually reshuffling half the routes.
The reason is that route planning is based on a static road graph, while reality depends on road closures, seasonal traffic, and weather that simply are not in the input model.
The gap between estimated travel time and observed travel time is usually the largest source of error, and it drags everything else with it.
Input data quality produces a second round of discrepancies. Different address spellings, coordinates at building centroids, missing floor and entrance — and the point on the map is where the vehicle cannot stop.
Normalizing the address directory, linking to entrances, and a separate layer of historical unloading time measurements deliver more improvement than any complication of the solver itself.
Cargo and delivery window constraints add rigidity that cannot be violated.
Vehicle weight and dimensions, compatibility of product groups, refrigerator operation, point operating hours, and closed receiving intervals — each such link makes the task not "find the shortest path" but "stay within the feasible set." This is also where dispatching bottlenecks surface: the same vehicle is needed by two customers with incompatible windows, and the solution has to be found with backtracking.
Manual dispatcher edits are not sabotage but a signal. They see context that is not in the data: the customer asks to arrive earlier, the driver's shift is ending, unloading at the site today is only until noon.
If edits do not return to the model, delivery route optimization degrades: the plan becomes ever more precise on paper and ever further from the yard. Next we break down how this is closed.
What changes after implementation: effect in measurable metrics
The effect of route optimization is measured not by feel but by metrics captured on historical data before launch and repeated on the same order volume after launch. Below is the set we record in the report for each delivery loop.
- Mileage reduction — total kilometers on a comparable number of stops drops by 8–15%: the routing engine builds chains by time and geometry, not in the order requests arrive.
- Empty runs — the share of trips without cargo goes down because backhaul loading is planned in the same pass, not through a separate dispatcher call.
- Share of late deliveries by delivery windows — calculated by actual arrival at the stop; hard windows and customer priorities are set by constraints, so the plan does not fall apart at the first traffic jam.
- Dispatcher workload — time spent on manual edits drops from hours to minutes: the system rebuilds the day when a window is missed, and the person confirms the changes.
- Evenness of load — the spread of stop count and weight across vehicles decreases, and extreme route overloads disappear.
Metrics are collected automatically, so the effect is visible in dynamics by week, not once in a presentation.
The calculation core on Google OR-Tools calculates the plan — it iterates through options under the given constraints and returns several equivalent solutions to choose from.
Operating modes: online recalculation, batch calculation, hybrid
The planning mode is chosen not by taste but by two values: how often new orders appear in the system and how expensive it is to change an already agreed route.
Recalculating a route at the moment an order arrives gives minimum mileage, but every change has to be confirmed with the driver and customer. Infrequent batch calculation is cheaper to maintain, but reacts worse to load spikes in the middle of the day.
| Option | When it fits | Constraints |
|---|---|---|
| Online route recalculation | Orders flow in all day, delivery windows are short, the set of stops changes dynamically | Requires a fast solver and a constant channel to the driver; too frequent plan edits unsettle the field staff |
| Batch route calculation | Orders are collected in advance, delivery is for the next day, the fleet is stable | There is no plan until launch; an urgent order in the middle of the day breaks already built routes |
| Hybrid planning | The main volume is planned, but urgent insertions appear regularly | Harder to configure: rules are needed for what exactly may be rebuilt and how often |
In practice, the choice of optimization mode comes down to recalculation frequency.
We measure how many orders arrive after the shift starts, what percentage of cancellations of already assigned stops is acceptable for the dispatch office, and how quickly the driver confirms a new task — based on these numbers the mode is either locked in or changed.
Hybrid planning is almost always built on splitting the route: a rigid framework with addresses and time windows is fixed, while the free part — incomplete slots, on-the-way stops — is recalculated on an event basis.
Recalculation frequency becomes an adjustable parameter: once an hour for the planned loop, instantly for urgent orders, with a ban on touching routes where the driver is already en route.
Implementation stages: from data audit to handover to operation
Implementation is split into short stages with a verifiable result after each.
The order is not accidental: planning rules cannot be configured before it is clear what constraints exist in the data at all, and checking plan quality is pointless before dispatchers have agreed with the calculation logic.
- Delivery data audit. We export route history, stop addresses, recipient time windows, cargo weight and dimensions, and driver work schedules. We calculate the share of addresses without precise geolocation, orders without a window, and duplicate stops — it is these gaps that produce unrealistic deadlines in the calculation.
- Solution design. We determine what the system calculates and what remains with the human: hard constraints (load capacity, shift time, travel prohibitions) and soft preferences (regular customers, even vehicle load). We fix what exactly we optimize — mileage, number of vehicles, or window compliance.
- Planning rule configuration. The rules the dispatcher keeps in their head are translated into formal constraints and weights. We check each one for conflict with the others, separate disputed pairs by priority so that the calculation does not "hang" on mutually exclusive conditions.
- Validation on historical routes. We run the plan on closed periods and compare with actuals: mileage, late arrivals, number of vehicles used, share of manual edits. We review discrepancies together with dispatchers, refine the rules, and repeat the cycle until deviations become explainable.
- Pilot launch at one site. One branch or shift works in the system in parallel with the usual planning: we compare results in real time and remove dispatcher objections before changing the process entirely.
- Handover to operation. We transfer the configuration, regulations, and manual edit procedure, train dispatchers on their own routes, and fix roles and access rights. After that comes support and fine-tuning of rules based on actual data.
What we hand over: configurations, diagrams, and regulations
We hand over not a "black box" but a system that your team can develop and maintain independently.
Planning rules are placed in configuration, access is described by roles, and failure behavior is fixed in regulations — routine changes do not require contacting developers.
- Planning rule configuration: customer priorities, time windows, vehicle load capacity and compatibility, penalties for window violations — edited in a separate file without rebuilding the system.
- Data flow diagram: the path of a request from the accounting system through address validation and distance matrix calculation to a finished route in the dispatcher interface — with failure points and retries when external services are unavailable.
- System access policies: roles of dispatcher, logistics specialist, analyst, and administrator, visibility by branch, action log, and the procedure for granting rights.
- Solution documentation: algorithm constraints, parameter reference, procedure for updating maps and tariff zones.
- Dispatcher operating regulations: acceptance of a recalculated route, handling of unrecognized addresses, conditions for moving an order to manual planning.
- Set of checks and metrics: test scenarios on historical days, report on the share of automatically built routes and deviations from the plan.
We hand over the kit together with training for your specialists: we go through the configuration, run typical failures, and fix who to contact with questions on each block.
Case: delivery fleet after switching to AI route planning
Case: distributor with its own fleet and two warehouses
Baseline
Planning relied on a dispatcher: they collected requests, spread stops across vehicles in a spreadsheet, and manually resolved delivery window overlaps. Morning edits alone took about three hours, and by noon urgent orders appeared — and some routes were reshaped on the fly.
Vehicles drove across the whole city, mileage grew, on-time delivery stayed around 87%, and drivers passed some stops out of the way.
What we changed and what we got
The model was built on route history, actual travel times, and unloading downtime; we added constraints: delivery windows, load capacity, driver work schedules, and customer priorities.
The plan is calculated several days ahead and fully recalculated when an urgent order arrives — the dispatcher sees not the whole picture, but only the stops that broke it. Manual adjustments remained for non-standard cases, but became targeted rather than daily.
- Mileage per route decreased by 18% with the same order volume.
- The number of routes decreased by 12%: some stops were combined into one trip.
- On-time delivery increased from 87% to 98%, and late arrivals due to planning almost disappeared.
- Dispatcher time for manual adjustment — from three hours to half an hour per shift.
- Cancellations due to shifted delivery windows were cut in half.
Such a gap between "before" and "after" comes not from a separate formula, but from linking the model with real fleet constraints and a clear plan recalculation process.
How streaming optimization differs from batch recalculation
Batch route recalculation works in windows: requests are exported from the accounting system, the solver calculates the travel time matrix across the whole pool, and returns the finished plan as a whole.
The plan is stable and explainable, but within the window the system sees neither a new order nor a cancellation — everything waits for the next run.
Streaming optimization keeps the route alive: a request or failure enters the queue, only the affected segment is recalculated, and the update reaches the driver within seconds.
Reaction speed to failure increases, but the mode requires discipline on the stability of the issued route.
| Criterion | Batch recalculation | Streaming optimization |
|---|---|---|
| Reaction speed to failure | until the next plan window | seconds, recalculation of the affected segment |
| Data volume per cycle | full export of requests and matrix | only the delta: new request, status change |
| Route stability | high, the plan does not change within the window | set by shift thresholds |
| Exchange with accounting system | batch exchange on schedule | events and back-writing of statuses |
Stability is the main trade-off. In streaming mode, we fix already dispatched stops, limit the number of permutations per route, and set a shift threshold: while the travel time gain is below the threshold, we do not touch the plan. Otherwise the driver receives a new route every few minutes and stops trusting it.
Exchange with the accounting system goes both ways; only the frequency differs. Batch is suitable when orders arrive in waves; streaming when reaction to a failure in the moment matters.
A hybrid is assembled more often: a night window builds the base plan, and daytime adjustments make targeted edits.
Technical concerns: data, integrations, and dispatcher control
Before launch, customers ask the same questions: what to do with incomplete road situation data, how to fit into an already deployed planning system, and whether manual route confirmation will remain with the dispatcher.
What to do if road situation data is incomplete?
We do not build a plan on a single source. We take route schedules and constraints from the accounting system, the road graph from open maps, for example OpenStreetMap, and accumulate actual travel time from the history of completed orders.
Where there is no data, the system calculates not an average across the city but a range: the plan is built on a conservative estimate, and actuals refine the forecast on subsequent routes.
We already have a planning system deployed — will it have to be replaced?
No, the optimizer sits alongside the current loop. Integration with the accounting system goes through file exchange or a software interface, and the existing order distribution logic remains operational.
We make the transition by vehicle groups: if the result is worse in time or mileage, the group returns to the previous mode without stopping delivery.
Will the dispatcher be able to edit the route manually?
Yes, and this is part of the system, not a workaround. The flexibility of rules is set by priorities: customer interval, cargo weight, no-turn restrictions, driver constraints.
The dispatcher sees why the route formed the way it did and can fix a segment — manual confirmation is saved as a rule and taken into account in subsequent calculations.
Let's discuss the task: what is needed for the first stage
Assessment of a delivery project begins not with access to your planning system, but with exports and a description of constraints.
It is enough for us to understand what data already exists, how it is structured, and where route calculation will run into real warehouse rules rather than mathematics. The more precise the input data, the fewer assumptions in the first-stage plan.
- Export of historical routes for several weeks: stops, arrival and departure times, actual mileage, order weight and volume.
- Fleet composition: vehicle types, capacity by weight and volume, warehouse assignment, driver shift patterns — this determines which routes are permissible at all.
- Delivery windows by customer and groups: hard intervals, soft tolerances, lunch breaks, ban on nighttime unloading.
- Cargo constraints: incompatible categories in one vehicle body, temperature modes, requirements for securing and unloading order.
- Priority rules: who receives an order first when there is a vehicle shortage, for whom a time shift is unacceptable.
- Address directory with coordinates, zones, and entry restrictions for heavy transport.
- Time standards for loading and unloading by stop type — without them the model systematically underestimates route duration.
Based on this data, we assemble a calculation model, compare it with historical routes, and show on specific days exactly where mileage and time are lost.
Then we return with a first-stage plan: what we launch at a limited site, which indicators we fix before start, and how we compare the result with current manual planning. Describe the task — we will return with an assessment and a plan.