Blog

A planner working from memory and a spreadsheet can hold maybe 20-30 delivery stops in their head at once: which truck has room, which store closes early, which area to avoid at rush hour. Below that ceiling, manual planning is fast and cheap. Above it, something has to give.

What usually gives first isn't obvious from the outside: routes still get built, drivers still leave the depot, deliveries still mostly happen. What erodes is the margin. A truck goes out at 70% capacity because nobody had time to check if a fourth stop would fit, or a store misses its time window because the planner front-loaded the easy stops first. None of it shows up as a single dramatic failure. It shows up as a slow tax on every day's fuel bill and every week's on-time rate.

The fix is to take the constraint-checking off a human's mental load entirely. Capacity, time windows and distance limits are exactly the kind of thing software should check exhaustively, on every stop, every time, so a planner's judgment gets spent on the calls that actually need a human: which store gets the apology call, which driver knows a shortcut the map doesn't.

Time windows feel like a customer-service feature, but they're really a scheduling constraint with a price tag. Every window you promise narrows the set of routes that can legally serve that stop. A 9-11am window on a store across town from your depot might quietly rule out three otherwise-efficient routes before a planner even starts.

The naive fix is to build the route first and check windows after, patching violations by hand. This is slow and it back-loads risk: the stop you catch last is the one most likely to blow its window, because by then the route is mostly fixed and there's nowhere left to move it.

The better order treats time windows as a first-class input to clustering rather than a post-hoc check: group stops so windows are compatible with the sequence before the sequence is finalized, and treat a windowless stop as more flexible cargo than a tight-windowed one. It sounds obvious written down. It's exactly the step manual planning tends to skip under time pressure, and exactly what a solver never skips.

The simplest way to build a route is greedy nearest-neighbor: start at the depot, go to the closest unvisited stop, repeat. It's fast, it's easy to implement, and it's a trap: every decision is made looking only one stop ahead, so it happily paints itself into corners. The stop it strands for last is often the one furthest from everything else, turning a route that looked efficient for its first 90% into a long, wasteful tail.

A multi-pass approach accepts that dispatch is not one decision but several, made in sequence with different goals: an initial pass clusters stops into truck-sized, window-compatible groups; a second pass sequences each cluster for shortest travel; a later pass sweeps up whatever the earlier passes couldn't place, using idle capacity that only became visible once the rest of the fleet was committed.

The result reads less like 'the shortest path a computer could find' and more like what an experienced dispatcher actually does: commit the easy 80% quickly, then spend real attention on the leftover 20% where the constraints actually conflict. That's the part worth automating well. The easy stops were never the problem; the hard stops are exactly where manual planning runs out of time.