The Phone Bonus Bug That Was Quietly Costing $60,000 a Year Per Rep

A commission plan or bonus program is code. It runs on rules, thresholds, and system fields, and like any code, it can break the moment something upstream changes. Most owners don't think about incentive pay this way. They set the plan once, hand it to accounting or ops, and assume it will keep running the way it was designed. Then a software vendor pushes an update, a job status field gets renamed, or a workflow rule gets tweaked, and the plan starts paying out something completely different from what anyone intended.

The scary part is that these breaks are usually invisible until the numbers show up in payroll. Nobody gets an alert saying your bonus formula just changed. The checks just get bigger, or smaller, or start rewarding behavior nobody meant to reward. By the time someone notices, months of payouts have already gone out the door, and the behavior the bonus was supposed to drive has quietly stopped.

That is close to what happened at a plumbing company in the Midwest that runs a busy inbound call center for its drain cleaning and plumbing crews. The company had built a bonus program to reward its customer service reps, the people answering phones and booking jobs, for converting calls into revenue. It worked well for a long time. Then a rule change inside its field service software quietly rewired how two fields interacted, and the whole program started paying out wrong.

A phone team, a bonus plan, and a hidden dependency

The company's CSR team handles inbound calls: homeowners with a backed-up line, a leaking water heater, a clogged main. Each call that turns into a booked, sold job is tracked in the company's field service platform using two fields, who the job was sold by and who it was assigned by. The bonus program was built around those two fields working together, with sold-by credit only counting toward a rep's bonus once the assigned-by logic confirmed the job was legitimately theirs.

Then the software vendor changed how those fields interacted on pending jobs. The assigned-by check that used to gate the bonus stopped functioning as intended, and sold-by credit started flowing through on its own, often to reps who had nothing to do with actually closing the job. Nobody at the company touched the compensation plan. The plan's logic didn't change. The field it depended on did, and that was enough to break everything downstream of it.

The operations lead running the phone team noticed the payouts first. The numbers were coming in nearly double to two and a half times what they should have been, and it was obvious something had gone very wrong. Paying out at that rate meant handing over enough in bonus money each year to cover almost another full-time hire, and it wasn't buying the company anything close to that in return.

The math was blunt. CSRs who had been earning somewhere between $150 and $200 a week in bonus pay were suddenly bringing home close to $400 a week. Run that gap out over a year, per person, across a team, and it lands around $60,000 in overpayment for every single rep if nobody caught it. For a small or mid-sized trades business, that is not rounding error. That is a wrong-headed second salary line hiding inside a bonus program.

There was a second problem that took a little longer to surface, and it was arguably worse than the money. Once the bug let sold-by credit through without requiring the assigned-by confirmation, CSRs no longer needed to make outbound calls to hit their numbers. Outbound calling, following up on quotes, checking in on maintenance plans, re-engaging past customers, had always been a core part of the job and a real driver of revenue. With the bonus paying out regardless, the team stopped doing it. Nobody made an announcement that outbound calls no longer mattered. The metric just stopped requiring them, and behavior followed the metric, the way it always does.

Finding the break before it became permanent

Diagnosing this kind of failure takes more than glancing at a payroll report. The payout numbers alone would tell you something was off, but not why. The real diagnostic work happened in the underlying job data, pulling the sold-by and assigned-by fields for the affected weeks, lining them up against actual call logs, and watching where the two fields disagreed with each other after the vendor's rule change went live.

That comparison made the mechanism obvious. Jobs were getting sold-by credit attached to reps who had no assigned-by record tying them to the work. Before the change, that combination would have been blocked. After it, the block was gone, and the bonus engine had no way of knowing the difference between a rep who earned the credit and one who simply happened to be sitting in the queue when a job landed. Once that pattern was confirmed across enough jobs, it was clear this wasn't a one-off payroll error. It was a structural gap between how the software now handled those two fields and how the compensation plan assumed they would always behave.

Fixing the sold-by and assigned-by logic without opening a new hole

The obvious fix, just restore the old assigned-by check, wasn't actually safe to make on its own. The vendor's rule change had happened for a reason, and simply reverting it risked blocking legitimate sold-by credit on jobs that were now structured differently on the pending side. So the fix removed the incorrect assigned-by check specifically on pending jobs, letting sold-by data trigger bonus credit the way it was supposed to, without requiring a field that no longer applied cleanly in every case.

That change alone created a new risk: double payment. On jobs where more than one CSR had touched the file, both could now show up with sold-by-style credit, and without a tiebreaker, the company would end up paying two people for the same job. The fix for that was a 0% split condition built into the plan logic, a rule that identifies when a job has more than one qualifying touchpoint and makes sure the payout splits down to zero for anyone who isn't the actual point of sale, instead of paying both in full. It is a small rule with an outsized job. It keeps a legitimate fix from turning into a new leak.

Why a bonus needs more than one gate

The deeper lesson in this fix wasn't really about ServiceTitan fields. It was about relying on a single metric to gate a bonus. A bonus tied to only one number, sold-by credit in this case, will always be vulnerable to whatever can move that number without the underlying work happening. Add a second, independent qualifier that has to be satisfied first, and you close most of that gap, because now two different things have to be true at once instead of one.

For this team, that meant putting a mandatory outbound-call qualifier in front of the inbound bonus. CSRs now have to hit 100 outbound calls a week before any inbound bonus dollars can pay out at all. It doesn't matter how much sold-by credit a rep racks up. If the outbound number isn't there, the bonus doesn't release. That single requirement did more to restore the original behavior of the program than anything else in the fix, because it reattached the bonus to the actual job duty it was designed to reward in the first place.

A second qualifier went in at the van level: a minimum of $150 in weekly revenue per van, with $175 set as the stretch target the team is actually pushing toward. That keeps the program anchored to real production, not just call volume or credit assignment, and it gives the team a second, concrete number to rally around each week.

Once the outbound requirement went in, the operations lead put it plainly: the team went back to making the calls that mattered, because the bonus finally required it again instead of assuming it.

Underneath both qualifiers, the company also had to fix the size of the pool itself. Even with the sold-by and assigned-by logic corrected and the qualifiers in place, the group bonus payout percentage had been set at 0.18 of total revenue, a number that had been drifting the plan's cost structure upward for a while. Bringing it down to 0.06 of total revenue reset the pool to a level that actually matched what the company intended to spend on the program, rather than what a broken field happened to be generating. Getting this kind of incentive plan design right means treating the payout percentage, the qualifiers, and the underlying data fields as one connected system, not three separate settings that can each drift on their own.

What the fix actually changed on payday

Once the corrected logic, the qualifiers, and the reset payout percentage were all live, the numbers came back down to where they belonged. CSR bonus payouts settled back into the $150 to $175 a week range the program had always been designed to produce, down from the roughly $400 a week the bug had been generating. Across a full CSR team, avoiding that gap is worth an estimated $60,000 a year in overpayment per person, money that was never budgeted to go out and would have kept going out indefinitely if the bug had gone unnoticed.

The behavior side came back too, and arguably that mattered more than the dollars. With the outbound-call qualifier in place, CSRs went back to making the calls that had quietly stopped once the bonus paid out without them. That's the part of this story that's easy to miss if you only look at the payroll totals. A broken metric doesn't just cost money, it can also unteach a habit that took real effort to build in the first place.

This isn't just a plumbing problem

Any business running incentive pay on top of a field service platform has this same exposure, whether it's an HVAC company paying commission on install jobs, an electrical contractor splitting spiffs across a crew, or a facilities team tracking work order completion rates to hand out bonuses. The specific fields will look different. The risk is identical. A bonus formula that depends on a system field is only as stable as that field, and vendors change fields for their own reasons on their own timelines, without checking whether your compensation plan is watching.

It shows up especially fast anywhere a phone team or CSR group is involved, because call center bonus structures tend to lean on one or two fields to measure something that is actually a multi-step process: answer the call, quote the job, book the job, close the job. Collapse all of that down to a single system field and you've built a single point of failure into your payroll. This is just as true for HVAC dispatch teams as it was for this plumbing teams phone group, and it's worth an audit even if nothing looks obviously wrong yet.

What to check in your own bonus plan

• Map every field your bonus depends on. If a payout formula references a status, a sold-by, an assigned-by, or any other system field, know exactly which one and write it down somewhere outside the software itself.
• Require more than one qualifier before a bonus releases. A single metric gate is a single point of failure. Layering in a second requirement, like a call count or a revenue floor, protects the plan when one input goes sideways.
• Watch payout trends weekly, not quarterly. A jump from $175 to $400 a week is obvious if you're looking every week. It's much easier to miss, and much more expensive, if you only check in three months later.
• Build in a split rule for jobs with multiple touchpoints. Fixing one bug can open a double-payment gap if you don't explicitly handle cases where more than one person qualifies for the same job.
• Revisit your payout percentage on a schedule. A pool percentage that made sense a year ago can be quietly overfunding the plan today, especially after any change to the underlying data it's calculated against.

None of this requires exotic software or a finance degree. It requires treating the bonus plan as a living system that depends on other systems, and checking on it with the same regularity you'd check on any other piece of the business that touches real money every week. The plumbing company running that phone team caught this one before it became a permanent cost of doing business. Most owners get the chance to catch theirs too, if they're looking in the right place.