The Pay Formula That Was Secretly Paying Twice

There's a specific kind of pay structure that shows up constantly in home service businesses, and for good reason: pay a technician their hourly base, or a percentage of the revenue they generate, whichever number is bigger that period. It's a fair idea on its face. Slow week, bad weather, a stretch of small jobs? The hourly base protects the tech's paycheck. Strong week, big jobs, a run of good sales? The commission side lets that same tech earn well above hourly for doing well above-average work. Nobody loses. That's the whole appeal of "whichever is higher" as a formula.

A power washing company running its technician pay through Jobber had set up exactly this structure: a $20 an hour base rate, compared against 12 percent of the revenue a technician generated, with the higher of the two determining the actual payout. It's a clean, well-reasoned plan. The only problem was that the system wasn't doing what the plan said it was supposed to do.

Whichever Is Higher, Except It Was Adding Them Together

During a routine check-in call, the company's owner, Mike, sat down with ShareWillow to review how the plan was actually calculating pay before the next payroll run. What surfaced wasn't a data sync problem or a missing metric. It was a real calculation defect: the system was summing the hourly base and the commission together instead of comparing them and paying only the larger of the two. In practice, that meant every technician on the plan was on track to be paid their full hourly guarantee and their full revenue-share commission, stacked on top of each other, for the exact same hours and the exact same jobs.

That's a meaningfully different outcome than the one the plan was designed around. "Whichever is higher" is a floor with a ceiling that moves depending on performance, a safety net during slow stretches and a real incentive during strong ones. "Add them together" is neither of those things. It's simply more money going out than the plan was ever built to pay, on every check, for every technician on the structure, until someone caught it. A well-intentioned formula that protects technicians during a slow week isn't the same formula once it starts paying every technician the slow-week rate and the strong-week rate simultaneously, no matter how the week actually went.

“Whichever is higher” and “both, added together” look almost identical in a spreadsheet formula and are nowhere close to the same plan in a paycheck.

What makes this particular catch worth paying attention to is how ordinary the moment was. Nobody flagged a specific paycheck as wrong. Nobody filed a complaint. This surfaced during a standard feedback and check-in conversation, the kind of call that easily could have stayed at the level of "what do you like, what's frustrating, what should we improve," without anyone opening up the actual math behind a live plan. The bug wasn't hiding in an edge case or a rare scenario. It was sitting in the default calculation every single technician on the plan would have run into on the very next payroll.

There's a broader lesson buried in how quietly this kind of thing can sit undetected. A hybrid pay structure, hourly-or-commission-whichever-is-higher, is popular precisely because it sounds simple to explain to a team. But "simple to explain" and "simple to calculate correctly" aren't the same property. Comparing two numbers and picking the larger one is a basic operation. Silently swapping that comparison for addition is an easy mistake to make in a formula and an easy one to miss in a review, especially when the summed total in a strong week can look plausible on its own, without anything about the number itself screaming that it's wrong. We've covered a similar structural pay design, hourly base versus revenue share, at an HVAC, plumbing, and electrical company that built a hybrid plan around the same "whichever pays more" principle. The idea works. It only works if the system actually executes the comparison it was told to make.

Fixed On The Call, Not On A Follow-Up

ShareWillow's Ashlyn corrected the calculation logic live during the same conversation where it surfaced, updating the plan so hourly base and commission are compared directly and the technician is paid whichever amount is actually larger, with both figures displayed side by side so Mike could see the comparison for himself rather than trusting a single blended number. That side-by-side view matters beyond just fixing the bug. It turns an opaque calculation into something an owner can sanity-check at a glance: here's what hourly would have paid this technician, here's what commission would have paid, here's which one won and why. A plan that shows its work is a lot easier to trust than one that just outputs a final figure and asks you to believe it.

The fix didn't require redesigning the compensation philosophy or renegotiating anything with the team. The underlying idea, pay whichever is higher, was correct from the start. What needed fixing was narrowly technical: the comparison logic itself. That's a useful distinction to sit with, because it's tempting when a pay bug surfaces to assume something more fundamental is broken, the plan design, the rates, the whole approach. Sometimes it is. Here, it wasn't. The 12 percent commission rate, the $20 hourly base, and the whichever-is-higher principle were all sound. The system just wasn't executing the "higher of" part correctly, and once that specific piece was corrected, the rest of the plan worked exactly as designed.

A second issue came up in the same call, less dramatic but just as consequential for a business running payroll on a tight weekly clock: data sync timing. The company needed prior-week data ready by Monday morning to complete payroll by Wednesday, and the sync between Jobber and ShareWillow was running on a schedule that didn't reliably capture weekend activity in time. Ashlyn increased the sync frequency to include weekend updates, so a job completed on a Saturday shows up in Monday's numbers instead of trailing in later in the week, after the payroll review has already started. It's a smaller fix than the calculation bug, but it solves the same category of problem: making sure the number a business owner is looking at on payroll day actually reflects the full week that happened, not a partial or stale snapshot of it.

Mike also raised a fair concern about ad-hoc adjustments, situations like a missed callback or a review that should count toward a bonus but doesn't have an automatic path into the system. That's a real gap worth naming honestly rather than glossing over: automated syncs are excellent at capturing what a platform like Jobber or ServiceTitan already tracks cleanly, and they're not naturally built for the occasional manual exception every business runs into. The fix there wasn't a magic switch, it was clarity about the process: use the plan review and finalize workflow to catch and correct exceptions before locking a pay period, rather than trying to force every edge case into fully automatic handling. A pay system doesn't have to be perfectly automatic to be trustworthy. It has to have a reliable human checkpoint before money goes out the door, and this company already had the structure in place to provide one, it just hadn't been stress-tested against a real edge case yet.

This same pattern, a plan design that's structurally correct getting undermined by a narrow calculation or timing defect, is one we keep running into across very different trades. A performance pay platform built on real job data is only as good as the arithmetic actually running underneath it, and that arithmetic deserves a second look even when, maybe especially when, the plan behind it sounds simple enough that nobody thinks to double check the formula. We saw the same instinct pay off for an HVAC company that caught a payroll rule bug the same day it would have hit a paycheck, and for a plumbing company that found a bonus formula quietly drifting from what it was supposed to require.

What Almost Went Out The Door

It's worth sitting for a second with what this catch actually prevented. Had the summing bug made it into a live payroll run, every technician on the plan would have received their full hourly pay and their full commission for the same hours worked, on every single pay period, not as a one-time bonus but as the plan's ongoing default behavior. That's not a rounding error or a one-off dispute waiting to happen. That's a structural overpayment built into the formula itself, one that would have compounded quietly, pay period after pay period, until either the numbers got big enough to notice or someone happened to check the math the way this call did.

The company caught it before that happened, which is really the entire story here. Not a dramatic recovery from a costly mistake, a routine feedback call that turned into a real save because someone was willing to open up the actual calculation instead of taking the summary numbers at face value. Mike's plan is to run the corrected system for the upcoming payroll and flag anything that still looks off, which is exactly the right instinct: a fix applied live on a call is a good start, not a guarantee, and the real confirmation comes from watching it hold up against a real pay period.

A structural overpayment doesn't announce itself with one bad check. It shows up as the plan's default behavior, quietly, every single period, until somebody checks the formula instead of the total.

If your own team runs a hybrid pay structure, hourly or commission, base or bonus, guaranteed minimum or performance upside, whichever pays more, it's worth doing exactly what surfaced this catch: sit down and trace one technician's actual number back through the formula, by hand if you have to, rather than trusting that "whichever is higher" logic is doing what its name says. The two most common failure modes are almost mirror images of each other. Sometimes a system silently picks the lower number, quietly shortchanging the people it was supposed to protect. Sometimes, like here, it silently combines both, paying out more than the plan was ever designed to give. Neither failure looks alarming from the outside. Both are only visible once someone actually checks the arithmetic against the plain-English version of the rule everyone agreed to.

None of this required a new platform, a new pay philosophy, or a difficult conversation with the team. It required one person opening up the plan, comparing what it said against what it was actually doing, and being willing to ask the unglamorous question: does this number really mean what we think it means. That question is available to any owner running performance pay off any software, on any trade, at any time. Most of the time the answer will be reassuring. Occasionally, like here, it's the difference between a formula that quietly pays double and one that does exactly what it was built to do.