The $5,000 Blind Spot: How a Pool Service Company Found the Revenue Its Payroll Was Missing

A Bug in a Spreadsheet Was Quietly Erasing a Technician's Month

A growing pool and spa service company had two separate pay problems tangled together, and neither one was obvious until someone went looking. The first was structural: technician bonuses were based on flat dollar tiers that did not account for how efficiently a tech actually used their hours. The second was a lot more mundane, and a lot more expensive. A payroll data sync was quietly dropping one technician's numbers almost every month, because of a misspelled name.

Neither problem was dramatic on its own. A technician's bonus being a little lower than it should be does not set off alarms the way a missed payroll run does. A commission structure that quietly favors efficient-but-small producers over high-volume producers does not look broken from the outside, it just looks like some people are naturally better bonus earners than others. Both problems were the kind that hide in plain sight for months, or years, unless someone goes looking with the right question in mind.

The efficiency problem showed up first. Revenue per hour across the crew ranged from about $55 an hour on the low end to $98 an hour on the high end, a huge spread for technicians nominally doing the same job. A flat dollar bonus tier could not tell the difference between a technician producing $10,000 a month efficiently and one producing $40,000 a month at the exact same hourly rate. Both would land in the same bucket and earn the same bonus, which quietly penalized the company's most efficient people.

Two technicians can produce very different revenue and still show the identical revenue-per-hour number. If your bonus only looks at revenue per hour, you're paying for efficiency, not results, and those are not the same thing.

That is the reasoning that pushed the company away from flat efficiency tiers and toward a straight commission model in ShareWillow: a percentage of the revenue a technician actually produced, aligned to a target labor rate, rather than a bucket based purely on an hourly average. The second producer earning four times as much revenue would now earn a meaningfully larger bonus, even if their hourly efficiency looked similar on paper.

The target labor rate itself came first, before any commission percentage was chosen. The company worked backward from roughly a 20% target labor cost to figure out what hourly revenue a technician needed to produce to hold that rate, landing on a $70 to $90 an hour target zone. Only after that target was set did the commission percentages get built around it, which meant the incentive was anchored to something the business actually needed, not just to a number that felt generous.

The Second Problem Was Hiding in Plain Sight

While the commission structure was being redesigned, a second issue surfaced almost by accident. One technician's revenue numbers looked lower than they should have been for a given month, and when the team dug into why, they found a name-matching bug in the payroll sync. The technician's name was formatted slightly differently between the job data and the payroll system, first and last name split in a way the sync did not recognize as a match, so that technician's jobs were silently excluded from the reported total.

What the Sync Was Actually Missing

The pattern only became visible because someone happened to compare that technician's numbers against a separate report and noticed the gap. Nothing about the payroll system flagged an error. From its perspective, the sync had worked exactly as designed. It simply never recognized that "J. Smith" and "Jonathan Smith" were the same person, so an entire month of that technician's completed jobs sat in the source data without ever making it into the number payroll actually used.

For that technician, the payroll system reported $27,418 in revenue for the month. The actual invoiced total, once every job was correctly attributed, was $32,190. That is a gap of roughly $4,800 in a single month, on a single technician, caused entirely by a formatting mismatch nobody had thought to check.

Once the mismatch was found, the fix itself was straightforward: standardize how technician names sync between systems so a job never silently drops out of the total again. But finding it required someone to actually compare the reported numbers against the source data, which is a step a lot of pool and spa service companies skip once a payroll process feels like it is running smoothly.

Construction Crews Got Their Own Incentive, Too

Service and construction are different enough businesses running under one roof that it was never realistic to expect one incentive formula to fit both well. A service technician closes several jobs a day, each one relatively small and fast. A construction crew might spend a full week or more on a single build, where the whole team's hours and the job's material costs are tangled together in a way daily revenue commission was never designed to measure.

Once that specific bug was fixed, the company treated it as a prompt to check the rest of the sync rather than closing the ticket and moving on. Names with suffixes, hyphenated last names, and nicknames used inconsistently between systems all got the same standardization pass, on the theory that if one technician's revenue had been silently dropped, others were likely affected in smaller, harder-to-notice ways too.

The company also runs pool construction and build jobs alongside service work, and those crews needed a different kind of incentive entirely. Rather than a revenue commission, construction jobs earn a bonus pool worth 10% of whatever labor budget the crew comes in under, split among the team by the percentage of hours each person actually worked on that job. A technician who worked 42% of a job's hours earns 42% of that job's award, which keeps the incentive tied directly to who did the work.

The Result: Roughly $5,000 a Month Found, and a Fairer Bonus on Top

Fixing the name-matching bug alone recovered close to $4,800 in a single month for one technician, revenue that had always been real and always been earned, but that payroll simply never saw. Multiplied across a full year and across any other technicians affected by similar formatting quirks, that is not a rounding error. It is money the business was already generating that its own systems were hiding from it.

It is also money that had already been correctly invoiced to the customer. The revenue existed. The job was done, billed, and paid for. The only place it did not exist was in the number the company was using to calculate its own technician's bonus, which is about as close as a data bug can get to taking money directly out of a crew member's pocket without anyone intending to.

There is a broader lesson in how this particular bug got found. It was not caught by a system alert or a routine audit checklist. It was caught because someone treated a technician's numbers looking slightly off as worth investigating instead of writing it off as normal variation. Most payroll errors of this kind never get that benefit of the doubt, which is exactly why they tend to persist for years once they start.

On the commission side, the move to a straight revenue percentage is still being tuned. Early modeling showed one technician's $11,581 in June revenue translating to a bonus somewhere between $115 and $231 depending on which percentage tier the company settled on. The owner's own reaction to the lower end of that range was blunt: a bonus that small was not going to change anyone's behavior. That feedback is exactly why testing a plan against real numbers before it goes live matters. It is much easier to adjust a percentage on paper than to walk back a bonus a crew has already come to expect.

There is a rhythm to how these two fixes played out that is worth naming directly. The commission redesign was a structural, plan-level change, the kind that gets a rollout meeting and a new document everyone reads. The sync bug was the opposite: a single quiet correction that never would have shown up in any plan document at all, and that nobody would have found without looking. Both mattered. Neither would have caught what the other one did.

What This Means for Your Crew

• Audit your payroll sync before you trust it. A single misspelled or reformatted name can silently exclude a technician's real revenue from their bonus calculation, month after month, without triggering any error anyone would notice.
• Revenue per hour alone can penalize your best performers. Two technicians can share the same hourly efficiency number while producing wildly different total revenue. If your bonus stops at efficiency, it is not rewarding the people generating the most value.
• Different work needs different incentive math. Service technicians and construction crews were never going to succeed under the same bonus formula here, and forcing one structure onto both would have undersold one team or overpaid the other.
• Split team bonuses by actual contribution. Tying a construction crew's shared bonus to each person's percentage of hours worked, rather than splitting it evenly, keeps the incentive fair without adding real complexity.
• Test payout math against real numbers before committing. Seeing that a proposed tier would only produce a $115 bonus let this company catch and fix a problem before it ever reached a paycheck, not after.
• A number that looks slightly off is worth a second look. The sync bug here never triggered an error. It just produced a total that was a little lower than expected, and it stayed hidden until someone decided that was worth investigating instead of ignoring.

If your pool service or field service business has grown past the point where a founder can eyeball every payroll number by hand, the odds are good that something similar is hiding in your own data. For another example of a data-accuracy fix protecting real payroll dollars, see how a multi-trade shop caught $76,000 in misclassified commission revenue before it ever touched a paycheck.