The Dispatcher Mix-Up That Turned One Bonus Plan Into Eighteen

The Mess Behind One Bonus Plan

Running one incentive plan is hard enough. Running a fair one across electricians, plumbers, HVAC techs, installers, helpers, and dispatchers, all in the same shop, all contributing in completely different ways, is a different kind of hard.

That was the situation at a family-owned electrical, plumbing, and HVAC company running about a dozen field technicians, installers, and dispatchers. On paper, they had bonus programs. In practice, the numbers behind those programs were held together with spreadsheets, side calculations, and a fair amount of trust that nobody bothered to double-check.

It's a familiar setup for any multi-trade shop that's grown past the point where one person can eyeball payroll and know it's right. An electrician closing an upsell on a service call gets paid differently than an HVAC installer finishing a two-system swap, who gets paid differently than a helper riding along on that same job, who gets paid differently than the dispatcher who routed the truck in the first place. Every one of those roles needs its own math. And every one of those math problems was, in this case, quietly wrong in a different way.

Job-completion bonuses were the first thing to unravel. Technicians were judged against daily targets, a fixed number of jobs a day, every day, with no room for a slow Tuesday or a job that ran long for reasons nobody could control, a tricky diagnosis, a parts run, a customer who wasn't home. Hit the number and get paid. Miss it, for any reason, and you didn't. Over a full month that kind of targeting produces a lot of frustration and very little signal about who's actually performing well. It penalizes bad luck as harshly as it penalizes bad work, and after a few months of that, most techs stop trusting the bonus enough to plan around it at all.

Efficiency bonuses had a quieter problem. The idea was simple: reward techs who complete jobs faster without cutting corners. But there was no clean way to measure how much time a job actually took. Without real start and end timestamps, "efficient" was more of a guess than a metric, and guesses don't hold up when they're tied to a paycheck.

Then there was the CSR booking-ratio incentive, which turned out to be broken in a way nobody had caught. Dispatchers had been misclassified as CSRs in the source system. That one mislabel fed directly into the booking-ratio math used to calculate CSR pay, which meant the people answering calls and the people dispatching jobs were getting blended into a metric that was supposed to isolate one specific behavior. The bonus looked precise. It had a formula, a percentage, a payout. It wasn't measuring what anyone thought it was measuring.

This is the kind of problem that's almost impossible to spot from the outside. Nobody sat down and decided dispatchers should count as CSRs. Somewhere, at some point, a role got tagged wrong in the system of record, and from that point forward every booking-ratio calculation quietly inherited the error. The people running the business had no reason to suspect the bonus math itself. It looked like it was working. It was just working on the wrong inputs.

Installer helpers had their own issue: on complex jobs, they risked being counted twice, which inflated payouts in ways that were hard to catch without going line by line through job records. A single combined install, the kind that involves two systems and two line items, could end up crediting a helper for what looked like two separate jobs instead of one, and nobody was auditing helper pay closely enough to notice the pattern. And additional work sold on the spot by electricians and plumbers, upsells and add-ons that happen constantly in the field, lived in a separate system that wasn't reliably feeding the numbers used to calculate their payouts. The sales were happening. The pay calculations just weren't seeing all of them, which meant electricians and plumbers were doing the extra work of selling add-ons without always getting credited for it.

Individually, none of these were dramatic failures. Nobody was trying to shortchange anyone, and nobody was trying to game the system either. Together, though, they meant that a business owner trying to run fair pay across six or seven distinct roles was working from numbers that quietly didn't add up, in at least four different directions at once. That's a hard thing to fix by staring harder at a spreadsheet. It takes rebuilding the math from the job data up.

Fixing It, Plan by Plan

Fixing this wasn't a single switch. It took working call by call with the company's operations team over several weeks, plan by plan, department by department, to get the underlying math right before any of it touched a paycheck. There was no shortcut for this part. Each role's pay depended on a different slice of job data, and each slice had to be checked against how the work actually happened in the field before it could be trusted to run automatically.

The job-completion bonus moved from a daily target to a monthly one. That single change removed the all-or-nothing pressure of any given day and let performance get measured the way it actually happens, over a full month of real work, good days and bad ones included. A tech who has one rough Tuesday no longer watches an entire bonus evaporate over something outside their control.

The install pool itself got rebuilt from the ground up. Completed jobs were valued at $10 each, with a 10% deduction applied for callbacks, so rework stopped being invisible in the math. If a job came back, the pool felt it, which is exactly how it should work. Complex jobs got fixed too: a combined AC-plus-furnace install, for example, now correctly counts as two jobs instead of one, since it genuinely is two jobs' worth of work condensed into a single visit. That sounds like a small adjustment. For the crews doing those combined installs regularly, it was the difference between a pool that reflected their actual workload and one that quietly undercounted it every time.

Helpers were moved to a flat $5 per job, with the double-counting bug closed so nobody was drawing pay twice off the same install. It's a simple number, but simple was the point: a flat rate per job is easy to verify and impossible to accidentally duplicate once the underlying job count is right. Efficiency bonuses got rebuilt on top of real job start and end timestamps instead of estimates, so "fast" finally meant something measurable instead of something implied. A technician's actual time on site became the input, not someone's best guess at how long a job like that usually takes.

Technician commission was set at 2% of sales, with an extra 1% kicker once a tech's average ticket cleared $500. That kind of tiered structure rewards technicians for both closing work and closing good work, without punishing anyone for a slower week. It also gives techs a concrete number to aim for instead of a vague sense that bigger tickets are somehow better. CSR and dispatcher roles were reclassified so the booking-ratio math finally reflected who was actually answering the phone versus who was routing trucks, which meant CSR pay stopped absorbing dispatcher activity it was never supposed to include. That one fix alone corrected every booking-ratio calculation downstream of it, without anyone having to manually re-audit past pay periods.

And underneath all of it, every employee got a live dashboard showing their own numbers in real time. No more waiting on a spreadsheet at the end of the month to find out whether the job counted, whether the callback got deducted, or whether the ticket average cleared the kicker threshold. The number on the dashboard is the number that shows up in the paycheck, and that consistency does more for trust in a bonus program than any policy memo ever could. When people can watch their own numbers move throughout the month, they stop wondering whether the math is fair and start focusing on the work in front of them.

Eighteen Plans, Real Numbers

What started as one bonus plan with three data problems has scaled into 18 separate active incentive plans running across the business at once. Roughly half run weekly, covering on-call electricians and plumbers along with a separate individual sales commission plan for each sales rep. The rest run monthly: install crews, technician scorecards, installer helpers, each tuned to how that specific role actually gets paid. Nobody set out to build 18 plans. That number is simply what it took once every role's pay got measured on its own terms instead of forced into a formula built for someone else's job.

The numbers behind those plans are real and current. The electrical on-call program alone is tracking roughly $13,600 in incentive pay across a ten-person team of technicians and dispatchers. The core technician commission program is tracking roughly $47,000 in awards across thirteen technicians. These aren't projections or estimates run for a case study. They're live totals from a system that's currently running, updating as jobs close and tickets get written, the same numbers the techs themselves see on their dashboards.

What's worth noticing is how different those two programs are from each other, even though they sit inside the same company. The on-call program pays out weekly and covers a mixed team of technicians and dispatchers responding to after-hours calls. The commission program pays out on a rolling basis tied directly to sales, covering thirteen technicians whose work looks nothing like on-call response. Trying to run both off one shared formula is exactly what caused the original mess. Running them as two of eighteen distinct, correctly-scoped plans is what makes each number trustworthy on its own.

What began as a single bonus plan with data problems is now a company-wide system of 18 coordinated incentive plans running side by side. That's the real shift here. It's not that one bonus program got fixed. It's that fixing it exposed how many genuinely different ways people across a multi-trade shop contribute, and once the underlying data was trustworthy, it became possible to build a plan for each one instead of forcing everybody into the same formula.

Most owners running electrical, plumbing, and HVAC crews under one roof don't set out to build 18 plans either. They start with one bonus program, usually modeled on whichever department is easiest to measure, and stretch it to cover everyone else. It works fine until someone finally pulls the thread on the numbers and finds three or four small, unrelated problems hiding underneath. The fix isn't a bigger spreadsheet. It's treating each role's pay as its own calculation, built on the data that role actually generates.

A few things worth taking away if you're running incentive pay across more than one department:

• A daily target is a coin flip, not an incentive. Moving job-completion bonuses to a monthly cadence turned noisy, punishing math into something technicians could actually plan around.
• Misclassified roles quietly break downstream math. A dispatcher tagged as a CSR doesn't just mislabel a person, it distorts every ratio that role feeds into.
• "Efficient" needs a real clock. Estimates make efficiency bonuses feel arbitrary. Actual start and end timestamps make them feel earned.
• Complex jobs deserve complex counting. A two-system install is two jobs of work. Paying it like one job shortchanges the person who did it.
• Visibility changes behavior. A live dashboard does more to build trust in a bonus program than any explanation ever will.

The bigger pattern is one we see constantly with growing multi-trade shops: electrical, plumbing, and HVAC companies rarely have one pay problem, they have five or six small ones scattered across departments, each invisible until someone goes looking. If you want to see how ShareWillow actually builds out pay calculations like these, from job-level data to a live number on a dashboard, that's the mechanism behind every plan mentioned here. It's a similar story to how one HVAC company replaced paper spiff forms with automated payouts, different trade, same underlying idea: pay is only fair when the data behind it is actually right. If your shop is running incentive pay off spreadsheets and side calculations right now, it's worth finding out what those numbers are actually missing. Get started with ShareWillow and see what a live, accurate plan looks like for your team.