Why route optimization software fails route-based field service

The assumption baked into every routing tool

That word, done, is the whole assumption. The job has an end. Once every address is visited the problem is solved, and tomorrow you load a fresh list.

Route-based field service doesn't work like that. You service the same sites over and over on a cycle. A stop you finished this week comes back around. There is no final state where every address is crossed off for good. The work drains down, then refills, and the crews start over. And there's almost always more work than fits in one day, so the real job isn't one optimal route. It's a rolling schedule that chunks the whole territory across many days and keeps doing it, week after week.

What it looks like in practice

We made that the core of the system instead of bolting it on. Every tree carries a simple flag: watered this cycle, or not. The day's work is just every tree where the flag is still false. A crew waters a tree, marks it on their phone, the flag flips. When the last unwatered tree is done, the cycle resets, every flag clears, and the whole set goes back in the pool for the next round. There's no fixed calendar. The pool refreshes when the work is actually finished.

That single idea, done is temporary, is the thing no off-the-shelf optimizer can represent. And it changes everything downstream.

The constraints that don't fit the textbook

Capacity is daily throughput, not total distance. The real limit is how many stops a crew clears in a day, applied to a pool that keeps refilling. So we cluster the work around the crews, not just the map. Each active truck gets a starting point spread out from the others, then its territory grows stop by stop until that crew has a full day's load. Territories end up sized to what a crew can actually do in a day.

Distance from the depot shapes the crews. A far territory costs more than a near one, so the operation can put fewer crews on the distant lanes. A delivery optimizer has no notion of home base shaping how the work is split.

Real days have slack. Crews finish early or run long. So each plan carries a buffer of the next-nearest stops in reserve. Finish early, the crew pulls the next one without waiting for a replan. Run out of time, the unfinished stops simply stay in the pool and roll into tomorrow on their own. Rollover is free, because an unfinished stop is only a flag that's still false.

“The hard problem is rarely the routing math. It's understanding the operation well enough to know which problem to solve.”

What off-the-shelf tools can't model

Off-the-shelf tools optimize one snapshot. Route-based field service is a continuous process. They are different problems wearing the same coat.

• Cyclic revisiting. Done is temporary. The whole set refills and the work starts again.
• Capacity as daily throughput. The limit is stops-per-crew-per-day over a pool that drains and refreshes, not total distance.
• Depot-aware crew sizing. Distance from base shapes how many crews go where.
• Buffer and rollover. Plans that absorb finishing early and carry unfinished work forward without a replan.
• Daily re-planning. Every day rebuilds territories from whatever is left in the pool.

Why this is the real lesson

You don't get to that list of constraints from a feature comparison. You get to it by watching how the operation actually runs: which crews go where, what happens when someone finishes at two o'clock, why a stop being done never quite stays done.

That's the part generic software keeps missing, and it's the part we think matters most. It's also the most repeatable thing we do. Almost every route-based business has a process the standard tools almost fit, and the distance between almost and exactly is where the real leverage sits.