How an HVAC and Duct Cleaning Company Fixed Its Broken Technician Payroll

Ask any HVAC owner what keeps a good technician around, and pay comes up before the truck, the tools, or the schedule. Not just the number on the check, but whether the tech believes the number is right. Once a technician starts doing their own math in their head on the drive home, wondering if this week's bonus is short, you've lost something that's genuinely hard to get back, even after you fix the underlying problem.

That's what happened, in miniature, at a small HVAC and duct-cleaning company that had just rolled out a new commission and bonus platform. The rollout wasn't the problem. What the platform surfaced, and eventually fixed, was a set of payroll errors that had almost certainly existed for years, quietly, inside a manual process nobody had ever had a reason to fully audit.

The paycheck nobody trusted

Every Friday, the office manager at a small HVAC and duct-cleaning company sat down with a calculator, a stack of job tickets, and a spreadsheet she'd built herself. Her job, as she saw it, wasn't just running payroll. It was catching the mistakes before the technicians did.

She had reason to be careful. A few weeks into using a new payroll and incentive platform, the numbers coming out of the software didn't match the numbers she was calculating by hand. One technician's payout showed $1,724 in the system, but her own math, done job by job, put it higher. Multiply a gap like that across a small team and fifty-two weeks a year, and you're not looking at a rounding error. You're looking at thousands of dollars a year in the wrong place, and a team that starts double-checking every check.

This is a more common story than most HVAC and duct-cleaning owners like to admit. It's rarely one big, obvious failure. It's a handful of small, quiet ones that compound: a job miscoded, a travel minute counted twice, an after-hours call paid like a regular one. Individually, they look like noise. Added up over a team and a year, they're real money and, worse, real trust.

Where the math actually broke

When ShareWillow's implementation team sat down with this company to figure out why the platform's numbers and the office manager's spreadsheet kept disagreeing, they found four separate, unrelated bugs, all hiding in plain sight inside data most owners never think to audit.

1. Duct cleaning was coded as an install

The field service software's job-type field was doing double duty. Duct-cleaning jobs, which should have been paid on a flat-fee service structure, were tagged the same way as installation jobs, which run on a different commission logic entirely. Nobody set out to misclassify anything. It happened because a dropdown had too few categories and a busy dispatcher picked the closest one. But the commission engine downstream took that tag literally, and every duct job quietly inherited the wrong pay math.

2. Travel time was being paid as labor

The second bug was subtler and more expensive. The system was counting idle time between jobs (the ten or fifteen minutes a truck sits at a red light or waits for a customer to answer the door) as billable travel time feeding into labor-based bonus calculations. On its own, a few minutes here and there looks trivial. Projected out across a team and a year, the implementation team estimated it could have caused a $30,000 annual overpayment if it had gone uncaught.

3. After-hours jobs weren't paying the on-call premium

Emergency, after-hours service calls were being logged the same way as routine daytime residential jobs. That meant technicians who got pulled out of bed for a no-heat call at 11 PM were being paid exactly what they'd have earned for a scheduled Tuesday afternoon tune-up. The fix was a straightforward $25 automatic bonus triggered whenever a job was tagged after-hours or emergency, so the premium a tech expects for answering a midnight call actually showed up in the number they saw.

4. The same job was being counted twice

The last bug was the kind that's almost impossible to catch by eyeballing a report: a duplicate-commission error where a single job number, re-opened for a callback or a follow-up visit, was being counted as two separate commissionable jobs. It inflated payouts in a way that looked, on the surface, like generosity. It was actually just noise stacking on top of noise.

Fixing the math is only half the job

Once the four issues were identified, the fixes themselves were mechanical: reclassify the job types, exclude idle time from the travel calculation, add the after-hours rule, and de-duplicate the job-number logic. That part took about a week.

The harder part was rebuilding trust in the number itself, especially for an office manager who'd been personally reconciling payroll by hand for weeks and, understandably, didn't want to just take anyone's word that it was fixed now. ShareWillow's team walked her through the platform's plan summary and dataset views so she could see exactly which job fed which dollar amount, instead of treating the payout number as a black box she had to double-check from scratch every week. They recorded short, specific walkthroughs she could rewatch instead of having to remember everything from a live call. And they moved data processing to a predictable weekly cadence, so payroll had a fixed, reliable time to be finalized instead of a moving target.

The goal was never just to get the math right once. It was to get the office manager to a point where she trusted the platform enough to stop rebuilding it in a spreadsheet every week.

What "fixed" actually looked like

The real test wasn't a single reconciliation. It was whether the two numbers, ShareWillow's payout and the office manager's independent hand calculation, kept landing in the same place week after week without her doing the detective work.

Roughly nine weeks after the first frustrated call, they did. Weekly comparisons that had once shown gaps in the hundreds of dollars per technician were now landing within $6 to $100 of each other on a multi-technician team, close enough to be explained by normal timing differences (a job that closed out Friday afternoon versus Monday morning) rather than a system error. Two representative weeks told the story plainly: one showed $1,455 in ShareWillow against $1,449 calculated by hand. Another showed $926 against $986. Not identical. Close enough that nobody needed a calculator to sleep at night.

That's the number that actually matters here, more than any single dollar figure: the gap between two systems tracking the same reality went from "a technician's entire bonus" to "the cost of a coffee." For a small team, that's the difference between a bonus program employees trust and one they quietly resent.

Why "close enough" was never good enough

It would be easy to read this story and think the stakes were mostly about the $30,000 travel-time exposure, and that number is real. But the more expensive risk in a story like this one usually isn't the dollars. It's what happens to a team when a bonus program stops feeling fair.

Technicians talk to each other. If one tech's payout looks light one week for no obvious reason, it doesn't stay a private frustration for long. It becomes shop talk. And once a crew starts assuming the bonus math is rigged, or just broken, in a way management either doesn't know about or doesn't care about, the program stops motivating anything. It becomes a source of resentment instead of a reason to hustle on the last job of the day.

That's the real cost of the four small bugs above. Not the overpayment risk, which is recoverable. The erosion of a team's belief that the numbers are real, which is much harder to rebuild once it's gone. This is also, not coincidentally, why the office manager's instinct to hand-check everything wasn't overcaution. It was the correct response to a system that hadn't yet earned her trust. The goal of fixing the underlying data wasn't to make her checking unnecessary in theory. It was to make it unnecessary in practice, because the numbers were finally right often enough that she didn't need to verify them herself.

What to check before you roll out (or audit) a bonus plan

You don't need to be switching platforms to have this problem. Most HVAC and duct-cleaning companies running any kind of tiered bonus, commission, or incentive structure, whether it lives in a piece of software or a homegrown spreadsheet, have some version of these four issues sitting quietly in their data right now. A few places to look:

• Job type mapping. Pull a list of every distinct job type your field service software actually uses, then check whether each one routes to the correct pay logic. Dropdowns tend to get added over time without anyone revisiting how the original categories were supposed to work.
• Travel versus labor time. If your bonus math is built on labor hours, confirm that "labor hours" actually excludes drive time and idle time between stops. This is one of the most common and least visible sources of overpayment in field service commission plans.
• Premium pay triggers. If after-hours, weekend, or emergency work is supposed to pay differently, verify that the trigger is automatic and based on the job record, not dependent on someone remembering to flag it manually.
• Duplicate job protection. Ask what happens, technically, when a job gets reopened for a callback or warranty visit. Does it inherit a new job number that could get double-counted, or is it correctly tied back to the original?

None of these require new software to check. They require about an afternoon with whoever owns your dispatch and payroll data, and a willingness to actually trace a few individual jobs end to end instead of trusting the summary report.

The pattern behind the story

None of these four bugs were unique to one company's setup. They're the predictable result of how most HVAC and duct-cleaning shops actually operate day to day: dispatchers under time pressure picking the closest dropdown option instead of the exact right one, field software that wasn't originally built with commission logic in mind, and job types (duct cleaning, emergency calls, callbacks) that don't map cleanly onto the categories a generic system assumes.

If you run an HVAC, duct-cleaning, or broader home services team and you've never actually audited how a technician's bonus gets calculated from raw job data to final number, it's worth an afternoon. A few questions worth asking your own systems:

• Are duct cleaning, maintenance, and install jobs actually tagged as separate job types, or do they share a category that was "close enough" when someone set it up three years ago?
• Does your travel-time calculation distinguish between a truck actually driving and a truck sitting idle?
• Do after-hours and emergency calls pay a visible premium, or do they quietly pay the same as a Tuesday afternoon?
• Could a callback or reopened job accidentally get counted as a second billable job?

Most owners assume payroll errors, when they happen, are big and obvious. In practice, they're almost always small, structural, and hiding in a dropdown menu. The fix isn't more oversight from the office manager. It's a system precise enough that she doesn't have to provide it herself.

You're not the only shop that's had this problem

This kind of quiet payroll drift shows up across the trades more often than most owners realize, and not always in the same shape. One HVAC contractor caught a set of bonus system bugs that, once fixed, doubled what technicians actually took home without changing the underlying pay structure at all. A water delivery route found they could cut false payroll alerts by 79 percent just by tightening how their system flagged exceptions. And another team moved off manual reconciliation entirely by automating technician bonus payroll from days of work down to minutes.

The common thread isn't the specific bug. It's that nobody had looked closely enough, recently enough, to find it. If your team runs any kind of technician bonus or commission plan today, whether it's built on a dedicated platform or held together with a spreadsheet and good intentions, it's worth treating payroll accuracy as its own project, not an assumption. The alternative isn't a dramatic failure. It's a slow leak that shows up as turnover, resentment, or a Friday afternoon spent with a calculator, trying to prove a number that should have just been right the first time.