Why a Flat $115 Bonus Wasn't Motivating Anyone, and What Replaced It

Every technician at a mid-size pool service and construction company clocked in the same way each morning: badge in, grab the truck, drive to the first stop. Some mornings, though, that first stop was the shop, not a customer's backyard. A part needed picking up, a truck needed loading, a crew needed a few minutes to sort out the day's route. None of that is unusual for a service business running eight to ten field technicians across pool routes and construction crews. What was unusual was that all of that shop time was quietly getting counted as billable work in the company's most important productivity number: revenue per hour.

Revenue per hour was supposed to be simple. Take what a technician generated in a month, divide it by the hours they worked, and you get a clean read on how efficient they are. But when shop clock-ins, non-revenue codes, and even a mix of two different time-tracking systems all got folded into the "hours worked" side of that equation, the number stopped meaning what everyone thought it meant. Techs were getting penalized on paper for time they never spent in front of a customer. And the whole team was still being paid the same flat, fixed award every month regardless of what that number actually showed.

A Productivity Number That Was Measuring the Wrong Thing

The company had been building its technician pay around revenue per hour for a while, pulling total service revenue, customer price plus route stop pay, from its service report, and comparing it against hours logged in its time-tracking software. The problem was in the hours. For months, the operations team had been counting anything logged as "PB," "PP," or "SHOP" as service time, on the theory that shop hours were still part of a technician's workday. An ops lead running the numbers with ShareWillow flagged the issue directly during a working session to rebuild the metric. Shop time is not revenue-producing time, and mixing it in was dragging every technician's average down. As one member of the ops team put it plainly on the call, if someone is clocked into the shop, "then they're not revenue producing." The company's own leadership agreed without much debate once the numbers were laid out: those hours needed to come out entirely, not get discounted or flagged, just removed from the calculation.

Compounding the problem was a second, quieter issue. The company had switched time-tracking platforms partway through the year, moving off an older tool called BusyBusy onto a newer one, Workyard. Each system tagged job codes slightly differently, which meant that comparing March's revenue-per-hour numbers to June's required manually reconciling two different data structures every time. Nothing about the number was wrong on purpose. It was just built on a shifting foundation, and nobody had gone back to check whether that foundation still made sense once shop time and dual systems were factored in.

Rebuilding the Number Around Only Paid Job Hours

The fix itself was not complicated once it was named. ShareWillow rebuilt the revenue-per-hour calculation to count only hours logged against actual paid job codes, PP and PB in the company's system, and to exclude shop, home, and office time entirely, regardless of which time-tracking platform a given month's data came from. That single change reset the baseline. Technicians who had been quietly punished for legitimate shop duties, loading trucks, picking up parts, prepping for the day, saw their real productivity for the first time. Once the noise was cleared out, the picture was stark. Revenue per hour across the team ranged from about 55 to 98, averaging in the mid-60s, against a target of roughly 100 an hour needed to hold a 20% labor rate for a technician earning around 20 dollars an hour. That gap between where the average technician sat and where the business needed them to be was the real story the metric had been obscuring the whole time. It was not a small miss. It was most of the team sitting a third or more below the number the company actually needed to stay healthy on labor cost, and nobody had been able to see that clearly with shop time still baked in.

Fixing the inputs to a KPI like this is exactly the kind of groundwork that has to happen before any incentive plan can work. You can read more about how ShareWillow approaches building and tracking KPIs tied to real, verified data on the product side, but the short version is: an incentive plan is only as fair as the number it is built on. Get the number wrong and every payout built on top of it is wrong too.

Why a Flat $115 a Month Wasn't Moving Anyone

With a clean revenue-per-hour number in hand, the company's owner turned to the bigger question: what should technicians actually be paid for hitting it. The existing setup was a flat monthly award, a fixed dollar amount that landed the same for every technician regardless of whether they were running a 55 revenue-per-hour month or a 98 one. The owner was blunt about the problem with that structure on a call reviewing the new numbers. "I'm gonna guess a $115 is not gonna motivate him," he said, thinking through how a specific technician on the team would react to that kind of payout. He kept coming back to the same tension throughout the conversation: the award needed to be big enough to actually change behavior, without quietly eating into the company's margins if too many technicians hit it at once. "I want it to be where it'll engage them," he said. "I can tell you $115 a month is not going to engage them. But we also don't want to hurt ourselves either. I'll have to roll that around in my noggin." An ops lead pushed the fairness argument even further, walking through a scenario where a flat tiered structure could actually create a new problem instead of solving the old one. If two technicians land in the same revenue-per-hour tier but one is generating twice the revenue of the other, a flat award per tier pays them identically. "I bring more, but I have the same revenue per hour, and then we're getting the same incentives," he said, laying out exactly why a fixed number, whether it is 115 dollars or 350 dollars, breaks down the moment you have technicians producing meaningfully different volumes of work at a similar efficiency level.

Building Tiers That Scale With What Technicians Actually Produce

The solution the team landed on replaced the flat award with a tiered revenue-per-hour commission structure. Technicians who hit 70 revenue per hour would start earning a small commission on their total monthly revenue. Cross 80, and the rate steps up. Cross 90, and it steps up again, scaling from roughly 1% up toward 5% depending on the tier and how aggressively the company wanted to push performance.

The math made the case better than any argument could. Using one technician's actual June numbers, roughly $11,581 in monthly revenue, the team modeled out what a percentage-based structure would pay compared to the old flat number. At a 1% commission rate, that technician would earn an extra $115 a month, right in line with the old flat award. At 1.5%, it climbed to $173. At 2%, it reached $231. The same technician, the same month, the same underlying performance, but a structure that could pay meaningfully more the moment the company decided the number warranted it, without redesigning the whole plan from scratch.

What made the commission model click for the team was less about the specific percentages and more about what it fixed structurally. A flat award pays the same no matter how much revenue sits behind the number. A commission tied directly to revenue pays more when a technician brings in more, which is exactly the fairness gap the ops lead had flagged. It also solved the owner's real worry: instead of guessing at one number that might undershoot for a strong performer and overshoot for a weak one, the company could set a percentage that scaled automatically with whatever a technician actually produced that month, and adjust the rate itself, not the underlying structure, as they learned what moved the needle. This kind of tiered, KPI-based commission plan is one of the more common structures ShareWillow builds for pool service and spa companies running mixed crews of service and construction technicians, precisely because it ties pay to output instead of averaging everyone into the same box.

A Separate Plan for the Construction Side

Service technicians running daily pool routes are only half the picture at a company like this one. The construction crews building and renovating pools work in a completely different rhythm: fewer, larger jobs, measured in weeks rather than daily stops, where the real question is not revenue per hour but whether a job came in on budget.

For that side of the business, ShareWillow built a separate, per-job incentive plan rather than trying to force construction work into the same revenue-per-hour model used for service routes. Each job gets tracked stage by stage, comparing the budgeted cost and time for that stage against what it actually took. If a stage comes in under budget, the difference becomes an award pool for that stage. If it comes in over, there is no pool, the job is simply ineligible for that period, no penalty, just no payout.

The part that mattered most to the team was how that award pool got split once it existed. Rather than dividing it evenly among everyone who touched the job, the plan allocates it based on actual hours worked on that specific job. On one job the team reviewed together, a single technician had logged about 42% of the total hours clocked against it, so he received 42% of that job's award pool. Nobody had to guess or negotiate who deserved what share. The hours worked told the story on their own.

That structure answered a version of the same fairness question the ops lead had raised about service techs, just applied to project work instead of routes. A technician who spends three days on a job that comes in under budget should not split the reward evenly with someone who spent three hours on it. Tying the payout to hours worked on that specific job made the construction incentive feel proportional in a way a flat per-job bonus never could.

What Changed Once the Numbers Told the Truth

None of this required the company to change how technicians did their jobs. Nobody got a new route, a new tool, or a new set of instructions. What changed was the number sitting underneath their pay, and the structure translating that number into a paycheck. Once shop time came out of the revenue-per-hour calculation, the metric finally reflected what technicians were actually doing on paid jobs. Once the flat $115 award gave way to a tiered commission scaling with real revenue, the team had a reason to care about that number every single month, not just the ones where it happened to look good.

The lesson underneath this particular fix is one that shows up again and again in service businesses running any kind of incentive pay: the plan is never really the problem until the number underneath it is trustworthy. A perfectly designed commission structure built on a distorted metric will still feel unfair, because it is unfair, just in a way that is hard to see until someone sits down and traces the data back to its source. This company did that work first, clearing shop time out of the equation and reconciling two time-tracking systems into one consistent read, before it ever tried to decide what a fair payout should look like. Only then did the harder, more human question, what number actually motivates a technician who has heard "$115" too many times to care, get an honest answer.