Pool Service Software for Routes, Chemistry, and Equipment Upgrades (2026)

Pool service software should do three things well: tighten routes by density and pool size, log chemistry so drift shows up before it's a callback, and tie equipment specs to the actual pool instead of a generic customer note. Everything else - invoicing, texting, scheduling reminders - is table stakes. The gap that actually costs money is between what the tech sees on the truck and what the office can act on: a green pool nobody flagged, a pump quote with no site measure behind it, a chemistry complaint with no log to back up what was tested. Below is what to look for, how to set it up, and a worked example of the route math so the numbers aren't abstract.

Why route math matters more than route count

Most owners think about growth in terms of stops per week. That number means nothing without density. A tech running 24 stops a day in a tight subdivision is doing better than one running 30 stops spread across three zip codes. Drive time between stops eats margin faster than almost anything else in this business, and it's invisible until you map it.

Good route software should let you see gallons and surface SF per pool alongside geography, not just a list of addresses. A 15,000 gallon vinyl liner pool with a simple equipment package takes different time and different chemical volume than a 30,000 gallon gunite pool with a salt system and a separate spa. If your route software treats every stop the same, you're pricing blind.

When you're building or rebalancing a route, work the math this way:

• Total drive time for the week versus total service time. If drive time is running close to service time, the route needs tightening before you add another stop.
• Cluster stops by zip or subdivision first, then sort by day. Don't let a new signup break a tight route just because it came in first.
• Flag pools with known equipment issues or access problems separately, since those stops run long more often than the schedule assumes.

Worked example: tightening a Tuesday route

Say a tech's Tuesday route has 22 stops averaging 12 minutes of service time each, for 264 minutes of service time total. If those stops are spread across three zip codes with 210 minutes of drive time built in, drive time is running at roughly 80% of service time - too high. Pull the map, cluster by subdivision, and the same 22 stops might sort into two tight geographic blocks with 90 minutes of drive time, dropping the ratio to about 34%. That's the difference between a route that can absorb two more signups and one that's already maxed out. This is the math the software needs to expose automatically - most spreadsheets and generic field-service tools won't show drive-to-service ratio without building it yourself every week.

To set this up in your system: build route views that group stops by zip or subdivision code first, sort by service window second, and surface a drive-time-to-service-time ratio per route per day. If your software has a manual "add stop" flow, check whether it warns you when a new stop falls outside the existing cluster radius - that single flag prevents most of the density problems described above before they happen.

Chemistry logging that holds up

Every pool company says they test water. The ones who keep accounts are the ones who can prove what they tested and when. Standard chemistry targets most techs work from: free chlorine in the 1 to 3 ppm range for residential pools (some run 2 to 4 for higher bather load), pH around 7.2 to 7.8, total alkalinity in the 80 to 120 ppm range, and calcium hardness depending on plaster versus vinyl versus fiberglass. Cyanuric acid needs its own check, especially on outdoor pools running trichlor pucks, since stabilizer creep is one of the most common reasons a pool goes green even though the tech was "adding chlorine every visit." CYA limits also aren't universal - some states cap allowable CYA under 100 ppm for residential pools, and a few set even tighter limits for commercial and public pools, so a tech working across jurisdiction lines needs the target range to follow the pool's location, not a single company-wide default.

Digital logging matters here for two reasons. First, it catches drift before the customer calls. If alkalinity has been creeping for three visits in a row, that shows up in a trend line, not just a single reading. Second, it protects you. When a customer says "the water's been cloudy for two weeks and you never said anything," a logged reading with a timestamp and a photo ends that conversation fast.

Set your system up to require the core four readings (chlorine, pH, alkalinity, and either CYA or calcium depending on surface type) at every stop, not just when something looks off. Techs will skip logging on the routine stops if the software makes it easy to skip, and that's exactly when the record matters most.

Setting up drift alerts instead of just storing numbers

Logging a reading is only half the job - the software should compare it to the last two or three visits and flag movement before it becomes a service call. Set threshold rules per chemical: for example, flag any account where alkalinity has moved more than 15 ppm across two consecutive visits, or where CYA has climbed above 80 ppm on an outdoor trichlor pool (since that's the range where stabilizer creep starts working against your chlorine efficiency). Free chlorine dropping below 1 ppm twice in a row on the same account is worth its own flag, since that's usually a demand problem (bather load, heat, organic load) rather than a dosing mistake. These rules don't need to be complicated - three or four threshold flags tied to the readings you're already logging will catch most of the accounts that turn into green-pool callbacks two weeks later.

Equipment schedules tied to the actual pool

An equipment package on a resi pool typically means pump, filter, heater (if installed), sanitizer system (salt cell or feeder), and automation or controls. Commercial accounts add more: bigger filtration, code-driven flow rates, sometimes a separate chemical controller. None of that is useful as a general note in a customer file. It needs to be tied to the specific pool with model numbers, install dates, and filter type (sand, DE, or cartridge) because that's what drives your service decisions and your upsell timing.

Variable speed pumps have been standard on new installs for a while now, and older single-speed pumps are a common equipment upgrade conversation, both for energy cost and because many jurisdictions have moved away from allowing single-speed replacements. When you're quoting that upgrade, the site measure matters: pump sizing depends on plumbing size, turnover rate targets for the gallons in that pool, and existing filter capacity. A pump that's oversized for the plumbing wastes money and can cause flow problems; undersized and you're back out on a callback.

Track these fields per pool in your system:

• Pump model, filter type and size, heater type and BTU rating, sanitizer system type
• Install or last-replaced date for each major component
• Surface type (plaster, pebble, vinyl, fiberglass) since that changes chemistry targets and resurfacing timelines
• Access notes: gate codes, dog on property, locked equipment pad, HOA restrictions on service hours

That access field sounds minor until a tech shows up to a locked gate on a 100 degree day and burns 20 minutes trying to reach the homeowner. Build access notes into the route stop itself, not a separate customer file nobody checks before rolling out.

Structure these as separate fields per component, not a single free-text "equipment" box. A pump field should hold model, install date, and plumbing size as distinct entries so the office can filter for "all pumps installed before 2016" when a manufacturer issues a recall or you want to run an upgrade campaign. A single text note buried in a customer profile can't be filtered or reported on - it just sits there until someone reads it manually.

Site measure and the renovation vs. service split

Plaster and pebble resurfacing, equipment replacement, and full renovations are a different business than weekly service, and pricing them off a service-route mindset gets contractors in trouble. A site measure for a resurface job needs actual surface SF, not an estimate off the service log, because plaster and pebble finishes are priced per SF and a bad measure either eats your margin or blows the quote.

Keep renovation work in a separate pipeline from route service, even if it's the same crew doing both. A service account might generate a renovation lead (cracking plaster, an aging heater, a pump that's finally worn out), but once that job is scoped it should move into a project view with its own allowance, materials list, and schedule, separate from the weekly route. Mixing renovation billing into route invoicing is one of the fastest ways to lose track of what a job actually cost you.

When you quote a renovation allowance, build in a line for unknowns. Plaster jobs regularly turn up rebar issues or shell cracks that don't show until the old surface is out. Customers expect a base price and a change-order path, not a locked number that blows up mid-job.

Job-site scenarios that separate good software from a spreadsheet

Green-to-clean recovery. A pool that's gone green needs a documented shock schedule, not a guess. Log starting readings, chemical quantities added, and follow-up readings at 24 and 48 hours. If you're billing this as a recovery job separate from routine service, the software should let you quote it that way and track the extra visits it takes to clear, since green-to-clean jobs commonly run three to five extra stops before the water's back to normal service.

Equipment failure in season. A dead pump or heater in July is an emergency call, not a routine ticket. Your system should let a tech flag equipment failure on-site with a photo and push it straight to the office queue for same-day or next-day scheduling, separate from the regular route so it doesn't get buried under standard stops.

Barrier and access basics. Most jurisdictions have some form of pool barrier code covering fencing, gate self-closing hardware, and alarm requirements, and specifics vary by local authority. You're not the code inspector, but noting obvious barrier issues (broken gate latch, missing alarm) in the account file protects you if there's ever a liability question later, and it's a natural upsell conversation with the homeowner.

PoolWright is built around this exact split: route stops clustered by density with chemistry logging and drift flags built in, equipment records tied to each pool with filterable fields, and a separate lane for renovation and resurfacing work so it doesn't get lost in the weekly schedule. If you're running routes off a spreadsheet and a paper chemistry log right now, it's worth the half hour to try it free and see whether it fits how your crew actually works.

Frequently asked questions

How often should chemistry be tested versus just chlorine added?

Full readings including free chlorine, pH, alkalinity, and CYA or calcium should happen at every routine service stop, not just when the water looks off. Relying on visual checks alone misses alkalinity and stabilizer drift, which are two of the most common reasons a pool that "gets chlorine every week" still turns cloudy or green.

What's a reasonable way to price equipment upgrades separately from weekly service?

Equipment upgrades (pump, heater, filter, salt system) should be quoted as their own line item based on a site measure and current equipment specs, not folded into a monthly service rate. Pricing drivers include pump sizing against plumbing and gallons, filter capacity, and access for the install crew, and none of that belongs in the same math as your weekly route rate.

How do I know if my service route is too spread out?

Compare total drive time for the week against total service time. If drive time is approaching or exceeding service time, the route is too spread out and needs to be clustered by geography before adding more stops, even if that means turning down a signup outside your density.