The $60,000 Bonus Bug Hiding in a Plumbing Company's Payroll

Most bonus plan disasters do not announce themselves. They do not show up as a dramatic failure everyone notices right away. They show up as one small rule, buried three layers deep in an attribution formula, quietly doing the opposite of what it was supposed to do, for weeks, until someone finally runs the numbers forward and does the math out loud.

That is almost exactly what happened at a regional plumbing and drain-cleaning company running its customer service and dispatch bonus program through ShareWillow, on top of ServiceTitan. The team caught it in time. But the story of how close it came, and what it took to catch, is worth sitting with if your own office bonus plan runs on any kind of automated attribution logic.

From Spreadsheet Math to a Real Rule Engine

Before ShareWillow, the office team's bonuses were calculated the way a lot of growing companies handle it: manually, off exports from ServiceTitan, reconciled by hand in a spreadsheet every pay period. It worked, in the sense that checks eventually went out correctly, but it consumed real hours from someone's week and depended entirely on that one person catching every edge case by memory.

Digitizing that process is usually a clean win. You take the rules that used to live in someone's head and a spreadsheet formula, and you encode them as an actual rule engine that runs the same way every single time. That is exactly what this company did, building qualifiers around ServiceTitan's own "sold by" and "assigned by" job attribution fields to determine which CSR or dispatcher earned credit for which booked job.

The problem is that automation only works as well as the logic underneath it. And in this case, two of those attribution fields were quietly fighting each other.

The Bug: A Gate That Was Never Supposed to Be a Gate

The plan had a qualifier requiring a CSR to actually make outbound calls before they could earn credit for a booked job, a reasonable rule meant to reward the behavior that drives new bookings, not just credit whoever happened to be logged in when a call came through. But an "assigned by" check, meant only for a different part of the workflow, was silently gating the "sold by" credit unless the job's split was zeroed out first.

In practice, that meant CSRs were getting paid bonus credit without actually making the outbound calls the plan was supposed to require. At the same time, a separate change in how the plan calculated group payouts, shifting from an individual calculation to a pooled one, was quietly inflating the total payout beyond what anyone had intended.

The office manager caught it live, mid-conversation, doing the annualized math out loud before the payroll cycle went out.

"But I also can't pay $400, that's 20,001 a year. I can't do that. That's each person, that's 60,000. That's a whole another body. I... it's too much."

Read that quote slowly. The plan was designed to pay somewhere around $150 to $200 a week per qualifying person. Left uncorrected, the actual math was tracking toward roughly $60,000 a year, per person, which is not a rounding error. It is the fully loaded cost of hiring an entire additional employee, showing up instead as a silent leak in a bonus plan nobody was watching that closely.

Tracing the Bug in Real Time

What makes this story useful, rather than just alarming, is what happened next. Instead of shutting the whole plan down or reverting to manual spreadsheets out of fear, ShareWillow's team diagnosed the root cause live, on the same call where the office manager first flagged the number. The fix had three parts.

First, the faulty "assigned by" check was removed entirely from the outbound-call qualifier, so it could no longer silently override the sold-by credit logic it was never supposed to touch. Second, payroll for the affected period was re-synced once the corrected rule was in place, so the numbers going out matched what the plan was actually designed to pay. Third, and this is the part a lot of quick fixes skip, the group payout percentage was recalculated from scratch, dropped from 0.18 down to roughly 0.06 of total revenue, to match the original per-person math instead of the inflated pooled version that had crept in.

Two new qualifiers were added at the same time to tighten the plan going forward: a requirement of 100 outbound calls per week, and a per-van revenue threshold of $150 to $175 a week. The booking-rate bar the team had been targeting was also raised, from 60% up to 80%, as part of the same correction.

Why This Kind of Bug Is So Easy to Miss

It is worth being honest about why a bug like this can live inside a plan for weeks without anyone noticing. Multi-invoice jobs, a jet job and a sewer job on the same visit, for instance, already complicate attribution on their own. Add a rule meant for one part of the workflow quietly interacting with a rule meant for another part, and you get exactly the kind of interaction that is invisible until someone runs the full-year math forward.

This is not a knock on the team that built the original rule. It is a case for why ongoing plan reporting, not just plan design, matters so much. A comp plan is not a document you write once and forget. It is closer to a piece of software: it needs monitoring, it needs someone checking the outputs against expectations regularly, and it needs a fast path to a root-cause fix when a number looks off, instead of a slow scramble the week payroll is due.

What Facility Managers and Office Leads Can Take From This

If you manage a customer service or dispatch team, even outside plumbing specifically, this story maps onto a problem a lot of plumbing, HVAC, and general field-service businesses share: bonus rules that reward behavior indirectly, through a system field, instead of directly, through something a manager can eyeball in five minutes.

"Sold by" and "assigned by" fields exist inside ServiceTitan for good operational reasons. But when a bonus plan's payout depends on the exact interaction between two fields like that, it is worth periodically asking a simple question: if I picked five recent payouts at random and traced them back to the actual calls made and jobs booked, would the story match what the system says happened? If you cannot answer that quickly, you likely have a version of this same bug sitting quietly in your own plan, waiting for someone to eventually run the annualized number out loud.

What Trust Actually Costs When a Bonus Plan Misfires

There is a version of this story that never gets told, because the bug never gets caught. In that version, the inflated payouts keep going out quarter after quarter. Eventually someone in finance notices labor cost creeping up in a category nobody can quite explain, and the investigation that follows is a lot less comfortable than one office manager catching the annualized math on a single call.

Or the opposite happens: an owner notices the number looks too high, panics, and cuts the bonus plan back sharply without understanding why the number was wrong in the first place. That overcorrection tends to hit the CSRs and dispatchers who were doing everything right just as hard as it hits the actual source of the error. Once a team feels like their bonus program is unpredictable, in either direction, they stop trusting it, and a bonus plan nobody trusts stops changing behavior at all. It just becomes a line item.

That is really what was protected here. Not just $60,000 a year, though that number is real and worth taking seriously on its own. What was protected was the team's confidence that the plan pays what it says it will pay, no more and no less, which is the entire foundation a good incentive program is built on. A plan people cannot predict is a plan people eventually ignore.

A Simple Audit Any Owner Can Run This Week

You do not need a data science background to check for a version of this bug in your own bonus program. Pull five recent payouts at random, ideally ones that look ordinary rather than the largest or smallest on the list. For each one, trace it back manually: who booked the job, who was assigned to it, what qualifiers the plan requires, and whether the payout actually reflects those specific facts.

If all five check out cleanly, that is a good sign, though not a guarantee. If even one of them requires more than a couple of minutes to explain, or produces a number that surprises you, that is worth digging into before it compounds across an entire pay period, let alone an entire year. The plumbing company in this story got lucky in one specific sense: someone happened to do the annualized math out loud during a routine call, rather than three months into a growing, invisible overpayment. Most businesses should not have to rely on luck for that.

The Takeaway

Nobody in this story did anything careless. The original rule made sense on its own. The pooled payout change made sense on its own. It was the intersection of the two that quietly broke, the way most real bugs do, not through one obvious mistake but through two reasonable decisions that never got tested together.

• Automating a manual bonus process is a real improvement, but only if the underlying rules are tested against edge cases, not just the happy path. Multi-invoice jobs, split credit, and pooled payouts are exactly where automated logic tends to break first.
• Do the annualized math on any new bonus number before it goes live. A $400 weekly payout sounds reasonable in isolation. Multiplied out per person per year, it can reveal a problem a weekly view will never show you.
• Catching a bug is not a failure of the system, it is the system working. The real risk is not that an error exists somewhere in a rule engine. It is not having a fast, direct path to trace a payout back to its source and fix it before the next check goes out.
• Bonus plans need the same ongoing attention as any other piece of business software. Build it once, then check it regularly, especially any time the underlying data fields or job workflows change.

A $60,000-a-year near-miss is a big number to catch on a single call. It is an even bigger number to imagine catching six months later, after it had already gone out the door a dozen times over. The lesson is not that automation is risky. It is that the right kind of automation makes it possible to catch a problem like this in the room, in real time, instead of in a much more painful conversation months down the road.