A shorter route can be a bad route

Two routes connect the same addresses. One covers fewer kilometres but arrives after the first customer has closed. The other spends a little longer on the road and allows the deliveries to be completed. If you compare distance alone, you may choose the one that does not work.

I would start with the conditions of a delivery day: orders, available vehicles, schedules, unloading time and the departure and return point. Then I would choose what to improve. Reducing driving, meeting time windows and balancing shifts are different objectives; sometimes they conflict.

A case with its limits written down

This example is hypothetical and its quantities are assumptions, not a calculated route or measured savings. A van leaves and returns to the warehouse within a working day from 8:00 to 14:00. It carries four orders whose combined load fits in the vehicle. One stop only accepts deliveries from 9:00 to 10:00; the other three, from 9:00 to 13:00. Each unloading is estimated at 15 minutes.

To compare two visit sequences, I would need road travel times between all the points. I would also check access, parking and whether the window requires arrival or completion of unloading before it closes. I would not substitute straight-line distances for those times.

For each proposal, the comparison would need to show departure, arrival and end of service at every stop, waiting and return. A sequence that requires arrival at 10:05 at the customer who closes at 10:00 is rejected, even if it covers fewer kilometres. If no sequence fits the working day, a condition must change or you must acknowledge that it cannot be met.

What a routing engine adds

Google's OR-Tools example with time windows uses a matrix of travel times and visiting windows. The engine looks for a sequence that respects the model you have supplied. It does not know on its own that an address is wrong, unloading takes twice as long or a street does not allow that van.

OR-Tools supports capacity and time constraints, but may return good solutions without proving they are optimal. Search time and configured rules affect the result. Traffic data, when used, comes from a separate service and remains an estimate.

I would first test with orders from a completed working day and checked constraints. I would compare road kilometres, driving, waiting, total duration and deliveries within their windows. The observed journey and the proposal must serve the same stops and loads. A difference against a scenario that removes difficult deliveries does not represent equivalent savings.

Changing a plan has a cost

After a cancellation, I would recalculate from the current position and load, retaining completed deliveries and commitments that cannot be moved. If the driver is already heading to a stop, the person responsible must assess the change before communicating it.

I would also make it clear which order is left out and why. Hiding an impossible delivery behind a tidy map only moves the problem elsewhere. A useful trial ends when the team can explain and carry out the proposal, not when the algorithm draws a shorter line.