Pool service route optimization

What optimization can and cannot fix

Route optimization gets sold as a single idea, but there are really three separate problems hiding under that name, and confusing them leads to disappointment. Sequencing is the order stops happen within a fixed day — this is what most optimizers are actually good at, and it can meaningfully cut drive time between stops that are already assigned to that day. Assignment is which technician and which day each account belongs to — a much bigger lever, and one that a pure sequencing tool cannot touch on its own. Day-mix is whether your accounts are spread evenly enough across the week that no single day is overloaded while another is light.

A route with 20 accounts scattered across three different suburbs, all assigned to Tuesday, will not become efficient no matter how well those 20 stops are sequenced — the underlying problem is assignment and day-mix, not order. Optimizing sequencing on a badly assigned route produces a smaller version of the same bad route. Fix assignment and day-mix first; sequencing then compounds those gains.

The real constraints an optimizer has to respect

A pure shortest-path or shortest-time algorithm, run without constraints, will happily route a tech to a gated community at 6:45am, or schedule a commercial pool outside the hours its property manager allows. Real routes carry constraints that matter more than raw drive-time minimization, and any optimization process has to treat them as inputs, not suggestions.

• Gate and access codes — some communities require a specific arrival window tied to a gate schedule or an escort.
• Dogs and yard access — a handful of accounts may only be serviceable on days a dog is confirmed to be inside or away.
• HOA and community quiet hours — some neighborhoods restrict service vehicle noise or access before a certain morning hour.
• Commercial pools with required service windows — HOA pools, hotels, and apartment complexes often specify hours (for example, before residents are typically at the pool, or during specific contracted windows).
• Fixed-time customers — a homeowner who works from home and has asked for a consistent early-morning or late-afternoon slot.
• Vehicle and equipment constraints — a tech carrying a specific piece of equipment for a scheduled repair may need to hit that stop before returning it or restocking.

None of these constraints are exotic — most routes accumulate five to fifteen of them over time — but they are exactly the details that get lost when a route is rebuilt from a spreadsheet or a generic mapping tool rather than a system built for recurring service.

Why locked stops matter

A locked stop is one the optimizer is told not to move — a fixed-time customer, a commercial account with a contracted window, or simply a stop the owner wants to keep in a specific place for a business reason (a long-tenured customer who has always been the first stop of the day, say). Locking stops before running any optimization prevents the algorithm from technically shortening total drive time while quietly breaking a commitment that matters more than a few minutes saved.

The practical workflow is to lock every hard constraint first, then let the optimizer sequence and, where you allow it, reassign everything else around those fixed points. This produces a route that is both efficient and still keeps its promises.

Measuring a route honestly before and after

"The new route feels better" is not a measurement. Before making a change, capture a small set of numbers over a representative week (not a single unusually light or heavy day), and capture the same numbers again a few weeks after the change, once the tech has adjusted to it.

Comparing a single before-day to a single after-day is misleading because routes vary naturally with weather, callbacks, and one-off repairs. A representative week on each side of the change gives a fairer picture of whether drive time genuinely dropped or just moved to a different day.

Re-optimizing after adding or losing accounts

A route that was well-optimized six months ago degrades gradually as accounts are added, cancel, or change service day — the same slow drift discussed in route-density guidance elsewhere. A reasonable cadence is to re-check route density and constraints whenever net account changes on a given day cross a meaningful threshold (for example, a net change of three or more stops on one day), rather than waiting for an annual review or for a tech to complain.

• After adding several accounts to one day, re-run sequencing and check whether the day-mix is still balanced against other days.
• After a cluster of cancellations, check whether the remaining stops on that day still cluster well together or now require more drive time per remaining stop.
• After acquiring a route or a batch of new signups, treat it as a full re-optimization rather than appending stops to existing days.

The human cost of reshuffling a familiar route

A technician who has run the same 12 stops for two years has more implicit route knowledge than any optimizer — which house has the aggressive dog, which gate code changes monthly, which customer likes a text before arrival. Reshuffling that route for a modest efficiency gain has a real cost: the tech has to relearn dozens of small details, mistakes go up for a few weeks, and morale can dip if the change feels imposed rather than explained.

1. 1Explain the why before the what

   Tell the technician what problem the change solves (shorter days, fewer late finishes, room for a raise via more stops) rather than presenting a new list with no context.

2. 2Phase large changes over two or three weeks

   Move a handful of stops at a time rather than rebuilding an entire week's routes overnight, so the tech can absorb new access details gradually.

3. 3Preserve tribal knowledge in the system, not just the tech's head

   Capture gate codes, dog notes, and access preferences in the customer record before reshuffling, so a route change does not also mean losing information.

4. 4Check in after the first week, not just before the change

   A quick conversation after the first week surfaces friction (a gate code that did not transfer, a customer confused about a new arrival time) while it is still cheap to fix.

Balancing across technicians

With more than one tech, optimization is also a balancing problem: two techs with routes of equal stop count can have very different workloads if one route has heavier pools, more repairs mixed in, or worse density. Balance by drive-adjusted time and realistic daily capacity, not by raw stop count, and revisit the balance whenever one tech consistently finishes early while another consistently runs late — that gap is a signal the split needs adjusting, not that one tech is simply faster.