AI optimization of logistics routes: reducing mileage and costs

AI route optimization: where mileage goes and delivery windows are missed

A shift starts with hundreds of addresses from which routes must be assembled subject to delivery windows, tonnage, dimensions, and driver working hours.

Manual planning is sequential: the dispatcher distributes points by zones and fills the vehicle until it hits the limit — so neighboring addresses go out on different routes.

At 40–60 stops per route, manually enumerating options is no longer possible: feasible combinations are orders of magnitude more than the dispatcher can check in a shift, and excess vehicle mileage grows with the number of points.

The bottleneck in routing is not a shortage of vehicles but a conflict of constraints. Hard delivery intervals, weight, volume, unloading time, breaks, and truck access restrictions cannot be optimized one by one: improving one metric breaks another.

Planning rules hardcoded years earlier — fixed districts, “each vehicle on its own direction” — diverge from the actual demand map.

Data on points is also fragmented: addresses without coordinates, windows in free-text comments, travel time from averaged reference books instead of actual measurements by hour and day of week.

Hence systematic overspend, not a one-off dispatcher error: mileage above optimal, missed delivery windows on some routes, manual edits right on the road.

We explain how this is closed: how constraints are moved into an explicit model, where actual travel times come from, and why the problem is solved by enumeration with pruning of infeasible options rather than a “by zones” heuristic — for this, solvers for the fleet routing problem class are used, e.g. Google OR-Tools.

Implementation effect: mileage, vehicle utilization, missed windows

We measure the effect not from ideal math but from a baseline: two to three weeks of telemetry before implementation, the same order nomenclature, the same windows, and the same fleet.

Such a comparison shows the planner's contribution to the result, not seasonal demand fluctuations — otherwise the numbers cannot be defended before management.

A separate result is an eliminated class of failures where being late to one point breaks the entire route: the driver reaches the customer outside the window, the customer postpones acceptance, the remaining addresses shift in a cascade.

The planner holds time and capacity constraints simultaneously, so such chains are simply not assembled, and missed windows cease to be a mass phenomenon.

We build the road graph and constraints on open OpenStreetMap data adjusted for actual tracks and access restrictions, so the arrival estimate does not diverge from reality. We take measurements on the same telemetry by which the result is later accepted.

Window predictability is more important than an absolute minimum mileage: a route that consistently fits the intervals removes manual control. The dispatcher deals with exceptions rather than rebuilding the shift.

Optimization formats: online recalculation, nightly batch, hybrid

The calculation mode is chosen not by the algorithm's “power” but by the shift rhythm and input data quality.

If orders arrive during the day and addresses and volumes change on the fly, online recalculation is needed; if the route is fixed for a day and data is confirmed in advance, batch is more stable. Below is a comparison of routing approaches by applicability and limitations.

The boundaries between modes are set not by calculation logic but by change tolerances: how many edits per shift the dispatcher, driver, and customer can withstand.

Hybrid is adopted where an online loop is needed but constant rebuilding gets in the way — the deviation threshold and edit limit per route keep the plan predictable.

If the status flow is incomplete or delayed, the online loop produces garbage routes: first data collection is set up, then recalculation is enabled.

How implementation is structured: from data audit to handover

We structure the stages so each ends with an artifact that can be checked before moving to the next.

We start not with the algorithm but with data and rules: if exports lack actual arrival times at points or branch time zones diverge, routing will produce a schedule that the dispatcher cancels on the second day.

Routing implementation stages

1. Logistics data audit. We collect exports from the accounting system, telematics, and waybills, verify completeness by periods, look for duplicates, geofence gaps, and trips without closure.
2. Constraint formalization. Delivery windows, body type and capacity, driver working hours, customer priorities — we consolidate into a single schema and agree it with dispatchers, not with their idea of the process.
3. Geodata preparation. We normalize addresses, map points, fix broken coordinates, build a warehouse and transport reference.
4. Objective function setup. We determine what we optimize — mileage, travel time, or load uniformity — and set penalty weights for window violations.
5. Validation on historical data. We run the solution on past routes and compare the plan with actual: where the discrepancy is explainable and where it points to a gap in the rules.
6. Handover to operation. Dispatchers get a workstation with manual correction, a deviation review procedure, and metrics that show planning quality day by day.

Documentation and handover: configurations, schemas, procedures

We hand over not a running service but a kit your team can work with independently. We store configurations as text in version control, describe schemas in words rather than leaving them in engineers' heads. Below is what exactly remains with the customer.

• Routing configuration: constraint matrix — delivery windows, tonnage and dimensions, temperature mode, prohibited segments, customer priorities.
• Routing schemas: how orders are distributed across routes and where the boundary lies between dispatcher decision and automatic calculation.
• Dispatcher access roles: who changes constraints, who only confirms, who can override the route manually, and how it is recorded.
• Rule update procedures: edit initiator, validation against past days' history, safe rollback to the previous configuration version.
• Route documentation: description of fields, references, exchange formats with accounting and warehouse systems, including discrepancy analysis.
• Override log: what dispatchers changed, where, and why — the basis for the next rule revision.
• Operating manual: typical failures, what to check first, whom to contact.

Before handover we review each item together with dispatchers and your engineer: they change a constraint themselves and see the result. If an edit cannot be made without us, handover is not closed.

Implementation case study: mileage and missed windows before and after

Starting point

Routes were assembled in a spreadsheet by fixed zones: the dispatcher manually filled orders into already formed sheets, and point order was set by the driver's experience.

Under tight load, the first addresses went beyond the window, and the entire sheet then ran one to one and a half hours late.

At input, excess mileage relative to the calculated minimum held at 9-12%, missed windows — 7-8% of deliveries. The daily plan was laid out in 3-4 hours and edited during the shift, so windows could not be confirmed in advance.

What was changed

We assembled a constraint model: time windows, tonnage and body volume, driver working hours, truck access restrictions. Travel time was calculated not by average speed but by historical telematics data over the road graph from Yandex.Maps — accounting for rush hours.

Routes are recalculated in the evening based on the actual past day: cancellations, new addresses, and actual dwell times enter the model immediately. The dispatcher sees a deviation at the moment it appears, not the next morning.

What was achieved

After eight weeks of continuous operation: excess mileage 3%, missed windows 2%, plan layout — 25 minutes instead of half a shift.

The result held because rules and weights live in settings next to the dispatcher rather than in code: a new district or changed point mode is entered the same day.

One limitation remained: the algorithm closes 15-minute windows only if there is a second order nearby. We output such addresses as a separate list — the dispatcher plans them manually.

How online recalculation differs from nightly batch calculation

The difference between routing modes is in the horizon over which the plan is calculated. Batch calculation runs on schedule, sees the entire accumulated order volume, and seeks a global optimum: minimum mileage, even vehicle load, feasible delivery windows.

Online mode works not on schedule but on events — an order arrived, canceled, a vehicle broke down, the schedule slipped. It touches not the entire plan but the area that can still be shifted without harm.

The temptation to run a full recalculation on every event is understandable, but the plan starts to shake: the driver gets a new route mid-shift, and a route that has already left the warehouse cannot be replayed in calculation at all.

Recalculation during a shift is therefore built on a hard boundary — started routes are frozen and participate only as a constraint: occupied vehicle, cargo on board, return time.

The choice of calculation mode is tied to the event and the cost of change.

While the shift is local, online mode suffices; when changes accumulate beyond a threshold — by share of flexible orders or number of affected vehicles — the decision goes to batch calculation and is rebuilt entirely.

To prevent the plan from being reinvented every few minutes, the objective function adds a penalty for changing an already promised route and a limit on the number of touched routes. The driver sees one sequence of points, while critical events are handled immediately.

Thus batch calculation and online mode do not conflict: night sets the base plan and global optimum, the shift — point repairs within the moving zone. As the shift progresses, the moving zone narrows, and everything still flexible goes to the next nightly rebuild.

Doubts and limitations: data quality, integrations, rollback

The quality of the route at output is exactly the quality of the point reference: duplicate addresses, outdated time windows, points without coordinates, and addresses like “warehouse at the ring” turn a formally optimal route into an infeasible one.

Therefore the first step is not calculation but reference cleanup: address normalization, deduplication by coordinates, validation of constraints by weight, dimensions, and unloading time.

With the accounting system, the solution works as an add-on, not a replacement: orders, counterparties, and statuses remain in it, the optimizer reads them and returns the route plan and point order.

Exchange occurs on schedule and by order keys, so repeated export does not create duplicates and does not break delivery already started; if connection is absent, the route is calculated from the last successful export.

Dispatcher knows the route better — what then?

Calculation is a proposal, not an order. The dispatcher can pin a point, shift a window, keep a familiar route order; the system remembers such edits as rules and takes them into account in subsequent calculations. We put disputed points into a separate list and review them together with the delivery service.

How to roll back changes in rules?

Rules are versioned: base set, priorities, exceptions by points and transport types. Returning to the previous version does not stop delivery — we switch the rule set and recalculate routes for the next day, the previous route order remains operational.

Let's discuss the task and come back with an estimate and plan

To make the estimate based on data rather than guesses, several input materials are needed. Exports in their current form are enough — cleaning and bringing to a unified format is our part of the work.

• List of delivery or service points: addresses, acceptance windows, access and unloading restrictions.
• Route history for 2-3 months: actual routes, travel time, downtime, deviations from plan.
• Fleet and operating modes: vehicle types, payload capacity, driver shifts, mandatory breaks.
• Rules that must not be violated: customer priorities, ban on certain streets for large vehicles, procedures for dangerous goods.
• Current planning process: who builds routes today and in what, where they are edited manually.
• What we consider the result: mileage reduction, number of vehicles on line, time window compliance.

The review goes in two passes. First we look at the data and the current process: where the plan diverges from actual, which constraints are not considered at all, how many manual edits occur per day.

Then we calculate what automation will give at your volume — on which segments mileage drops, which routes can be combined, where the bottleneck is not in routes but in the warehouse schedule.

The estimate and implementation plan include: target route calculation scheme, list of data and those responsible for exporting it, work stages with a verifiable result at each, method of “before and after” comparison by mileage and time, integration requirements with the accounting system, and launch procedure without stopping current logistics. Describe the task — we will come back with an estimate and plan.