Better delivery predictions still need a feasible route

An AI routing improvement must survive time windows, unloading delays and a clear accounting of every unserved stop.

Better delivery predictions still need a feasible route

A route with fewer kilometres can still be unusable. It may arrive after a customer's receiving window, load more than the vehicle can carry or leave out the hardest stop. When a fleet adds AI, the important distinction is between predicting an uncertain journey and deciding which journeys are allowed.

This analysis combines a routing research paper accepted at ICLR 2019 with the OR-Tools project's implementation documentation, checked on 17 October 2026. Its geographic scope is general methodology, not a measured route in any country. It does not evaluate a named fleet or recommend a paid mapping service. The worked depot example is fictional and deliberately small. Real operators must validate road access, working arrangements and applicable local requirements separately.

Prediction and optimisation answer different questions

A learned model might estimate travel time or unloading duration from previous jobs. A routing solver uses inputs and constraints to propose a sequence of visits. Learning can also be applied to constructing routes: Kool, van Hoof and Welling's research trains an attention model using reinforcement learning and evaluates several routing problems. Those benchmark tasks demonstrate a method under their specified conditions, rather than establish feasibility for an operator's complete workflow. [Attention, Learn to Solve Routing Problems!](https://arxiv.org/html/1803.08475v3)

The distinction matters when interpreting a vendor's demonstration. A learned route constructor, a learned time estimator and a conventional optimisation model are different components. Ask which component changes, what constraints it represents and what happens when the inputs are wrong. A convincing map does not answer those questions.

Google's OR-Tools time-window example makes the scheduling structure explicit: a travel-time matrix, visit windows, a time dimension and waiting allowance. The example illustrates how a solver can represent arrival timing. It is not evidence that its illustrative time matrix describes a real city, nor does it supply every fleet constraint automatically. [OR-Tools vehicle routing with time windows](https://developers.google.com/optimization/routing/vrptw)

An eight-minute job can change the whole route

Imagine a depot with one van leaving at 09:00. Stop A accepts service between 09:15 and 09:30. Stop B accepts service between 09:40 and 10:00. For this example, interpret a window as the permitted service-start time; a real operator must resolve whether its customer agreement instead requires service completion inside the window.

Assume depot-to-A travel takes 15 minutes, service at A takes eight minutes and A-to-B travel takes 20 minutes. The van starts at A at 09:15, leaves at 09:23 and reaches B at 09:43. Both service starts are inside the assumed windows. If unloading at A actually takes 28 minutes, arrival at B moves to 10:03. The stop order did not change; one inaccurate input broke the plan.

These invented numbers illustrate why the team should identify the source of each duration. GPS travel observations, loading scans, a customer's gate queue and the planner's assumptions describe different activities. If an unloading delay is folded into “travel time”, the model may learn the wrong explanation and carry it to the wrong location.

The proposed data review should inspect timestamps before fitting a model. Does “arrival” mean crossing a geofence, parking or obtaining entry? Are failed visits recorded? Are missing scans concentrated in difficult jobs? A history that excludes failed visits may make the next schedule look easier than the actual work.

Never hide an unserved stop inside a good objective

OR-Tools also documents penalties that let a model leave visits unserved. The penalty is added to the objective when a visit is dropped; its scale changes the trade-off against travel cost. Different visits can have different penalties. This is an explicit modelling decision, not simply an implementation detail. [OR-Tools penalties and dropping visits](https://developers.google.com/optimization/routing/penalties)

For the fictional depot, suppose the proposed route is shorter because it omits a remote customer. A distance-only comparison would reward that plan. A useful dispatcher view should display the omitted job, its priority and the reason it could not be assigned. A mandatory job should be represented as mandatory under the chosen formulation, rather than given a vaguely “large” penalty and assumed safe.

Keep units consistent. Minutes, metres and monetary costs are not interchangeable objective values. If the business chooses to combine them, document the conversions and examine how changing them affects who gets served. If no feasible solution is found within the search time allowed, distinguish that outcome from a proof that no feasible solution exists. An understandable failure is more useful than a route presented with unsupported certainty.

Test the full plan under uncertainty

A bounded local experiment could compare the existing planner and the proposed system on the same frozen job set. Report served and unserved stops, service-window failures, overtime assumptions, driving time, waiting and planner overrides. Keep demand and fleet availability fixed for that comparison. Otherwise a quieter day can be mistaken for an algorithm improvement.

Then replay the plan against deliberately varied durations. Extend selected gate waits, slow one corridor and make a vehicle unavailable. These scenarios do not predict the likelihood of a disruption; they reveal which assumptions the proposed route depends on. A probabilistic travel model would need separate calibration evidence before its intervals could be treated as meaningful probabilities.

Drivers and dispatchers should review the resulting exceptions before operational use. They may identify a loading sequence, access restriction or delivery practice absent from the model. Record whether each override corrects missing data, changes a business rule or handles an exceptional situation. That distinction determines whether to improve the data, the formulation or the fallback process.

Start in shadow planning, with the proposed route advisory and the existing dispatch process retaining authority. Define when a planner must intervene and how the accepted plan is recorded. Replanning should show which commitments change; repeatedly moving stops to improve a score can create an unusable day even if every individual plan appears reasonable.

The potential value of AI is better estimates or better search through routing choices. It does not remove the need to state hard constraints, inspect excluded work and account for uncertainty. A fleet should accept a route because its operational assumptions survive examination, not because the line on the map is shorter.