What PoolBoss Says
Manage a multi-technician pool service calendar by giving every tech's day one shared home instead of separate lists and text threads. Recurring routes populate each tech's stops automatically, a single daily view shows who is ahead or behind, and reassigning a day when someone is out takes a few taps instead of a round of phone calls.
One tech is a schedule you can keep in your head. Two is a schedule you keep in your head badly. Three is the week you start texting people at 7am to find out where they are, and taking a customer's call about a missed pool with no idea whether it was missed.
The coordination cost is real and it shows up in the same three places for everybody: days that quietly land lopsided, a tech finishing at 1pm while another is still going at 6, and nobody able to answer when somebody is coming. What follows is how operators running two or more crews handle it day to day - one shared view instead of several, routes that fill the calendar themselves, and a short list of moves for when the day goes sideways.
At a glance
Key takeaways
- Put every technician on one grid with days across the top and techs down the side; the coordination question is about the whole crew, not one tech at a time.
- Make recurring routes the scheduling unit so visits generate themselves - a 210-pool weekly book is about 10,900 visits a year that nobody should be entering by hand.
- Judge a day by pace, not stop count: at roughly 6 stops an hour, a 19-stop day against a 9-stop day is nearly two hours of extra service time before drive time.
- Fix a lopsided day in the morning, not at 5pm - the same five-stop shift is either a small correction or paid overtime, depending only on when you make it.
- When a tech calls out, reassign the whole day to someone with slack or spread it across the crew, and confirm the change rather than letting the schedule move silently.
- For a rained-out day, move every visit on that date at once and let each keep its assigned tech, so relative workloads and customer continuity survive the reschedule.
- Keep the technician's phone scoped to their own stops in order; a crew-wide view on a tech's device is the fastest way to get the crew to stop opening the app.
See every technician's day in one place
The fix is not a better calendar app, it is one calendar instead of several. Three techs servicing 210 weekly pools produce 210 visits a week, about 14 stops each per day, and no combination of per-tech spreadsheets, shared Google calendars, and group texts keeps that many moving parts straight. A single grid does, because the question you actually ask - who is where, and is anybody drowning - is a question about the whole crew, not about one tech at a time.
The practical test is whether you can answer a customer asking when somebody is coming in under ten seconds without calling a tech. If the answer lives in one person's memory or in a thread you have to scroll, the schedule is not really written down. If it lives on a grid with techs down one side and days across the top, it is, and anyone in the office can read it.
That grid is also where the day gets changed, not just read - the point of putting the crew on one view is that you can see and manage every tech's route from the same screen you check it on, rather than reading in one place and fixing in another.
| What you need to know | Separate calendars and texts | One shared crew calendar |
|---|---|---|
| Who is running which stops today | Ask each tech, or check three calendars | One grid, whole crew, at a glance |
| Whether a day is overloaded | You find out at 6pm when someone is still out | Flagged during the day against expected pace |
| Covering a tech who calls out | Rebuild the day by phone, stop by stop | Hand the day to another tech in one action |
| Rescheduling a rained-out day | Move each visit by hand | Move every visit on that date at once |
| What the tech sees | Whatever you remembered to text | Their own stops in order, on their phone |
Let recurring routes carry the schedule, not one-off bookings
A multi-tech calendar only stays current if nobody has to fill it in. Set service up as recurring routes with a cadence - weekly, biweekly, monthly, or a custom interval - and the visits generate onto each tech's day on their own. A 210-pool book on weekly service is roughly 10,900 visits a year. That is not a number anyone types in, and every hour spent maintaining a calendar by hand is an hour the calendar spends being wrong.
This is the split that separates pool service from general field-service work. A plumber's schedule is a stack of one-off jobs, so a job-booking calendar fits. A pool route is the same stops in the same order on the same day every week, so the route is the scheduling unit and the calendar is downstream of it. Book pool service as individual jobs and you have signed up to re-enter your entire book every week.
Once the cadence is set, the crew calendar is just the readout: the whole week across the crew assembles itself from the routes underneath it. If you have not set that cadence up yet, set up the recurring routes that feed this view first - the calendar is only as good as the routes behind it.
Catch an overloaded day before it happens, not at 6pm
An unbalanced day is easy to create and almost invisible until somebody is still working after dark. Stops get added to whoever was closest at the time, a route picks up four new pools over a season, and nothing tells you the day is now lopsided. On an established route a tech runs about 6 stops an hour, so a 19-stop day against a 9-stop day is close to two hours of extra service time before drive time is counted, and it lands on the same person every week.
What you want is pacing, not a headcount. A day that is behind is not a day with too many stops, it is a day where the stops remaining will not fit in the hours remaining, which depends on when the tech actually started and how long their pools actually take. PoolBoss computes that from the route's real start time and average service time rather than a flat guess, and flags a tech who is behind pace while there is still a day left to fix it.
Evening out the example below is a small move made early: five stops shift from the overloaded tech to the one with room, everybody lands at 14, and nobody is finishing at 6:30. Made at 5pm instead, the same move is just overtime with extra steps.
- Stops as scheduled
- Stops after balancing
| Category | Stops as scheduled | Stops after balancing |
|---|---|---|
| Tech A | 19 stops | 14 stops |
| Tech B | 14 stops | 14 stops |
| Tech C | 9 stops | 14 stops |
Reassign a technician's day when someone is out
Handing off a day should be one decision, not fourteen. An owner running three techs and about 210 pools across Henderson and Las Vegas normally checks in by text. On a Wednesday one tech messages at 7:40am that he is sitting in urgent care. What the owner needs in the next five minutes is narrow and specific: which of his stops are still open today, whether the other two techs already have full days, and who has room to absorb the extra work without running into overtime.
By phone that is a morning gone. On a crew calendar it is a two-minute fix - pull up the week across all three techs, see that one is at 11 stops and one is at 16, and hand the open stops to the tech with slack or spread them across both. In PoolBoss that is a named action rather than a workaround: reassign a day to one tech, or balance a day across the techs already working it, looking at each person's whole day across every route they run instead of one route at a time. Nothing moves until you confirm it, which matters, because a schedule that changes silently is worse than one that does not change at all.
The underlying recurring route is untouched by any of this - Thursday the tech is back on his own stops automatically, and the one-time change does not become the new pattern. Reassignment for an out tech is common enough to be worth its own playbook, so cover a route when one tech is out walks the full version, including what to tell customers.
Move a whole day when the weather takes it
Rain, a truck in the shop, or a holiday takes out the whole day rather than one tech, and the move you want is the whole day too. A washed-out Tuesday across a three-tech crew is around 42 visits, and rescheduling those one at a time is an hour of clicking that nobody does properly - which is how pools get skipped without anyone deciding to skip them.
Sliding every scheduled visit on one date to a new date in a single action solves it, with each visit keeping the tech it was already assigned to. The techs' relative loads stay intact, the customers keep the same person, and the week's arithmetic still works. The same mechanic covers the single-occurrence exceptions that come up constantly in this trade: a route that runs Thursday this week only, or a Monday route moved to Tuesday for a holiday, changed once without altering the recurring pattern underneath it.
Route optimization is a different tool and worth keeping separate in your head. Optimizing reorders the stops inside one route to cut drive time, with a preview before anything changes. It does not decide which tech runs which day - that is the calendar's job, and conflating the two is how operators end up surprised by a reshuffled week.
Each technician's phone shows only their own day
The crew view is for the office. On a technician's phone, the right amount of schedule is their own stops for today, in order, and nothing else. A tech scrolling past two other people's routes to find their fourth stop is a tech who stops looking at the app, and an app the crew stops opening is a calendar that goes stale within a month.
Role-scoped is also the honest answer to what techs worry about when you put their day on a screen. There is no live location tracking here and none planned - the app records that a visit was completed, with the readings and notes from that stop, which is proof of service rather than surveillance. Assigning or reassigning a route sends a push notification to the tech who now owns it, so a day that changes at 7:40am reaches the person driving to it without a phone call.
That division - full board for the office, own day for the tech - is what makes the whole arrangement hold up past three trucks. The dispatcher gets more visibility as the crew grows and the technician's screen does not change at all.
FAQ
Frequently asked questions
What is the best scheduling software for pool service companies?
The best one for a route business is whichever treats a recurring route as the scheduling unit instead of making you book every visit as a separate job. That single design decision drives most of what you will care about later: whether the calendar fills itself, whether a cadence change ripples through automatically, and whether covering a sick tech is one action or forty. Most tools aimed at a small multi-tech crew run $30-$100 a month, and the price differences between them matter far less than that structural fit. Beyond it, the things worth testing on a trial are narrow: can you see all your techs on one screen, can you move a day without rebuilding it, and does a technician's phone show only their own stops. Generic field-service platforms score well on job dispatch and badly on recurring routes, which is exactly backwards for pool service.
How do I track what my pool technician is doing?
Track completed work, not location. A 14-stop day produces 14 timestamped visit records with chemical readings and notes attached, and that is a far more useful picture of the day than a dot moving on a map - it tells you what was done, not just where the truck sat. Watching a route fill in through the day also answers the practical question on its own: if it is 2pm and four stops are still open on a 14-stop route, you know before the customer calls. Continuous GPS tracking is a different thing, it is not something PoolBoss does or plans to do, and crews tend to resent it in ways that cost more than the visibility is worth. The completion record is what settles a did-anyone-show-up dispute anyway, and it does not require anybody to be followed around.
How do I assign routes to pool service technicians?
Assign by geography first, then even out the workload inside those geographic blocks. Tight clustering is the single biggest lever on a route's economics - stops 5-8 minutes apart instead of 15-20 can be the difference between 18 pools in a day and 12 - so cutting the territory into compact zones and giving each tech a zone beats balancing pool counts across a spread-out map. Once the zones are set, compare the techs' whole days rather than individual routes, since a tech running two half-routes can be busier than one running a single long route. Keep the same tech on the same pools where you can, because a tech who knows a pool spots what is different about it, and customers notice when the person changes every week. Revisit the split once or twice a season as pools are added and lost.
How many pools can one pool service technician service per day?
About 15-25 residential pools on a tight route, with 20 a reasonable planning number for a full day. The working rate is roughly 6 stops an hour on established residential pools where the tech knows the equipment, which gets you to 20-24 in a standard day once drive time and a lunch break are real. What moves the number most is not the tech's speed, it is the distance between stops: a clustered route can support the high end, and one with 15-20 minute drives between pools tops out closer to 12-14. Commercial pools, pools with heavy tree cover, and anything requiring equipment work count for more than one residential stop. If your techs are consistently at the low end of the range, look at drive time before you look at the people.
How do I optimize my pool service route to reduce drive time?
Reorder the stops within a route so the drive path stops doubling back, and preview the change before you accept it. Optimization is a stop-order problem inside one tech's route, which is separate from the crew-calendar question of which tech runs which day - keeping those two apart avoids a lot of confusion. The reason a preview matters is that the shortest path is not always the right one: gate codes, customer time windows, a commercial pool that has to be done before the property opens, and a dog that is inside until 9am are all constraints a distance calculation does not know about. Accept the reorder where it is clean, override it where you have a reason. On a spread-out route, tightening stop order is often worth 30-60 minutes a day, which is a stop or two of additional capacity without hiring anybody.
Does pool service software have an offline mobile app?
The ones built for field work do, and it matters more in this trade than most operators expect. Pool equipment lives behind houses, in cabanas, and on properties with dead spots, so a tech who can only log a visit with a full signal will eventually be standing in a side yard with a completed pool and no way to record it. An offline-capable app lets the technician complete the visit, enter chemical readings, and add notes with no connection at all, then syncs everything once the phone is back on signal. Ask about this specifically on a trial, because it is easy to miss in a demo run over office wifi and painful to discover in August. The failure mode you are avoiding is a tech re-entering a day's readings from memory that evening, which is how chemical records stop being worth anything.
