How route sequencing decides the order your van actually drives

A dairy and snacks distributor running six vans out of one depot built its routes the way most do: a supervisor with a printed customer list and a whiteboard, ordering stops by memory and habit the night before. Stop 1 was always the school-side bakery because the rep liked to start there. Stop 14 was wherever there was room left on the list. Nobody had measured whether that order made sense; it was just the order it had always been in.

The van still finished every stop most days. Nobody was calling it broken. It just took longer than it should have, and the reason was invisible from the office: the rep spent forty minutes a day driving past stops he'd already passed, because the sequence sent him east, then west, then east again to reach a customer that was three doors from stop 4.

Why nobody notices the cost of a bad order

A route with 18 stops has 18 factorial possible orders — a number with sixteen digits. Nobody is choosing badly on purpose out of that space; a human just can't search it. What a supervisor actually does is something much smaller: group stops loosely by neighborhood, keep regulars in their usual slot, and patch the list when a new customer gets added. That produces a route that looks reasonable stop by stop and is quietly 20–30% longer in drive time than it needs to be, because "loosely by neighborhood" is not the same computation as "shortest path through all of them."

The cost doesn't show up as a line item. It shows up as a route that finishes at 4:40 instead of 3:50, a rep who tells the office he "ran out of day" before the last two stops, and a truck that burns more fuel per case delivered than the one running the depot's other side, for no reason anyone can point to. Add one new customer mid-route and the problem compounds — the supervisor tacks the new stop onto the end of the list because reordering the whole route by hand isn't worth the time, even though the new stop is two minutes from stop 6 and forty minutes from where it just got placed.

What actually changes when the order is computed instead of guessed

The moment the dairy distributor's ops lead put the same 18 stops through an actual sequencing pass instead of a whiteboard, the order that came back barely resembled the old one — same starting point, same customers, radically different path between them. The van covered the same route in under five hours instead of six.

This is the traveling salesman problem, and it's worth being honest about what solving it well actually means: nobody computes the true optimal order for more than a handful of stops, since the search space grows factorially. What route sequencing software does instead is run a fast heuristic — build a reasonable starting order (nearest-neighbor: always drive to the closest unvisited stop next), then improve it with local swaps (two-opt: if uncrossing two legs of the route shortens it, do that swap) until no swap helps anymore. That gets within a few percent of optimal in milliseconds, which is what a dispatcher needs at 6 a.m., not a perfect answer that takes an hour to compute.

Distance alone isn't the whole model, either. A real route has constraints that change which "shortest" is actually correct:

• Time windows. A convenience store that only accepts deliveries before 9 a.m. has to be early in the sequence regardless of how close it is to everything else.
• Vehicle capacity. If the van is loaded heaviest-first for stability, the sequence has to respect what's physically reachable in what order.
• Credit holds. A customer over their limit might need a call before delivery, which can mean visiting them last rather than skipping the stop from the route entirely.
• Driver familiarity. Some sequencing keeps a rep's regular customers in roughly the same daily slot on purpose, because a store owner who expects the rep at 10 a.m. plans their own morning around it — a purely geometric optimum that visits them at 2 p.m. instead is technically shorter and practically worse.

Good route sequencing isn't "shortest path, full stop." It's shortest path subject to the constraints that actually matter to the business, which is a harder and more useful problem.

Real-time reordering is the part that matters more than the morning plan

The morning sequence is the easy case — every stop is known, nothing has happened yet. The case that actually determines whether the sequencing is useful is what happens at 10:30 when a stop cancels, or a customer calls in wanting an add-on delivery today, or the rep hits a closed road. A static route printed at 6 a.m. has no answer for any of that; it just becomes wrong, and the rep improvises for the rest of the day. A route that can be resequenced mid-day — drop the cancelled stop, insert the new one where it actually fits, recompute the remaining order — keeps the math honest instead of decorative.

That's also why sequencing has to live close to the data it depends on: current stock on the van, the customer's credit status, today's confirmed orders, not a route plan exported once at midnight from a system that hasn't heard from the field since.

What to check if your routes are still ordered by habit

• Time one route for a week without changing anything, then compute what a sequenced version of the same stops would look like — the gap is usually bigger than anyone guesses.
• Look at how a new mid-route stop gets added today: if it's always tacked onto the end of the list, that's the clearest sign the sequence is manual, not computed.
• Check whether the "optimal" route respects the constraints that actually matter — a delivery window, a credit hold, a regular's usual time slot — not just distance. A shorter route that misses a time window isn't actually shorter.
• Ask whether a route can be resequenced after 8 a.m., or whether every change means the rep works off a route the plan no longer describes.

iotoms sequences each van's stops from the same data the rest of the workspace already has — today's confirmed orders, current van stock, customer credit status — and can resequence mid-route when a stop changes, instead of leaving the rep to patch a route that stopped matching reality an hour after it printed.