Routes in delivery are not “drawing a line on a map.” It’s a daily fight with physics, time, and human habits. Traffic jams, customer time windows, parking, loading/unloading, sudden reschedules, and the eternal “we’ll be after lunch” — all of that turns a good plan into a bad one if it doesn’t reflect reality. But competent planning gives a fast payoff: fewer kilometers, lower fuel consumption, more deliveries per vehicle/shift, and less downtime at stops.
A typical beginner mistake is trying to optimize only kilometers. In city logistics, minutes are usually more expensive than meters. So below is a practical breakdown of key metrics, approaches, and a step-by-step implementation algorithm for route planning that reduces costs instead of adding operational drama.
1) Mileage (distance) and “empty miles”
Mileage is the total kilometers of a route. Empty miles are kilometers driven without useful work (no deliveries/pickups). Measured as km/shift and % of empty km. It matters because empty kilometers are fuel and time with no revenue.
2) Stop time
How many minutes one stop takes: approach, parking, signing, waiting, reschedule. Measured in minutes by stop type. It matters because reducing stop time often produces a bigger effect than “cutting 5 km.”
3) Delivery time windows
Time intervals when the customer accepts the shipment. Measured as time ranges and by how “strict” the window is. It matters because strict windows break perfect route geometry and create downtime.
4) Resource capacity
Constraints by weight/volume, number of packages, shift duration, number of stops, temperature regimes. Measured as limits and actual utilization. It matters because an overloaded plan equals failures, penalties, and overtime.
5) SLA/OTIF and cost per successful delivery
OTIF is “on time and in full.” Cost per successful delivery is the cost of one delivery that actually happened. It matters because the “prettiest route” is useless if you don’t hit the windows or you get many failed deliveries.
6) Downtime
Time when a vehicle/courier is standing still and not moving the process: waiting at the warehouse, at the dock, at the customer. Measured in minutes and by reasons. It matters because downtime is paid time with no result. Economics hates that.
| What we optimize | Metric | What most often gets in the way |
|---|---|---|
| Mileage | km/shift, % empty km | Scattered addresses, poor clustering |
| Fuel | l/100 km, l/shift | Traffic, idling, driving style |
| Downtime | min/stop, min/shift | Time windows, dock queues, customer waiting |
| Productivity | deliveries/shift | Long stop time, poor sequencing |
Manual planning + simple rules (for small volumes)
When it fits: up to ~20–40 stops per day for one or two vehicles, stable geography, an experienced dispatcher, few strict time windows.
Pros: fast; no expensive software; easy to factor in “human knowledge” (where to park, which entrances are tricky).
Limitations: scales poorly; quality depends on one person; hard to analyze data systematically.
Risks: routes “the way we’re used to” become tradition—and traditions are rarely optimal.
Algorithmic planning (TMS/route optimization) + execution control
When it fits: dozens and hundreds of stops per day, multiple vehicles, many time windows, high cost of mistakes, need to scale.
Pros: better optimization by time and mileage; transparent analytics; easier re-optimization when changes happen.
Limitations: requires high-quality data (addresses, windows, service time); requires execution discipline.
Risks: if the data is bad, the algorithm will optimize garbage. That’s not the algorithm’s fault—it’s its job.
Scenario 1: baseline — 3 vehicles, 120 stops a day; routes were built “by habit,” and mileage and fuel were increasing. Actions — introduced city zoning, assigned zones to vehicles, added service-time standards by stop type, and started analyzing plan vs actual. Result — mileage went down, and deliveries per vehicle increased without overtime.
Scenario 2: baseline — lots of downtime at stores due to dock queues. Actions — agreed on narrower receiving windows, distributed stops by time, added a rule “don’t arrive early” (yes, sometimes that’s also optimization). Result — downtime decreased and the schedule became more stable. We’ve worked in this field for over 13 years, and honestly: sometimes the biggest win isn’t in the route, but in stopping the habit of arriving where you won’t be accepted anyway.
1) What gives a bigger effect: optimizing mileage or reducing downtime?
Often, reducing downtime and stop time. In city deliveries, time is usually more expensive than kilometers. But it’s best to calculate based on real data: if you have long distances between districts, mileage can be the main lever too.
2) Can you plan routes without specialized software?
You can, if volumes are small and data discipline exists. But once the number of stops grows, time windows appear, and the “day dynamics” increase, manual planning starts to consume too much time and produces unstable results.
3) Where to start if today is total chaos?
With three things: normalize addresses, introduce stop types (and their service times), and record plan vs actual with reasons for deviations. This baseline data is the fuel for any optimization. Without it, there’s nothing to optimize—only to guess.