Why This Pool Service Company's Incentive Plan Paid Zero Its First Month

Pool service companies run on tight crews and tighter margins. A handful of technicians cover a whole route of accounts, and the difference between a good month and a break-even one usually comes down to how efficiently those technicians turn hours into billed work. So it makes sense that when owners in this industry think about incentive pay, the first metric they reach for is revenue per hour. It's intuitive, it's easy to explain to a technician, and in theory it rewards exactly the behavior you want more of.

That was the starting point for a pool service and construction company with roughly 8 to 10 field technicians. Leadership wanted a plan that paid technicians more when they generated more revenue per hour worked, and less (or nothing) when they didn't. Simple enough on paper. But before ShareWillow could help them build that plan, we had to answer a less exciting question first: could the company actually prove, with numbers it trusted, how many hours each technician worked and how much revenue each technician generated? The answer, at first, was no.

The Problem Wasn't the Plan. It Was the Data Underneath It

Revenue per hour sounds like a single number, but it's really the output of two separate systems that have to agree with each other. This company tracked technician time in a dedicated field-time tracking app, and tracked jobs and invoicing in a completely separate system. Nobody had ever gone through the exercise of reconciling the two, because until now, nothing had depended on them lining up exactly. Payroll ran fine. Invoices went out fine. It was only when the company tried to use those numbers to calculate a bonus that the cracks showed up.

And once we looked closely, there were real cracks. Unproductive time and drive time were sometimes getting miscoded as billable hours, which quietly inflated the "hours worked" side of the equation for some technicians and made their revenue-per-hour number look worse than it actually was. In other cases, technicians were clocked into the wrong customer's job entirely, which meant hours and revenue were being attributed to the wrong person altogether, not just miscounted. And on the revenue side, the company found a batch of invoices that had never been assigned to any technician at all. That work had been done, and the company had presumably been paid for it, but there was no clean record connecting it back to the person who earned it.

None of this was the result of anyone cutting corners. It's the normal residue of running two systems that were never designed to talk to each other, built up over months of day-to-day operations. But normal or not, it meant the company's revenue-per-hour figure, the exact number a new incentive plan would be built around, could not be trusted as it stood.

Why Bad Data Makes Bonuses Risky in Both Directions

It's tempting to think that messy time data is a minor issue you can clean up later, after the plan launches. In practice, it's the single biggest threat to whether an incentive plan survives contact with reality. If a company pays bonuses off numbers it can't verify, it is exposed on two fronts at once, and both are expensive.

Overpay a technician whose real productivity was lower than the reported number, because drive time got coded as billable or an invoice landed on the wrong name, and the company is handing out cash for work that didn't actually happen at that level. Do that more than once and the incentive plan stops being a performance lever and starts being a fixed cost nobody can explain. Underpay a technician whose real numbers were better than the messy data showed, because a chunk of their invoiced work never got attributed to them, and you've just told your best people that the new bonus plan shortchanges them. That is arguably the worse outcome, because it's the top performers, the ones you most need to keep, who notice first and trust the least after that.

Either way, the plan's structure was never the issue. A tiered revenue-per-hour incentive is a reasonable, well-understood way to reward productivity in a field service business. The company just couldn't safely turn it on until the inputs feeding it were something everyone could stand behind.

Building a Tiered Plan Worth Up to 5% of Revenue

Once the data problem was on the table, the plan design itself was straightforward. ShareWillow built a tiered commission structure worth up to 5% of monthly revenue, with the exact payout determined by which of five revenue-per-hour tiers a technician landed in for the period. The tiers scale upward from a qualifying floor around $110 per hour worked at the entry level to a top tier above $150 per hour worked, where a technician earns the full incentive percentage tied to their production.

In plain terms, it works like a ladder:

• Tier 1 (qualifying threshold): A technician needs to average roughly $110 in revenue per hour worked just to qualify for any incentive payout at all. Fall short of that, and no bonus is owed for the period, full stop.
• Tiers 2 through 4: As a technician's average revenue per hour climbs past the entry threshold, they move up through progressively higher tiers, each one unlocking a larger share of the incentive pool.
• Tier 5 (top tier): Technicians averaging north of $150 per hour worked land in the top bracket, qualifying for the full incentive, up to that 5% of monthly revenue tied to their own production.

This kind of structure rewards the technicians who are genuinely moving faster and closing more billable work per hour on the clock, without capping their upside and without paying out flat bonuses to everyone regardless of actual performance. But a tiered structure like this is only as good as the two numbers feeding it: hours worked, and revenue earned. Which is exactly where the earlier data problems had to get solved first, not worked around.

Closing the Gap With Invoice-Level Attribution

To fix the unassigned-invoice problem, ShareWillow set the plan up to pull revenue from an invoice-level attribution report rather than a top-line revenue number. Every invoice gets traced back to the specific technician who did the work that generated it. That single change closed the gap where a batch of invoices had previously been sitting with no technician attached, revenue the company had earned but that no incentive calculation could have credited to anyone. Hours came from the company's time-tracking system, the same source that had been producing the miscoded drive time and wrong-job clock-ins.

Pulling clean data from each source individually wasn't enough on its own, though, because the two systems still didn't always agree with each other. So ShareWillow built a cross-validation workflow into the plan: before any incentive payout could be finalized, the company's accounting team had to reconcile mismatches between the time-tracking data and the invoicing data for that period. If a technician's hours or revenue looked off, someone checked it before money moved, not after. That step turned two systems that quietly disagreed with each other into one number the company could actually stand behind at payout time.

The First Clean Month: Zero Technicians Qualified

Here's the part of this story that's easy to misread. In the first month the company ran its data through the new, verified process, the numbers showed that not a single technician actually met the $110-per-hour qualifying threshold. Under the old, messier reporting, some of those technicians might have looked like they cleared the bar. Once the hours were correctly coded, the invoices were correctly attributed, and accounting had reconciled the two sources, the honest numbers told a different story. No incentive payout was owed for that month.

It would be easy to file that under disappointing news. We'd frame it differently: that first month is exactly what a working incentive plan is supposed to produce when the underlying performance doesn't clear the bar. The whole point of building the invoice attribution report and the accounting reconciliation step was to make sure the company never paid out a bonus that the real numbers didn't support. A zero-payout month, arrived at through data everyone trusts, is not a broken plan. It's a plan doing its job, protecting the business from paying for productivity that, on close inspection, hadn't actually happened yet.

Smoothing Out Seasonality With a Multi-Month Average

After seeing that first clean month, the company made one more adjustment: instead of judging revenue per hour strictly month to month, they moved to averaging it across multiple months. Pool service work has real seasonal swings, and a single slow month, weather, a lighter job mix, whatever the cause, shouldn't permanently tank a technician's shot at qualifying, any more than a single unusually strong month should set an unrealistic bar for every month after it. Averaging across a rolling window lets the plan reward sustained productivity rather than reacting to noise in either direction, which is a more honest read on how a technician is actually performing over time.

What This Means for Your Shop

You don't need a pool service company's exact numbers to have this exact problem. Any field service business running technicians through a separate time-tracking tool and a separate job or invoicing system is one export away from finding the same gaps: hours that don't match, jobs attributed to the wrong name, invoices nobody assigned to anyone. If you're thinking about building or tightening an incentive, commission, or profit-sharing plan for your technicians, it's worth checking a few things first, and ShareWillow's plan design tools are built around exactly this kind of verification, not just the payout math on top of it.

• Do your time-tracking system and your job or invoicing system actually agree with each other, or has anyone ever checked?
• Is every invoice attributed to the technician who earned it, or are some sitting unassigned where nobody would notice?
• Does your team have a reconciliation step before a bonus is paid, or does the calculation run straight through on whatever the raw data says?
• If you judge performance by a single month, would a normal seasonal dip or a lucky month distort the bar for every technician after it?

If you run a pool service or construction business and you're planning to tie pay to a productivity number, treat the data underneath that number with the same scrutiny you'd give the plan itself. It's usually the less exciting half of the work. It's also the half that determines whether your technicians end up trusting the plan or quietly resenting it.