How often a pool route should actually be serviced

Actual interval (days) = days in period / visits completed in period
Drift                  = actual interval - promised interval
Max gap                = longest run of days between two visits, per customer

What actually sets the interval

Four things move the number, roughly in this order.

Water temperature. Chlorine demand rises with temperature and so does algae growth. Same pool, same family: a visit that holds for nine days in March does not hold for nine days in July. This is why the interval is a seasonal decision and the price built on it should be too.

Bather load. Every swimmer adds organic load the sanitizer has to deal with. A retired couple's pool and a pool that hosts eight kids every Saturday are different accounts even when they are on the same street with the same gallonage.

Sun exposure and stabilizer level. Free chlorine degrades in UV. A pool in full sun with low cyanuric acid can lose most of its free chlorine in a day, and no weekly schedule fixes that. The fix is the stabilizer level. If you cannot get the stabilizer right, that pool needs a tighter interval or a different sanitizer, and you should price it that way rather than absorbing it.

Debris and screening. A screen enclosure keeps out most leaf and blossom fall. That turns a skim-net-empty-baskets-backwash stop into a skim-and-brush stop. It matters enormously for how many stops fit in a day, which is the capacity arithmetic below, and barely at all for the interval.

What does not set the interval: how clean the pool looks to the customer. A pool can look fine on day nine and be two days from a bloom. If you let customer perception set frequency, you will be downgrading accounts in May and rescuing them in July at your own cost.

Water temperature and bather load set the interval. The interval sets the price. Confusing the two is how routes get underpriced going into summer.

The capacity arithmetic that decides whether you can hold weekly

Before anything else, work out whether the promise is physically possible.

Required stops per week = weekly accounts + (biweekly accounts / 2)
Capacity per week       = tech-days per week x stops per tech-day

Worked example. Four techs, five days each, so 20 tech-days. You have 380 weekly accounts and 80 biweekly, which is 380 + 40 = 420 required stops. 420 / 20 = 21 stops per tech-day required.

Twenty-one stops is about 20 minutes per stop across an eight-hour day, including drive time, loading, and the two accounts that need something extra. That works in March. In July, when every stop picks up a few more minutes of brushing and filter cleans come due, the honest figure for the same crew might be 18. 18 x 20 = 360 stops of capacity against 420 required. You are 60 stops short every week.

Those 60 stops do not disappear. They move to next week, and so the following week starts 60 stops behind. That is drift, and it compounds. By late summer a weekly route is running at nine or ten days and nobody decided it should.

There are only two fixes: raise stops per tech-day, by tightening the geography or shortening the stop, or raise tech-days. Pushing visits is not a third option. It is the symptom.

The rule worth writing down: your summer capacity is your real capacity. Size the route for July, not for the shoulder season, and the shoulder season takes care of itself.

The drift report you can run this week

This takes about twenty minutes and it is the most useful thing you will do to the route this month.

Export every completed visit for the last 90 days with two columns: customer, date. Then per customer, compute:

• visits completed in the period
• actual interval, which is 90 divided by visits
• max gap, the longest number of days between two consecutive visits

Sort descending by max gap. Flag every customer whose max gap is more than their promised interval plus three days.

What the shape of that list tells you:

One leading indicator worth tracking alongside it: count visits completed after 4pm. End-of-day compression shows up weeks before the gaps do. When the share of late finishes starts climbing, the gaps are coming.

Changing frequency on purpose instead of by accident

If the arithmetic says you cannot hold weekly across the whole route, move accounts to biweekly deliberately and pick which ones. Good candidates: cool season, screened, low bather load, stable chemistry history, an owner who is not in the water much. Bad candidates: full sun, heavy bather load, an account that has needed a return visit this year.

Price it honestly. A biweekly account is not half a weekly account, because the stop takes longer and the chemical demand per visit is higher. If you bill half, you have taken a pay cut and called it a schedule change.

And tell the customer before the first longer gap, not after. A gap they expected is a schedule. A gap they noticed is a cancellation risk.

What pool scheduling software has to do, beyond drawing a calendar

Any calendar can place a recurring visit. The thing that stops drift is different, and worth insisting on when you evaluate tools:

• every recurring job carries its promised interval as data, not as an assumption in the route name
• a report of actual gap per customer, not just a count of completed visits
• tomorrow's load visible against capacity before the day starts, so you can move one stop in the morning instead of nine stops in August

OkPilot is field operations software you run by typing plain instructions, so "show me every account with a gap over ten days this quarter" is the kind of question you ask directly rather than exporting and building a spreadsheet for. It suggests the reshuffle, and a person approves it before anything moves.

If the gaps turn out to be geography rather than headcount, the fix is a route rebuild rather than a scheduling change, and those are different jobs with different tools. Route planning and dispatch are not the same thing, and recurring-visit businesses like pest control hit exactly the same wall at exactly the same point in the season.