Four Dashboard Bugs an HVAC Contractor Caught Before a Single Bonus Went Out

The Audit Nobody Budgets For

An HVAC contractor doing roughly $1.1 million in revenue the prior month, and already sitting at about $280,000 for the current month, was two weeks out from launching incentive pay for both technicians and customer service reps. September go-live. Plans built, thresholds set, everyone bought in. The only thing left was to make sure the numbers feeding those plans were actually correct.

That last step is the one most companies skip, or do halfheartedly, because by the time you get to launch you've already spent weeks on plan design, buy-in, and communication. The dashboard feels like a formality. It isn't. It's the thing every dollar of the plan will be measured against, and if it's wrong, the plan is wrong, no matter how well designed the compensation structure underneath it is.

On a working session ahead of the launch, ShareWillow's implementation team sat down with the owner and ran every dashboard metric against numbers the owner already knew, from memory, to be true. Total revenue. Roughly how many tune-ups a given CSR should have logged. Roughly how busy the install crews had been. It's a simple technique: if you already know the answer, you can catch the software lying to you. And in this case, the software was lying four separate ways.

Bug One: The Tune-Up Count That Was Off by a Factor of Seven

The first plan involved CSRs earning credit for scheduling maintenance tune-ups, a solid proxy for how much proactive selling a rep is doing on the phone. When the team pulled up one CSR's tracked count for the month, it showed 6 tune-ups. For a mid-month number on a team member who wasn't otherwise flagged as a low performer, that looked off.

The cause turned out to be a filter problem. The dashboard was matching job types against an exact string, something like "SVC-AC tune up." Any job logged slightly differently, say "SVC-AC tune-up" with a hyphen, didn't match and got silently dropped. Worse, tune-ups booked under a membership plan weren't captured by the filter at all, because they lived under a different job-type label entirely. The filter wasn't wrong on purpose. It was just built for one exact way of logging a job, and real-world dispatch data never stays that clean for long.

Once the team rewrote the filter to match any job type containing "tune up," in any punctuation or format, that CSR's count jumped from 6 to 46. Not a rounding error. The difference between a rep who looks like she's barely working and a rep who's actually one of the most productive people on the team. If that plan had gone live on the original filter, she would have opened her first incentive statement, seen a number a fraction of what she knew she'd earned, and had every reason to stop trusting the program on day one.

This is the pattern worth sitting with. The bug wasn't in the incentive plan's design. The commission structure the owner had built was fine. The bug was three layers underneath it, in how a job-type string got matched against a filter that someone configured once and never had a reason to revisit. That's exactly the kind of thing that hides in plain sight until a real paycheck is riding on it.

When the Data Just Isn't There

The second issue was simpler to describe and just as dangerous. One CSR's booking-rate number, the percentage of inbound calls she successfully converted into booked jobs, wasn't showing up on her dashboard at all. Not low. Not zero. Missing.

The root cause was a name-mapping mismatch. Booking-rate data for this team came from a separate spreadsheet tracked outside the main field service system, and the name used to identify her in that spreadsheet didn't match the name ShareWillow's system had on file for her, maybe a nickname, a middle initial, a formatting difference. To a human glancing at both sheets it's an obvious match. To a system doing exact-match joins between two data sources, it's two different people, and one of them has no data.

Once the team corrected the mapping, her real August booking rate appeared: 75 percent. That put her right in the middle of her team, alongside teammates showing 100 percent, 82 percent, and 59 percent. A solid, respectable number for someone who, on the broken dashboard, would have looked like she wasn't booking any calls at all. Imagine being that CSR, watching three teammates get credit for booking rate every pay period while your own column reads blank, with no explanation and no fix in sight until someone happens to audit the pipeline. That's not a bug you can talk your way out of after the fact. It has to be caught before the first check goes out. This is also the exact kind of failure mode that makes a dashboard built specifically for tracking incentive-plan data, with real data-mapping and validation built in, worth the trouble of getting right rather than duct-taping bonus math onto whatever reporting a dispatch tool happens to expose.

Bug Three: Install Revenue Showing Near Zero

The third bug was the one that should have been impossible to miss, and almost was. The dashboard's install jobs and install revenue widgets were both showing numbers close to zero. For a company doing roughly $1.1 million in revenue the month before and $280,000 already logged in the current month, that's not a metric that's a little low. It's a number that's obviously, absurdly wrong the moment anyone who knows the business looks at it.

The cause was a filter carried over from somewhere it didn't belong. The dashboard widget pulling install performance was built on top of a technician performance report, and that underlying report had a business-unit filter applied to it, one that had nothing to do with installs specifically. It had been set for a different purpose entirely and just happened to also silently exclude install jobs from anything built on top of it. Nobody chose to hide install revenue. A filter configured for one report quietly broke a different report built downstream of it.

The fix was to remap the widget to an unfiltered, install-specific report instead of inheriting one built for a different job. Once that was done, the real numbers appeared, in line with what the owner already knew the crews had been producing. This is the sanity-check habit worth building into every launch: if a number on the dashboard contradicts something you already know cold, like your own top-line revenue, don't assume the dashboard is right and your memory is fuzzy. Assume there's a filter somewhere doing something you didn't ask it to do.

Bug Four: A Number That Broke Math Itself

The fourth issue was the most subtle, and arguably the most instructive, because it didn't require any outside knowledge to catch. It just required someone to notice that a percentage was doing something a percentage isn't supposed to do.

Billable efficiency is meant to measure how productively a technician's paid hours convert into sold work: hours actually billed to a customer divided by hours the tech was paid for. On this dashboard, several technicians were showing efficiency numbers over 100 percent. That's a result that should stop you cold. A technician can be extremely efficient. He cannot, by definition, bill more hours of work than he was paid to be on the clock for that job. A number over 100 percent isn't an achievement. It's a signal that the math underneath it is broken.

The cause was a mismatch between two different units of measurement getting compared as if they were the same thing. "Sold hours" on a job reflect the total crew hours for that job, not any one person's time. A job sold at 14 hours might actually represent 28 combined technician-hours if two people worked it together. The efficiency calculation was taking that crew-level sold-hours number and dividing it by a single technician's individual paid duration, comparing a two-person number against a one-person number. That understates the denominator and inflates the ratio, and on a two-tech job, it can push the result well past 100 percent without anyone touching a fraudulent number anywhere in the chain. It's just the wrong two numbers being compared.

Be suspicious of any incentive metric that lands somewhere it logically cannot be, whether that's a booking rate over 100 percent, an install revenue number at zero for a company doing seven figures a month, or an efficiency score that would require bending physics. Extreme results in either direction are usually a data problem wearing a performance number's clothes.

The fix, still being finalized as of the working session, is to recalculate efficiency at the job level rather than the individual level: sum the paid duration of everyone who actually worked the job, then compare that combined total against the job's real sold hours. That keeps crew-level inputs matched against crew-level outputs, and gives each technician on a multi-person job a number that reflects what actually happened rather than an artifact of how the report happened to be structured.

Why This Keeps Happening

None of these four bugs were dramatic in isolation. A filter matching too narrowly. A name that didn't line up between two systems. A filter inherited from an unrelated report. A metric comparing crew hours to individual hours. Individually, each one sounds like a rounding error an engineer could fix in an afternoon, which is exactly why they're easy to miss. Together, they meant that almost every number the incentive plan was about to pay real money against was wrong, some undercounting real work, one badly overcounting, none of them safe to hand to a technician or CSR as-is.

This is close to universal, not a mark against this particular contractor or their systems. Field service platforms like ServiceTitan, ServiceFusion, and Workyard were built to run dispatch and invoicing. They're good at that. They were not built to do the specific arithmetic an incentive plan needs, which often means summing across jobs a particular way, matching a name across two disconnected systems, or filtering a job type by intent rather than by an exact label someone typed in six months ago. Those mismatches don't announce themselves. They sit quietly in a dashboard until someone checks a number against something they already know is true.

That's the entire discipline: before turning on any incentive plan, for any HVAC business, sanity-check every metric the plan pays against something you already independently know. If your top-line revenue was $1.1 million last month, an install revenue widget reading close to zero is not a rounding issue, it's a broken pipe. If a percentage-based metric shows over 100, someone needs to open the formula before anyone gets paid off it. This is precisely the kind of scrutiny that matters most for HVAC businesses building incentive pay for technicians and CSRs, where the underlying data is scattered across dispatch software, standalone spreadsheets, and membership systems that were never designed to talk to each other cleanly, similar to how one HVAC company caught a KPI number that was off by 40 before payday.

All four bugs in this case were caught and corrected in the weeks before launch, not after a single paycheck went out on bad numbers. That's the outcome worth aiming for. A pre-launch audit costs a working session and a checklist. A broken number discovered by an underpaid technician looking at his first real incentive check costs you the credibility of the entire program, and you may not get a second chance to earn it back.