The Pay Metric No One Could Actually Check

The Pay Metric No One Could Actually Check

A 7-person HVAC company built part of one employee's monthly pay around a number called "estimate success rate." The idea was straightforward: track how often she provided an estimate on the jobs she worked, set a 95% target, and tie a piece of her compensation to hitting it. On paper it looked like a clean, fair way to reward someone for doing the job right and following through on the moment that turns a service call into a sold estimate. Small HVAC shops build pay plans like this all the time, because it feels like exactly the kind of thing that should be measurable. Someone either provided the estimate or they didn't. It seems like a simple yes or no, multiplied out across a month, into a clean percentage.

In practice, the owner had no real way to see the number behind it. The field service software the company used tracked jobs, techs, and statuses, but how the software actually got used day to day didn't line up cleanly with what the pay plan needed. Estimates weren't always assigned in the system to the person who actually gave them. The status meant to mark an estimate as "provided" often just never got clicked. So every month, a number showed up that was supposed to represent this employee's real performance, and every month the owner had to more or less take it on faith. He could see the final percentage. He could not see the jobs behind it, which ones counted, which ones should have counted and didn't, or why the number moved the way it did from one month to the next.

That's a rough spot to be in as a business owner. You've told someone part of their paycheck depends on a specific, measurable outcome. That instinct is right, tying pay to real performance is exactly how incentive pay is supposed to work, and it's a big part of why trades businesses turn to structured incentive plans in the first place. But if you can't independently verify the number, you're not actually running a performance-based pay system. You're running a trust-based one with a percentage sign attached to it. If the number comes in low, you don't know whether performance was actually low or whether nobody clicked a button in the field service software. If the number comes in high, you don't know whether that's earned either. Either way, you're making a pay decision on a foundation you can't inspect.

The employee was in an equally rough spot. She was being measured against a 95% target every month with no way to see her own data, question a low score, or understand what specifically to do differently. If the number came in under target, there was nothing to point to. No list of which jobs counted against her, no way to say "that one shouldn't count, I never got assigned to it." A pay-linked metric that neither side can inspect isn't really a metric. It's a black box that happens to move money around, and black boxes are corrosive to trust even when nobody involved is acting in bad faith.

This is a more common situation than most trades business owners like to admit. Field service software is built to run jobs, dispatch techs, and invoice customers. It was never designed to double as a compensation audit trail. The moment you attach real pay to a status field or a report the software spits out, you've inherited a data integrity problem you probably didn't know you had, and it stays invisible right up until someone asks the obvious question: how do we actually know this number is right? For this owner, that question didn't have a good answer, and that gap is exactly what needed to get fixed before the pay plan could be trusted by either side of it.

Why the Number Was Invisible, and What Fixed It

Two habits in the field were quietly breaking the metric. First, when a job came in, the estimate itself often didn't get formally assigned in the field service software to the tech who actually walked the customer through it. Jobs get reassigned, techs cover for each other, dispatchers move things around, and the paper trail inside the software doesn't always keep up with who really did the work. On a busy day, the job might sit assigned to whoever opened the ticket that morning, not whoever actually stood in the customer's kitchen and walked through pricing. Second, and more directly, the "estimate provided" status on a job frequently just wasn't marked at all. The tech gave the estimate in the field, then never went back into the system to flip the status that told the software the estimate had actually happened. From the tech's point of view, the job was done. From the software's point of view, it never occurred.

Neither habit is malicious. It's the kind of thing that happens in a busy 7-person shop where everyone is running from job to job and clicking a status field is the last thing on anyone's mind after a long install or a hot summer service call. But when that status field is quietly wired to someone's paycheck, "the last thing on anyone's mind" becomes a real problem, and it's one that stays hidden precisely because nobody is looking at it closely enough to notice. Most field service platforms will happily let a status sit unmarked forever without ever flagging it back to an owner. Nothing breaks. Nothing errors out. The report just quietly comes back wrong, month after month, and there's no built-in signal telling anyone that's what happened. The software isn't lying, it's simply reporting the only thing it actually has: whatever got clicked, not whatever actually happened in the field.

ShareWillow's Metrics Hub pulled the raw data straight out of the company's field service software and rebuilt it into something the owner could actually look at: a per-employee, per-month breakdown of every single estimate that counted toward the qualifier, filterable by employee and by month, and exportable as a CSV. Instead of one opaque percentage landing in his inbox once a month, the owner could open a report, pick the employee, pick the month, and see the actual list of jobs behind the number. Which ones counted. Which ones were marked provided. Which ones weren't, and why. For the first time, the score driving part of someone's pay had a paper trail behind it instead of just a headline number he had to trust. If a number looked off, he no longer had to guess. He could open the export and see exactly which jobs pulled it down, and whether the cause was performance or a status field nobody touched.

ShareWillow also flagged the root cause and offered a fix that goes further than just reporting on the mess: rebuilding the underlying attribution logic so an estimate gets credited to whoever actually created it, not just whoever the job happened to be assigned to in the system. That's the difference between measuring the software's bookkeeping habits and measuring the actual work someone did in front of a customer. Once that logic is in place, the monthly number stops being a proxy for "did someone remember to click a button" and starts being a much closer read on real performance, which is the whole point of tying pay to a metric in the first place. It's a small technical fix with an outsized effect on fairness, since it moves the entire measurement closer to the thing everyone actually cares about: who did the work, not who happened to have the job sitting under their name in the software that day.

What the Number Actually Said, and What Happens Next

With real visibility in place, the owner pulled August's numbers and got an answer he'd never actually had before: a 75% estimate success rate against the 95% target tied to this employee's pay. Three out of four estimates were properly marked "provided." That's not a rounding error. That's a quarter of the qualifying work going unrecorded, on a metric that directly affects a paycheck, and it's the kind of gap that simply cannot be seen without a report built specifically to surface it. Before this month, that gap had been sitting there invisible for however many months the qualifier had been part of her pay, quietly shaping a number nobody could actually stand behind.

"August's rate came in at 75% against a 95% goal. Three out of four estimates," the owner said. "It's not lost revenue yet. It's a habit gap: techs aren't assigning themselves to the estimate or clicking 'provided.'"

That distinction matters more than it might sound. A 75% score could mean the employee is genuinely underperforming against the target. It could also mean the work is happening and the system just isn't capturing it. Those are two very different problems that call for two very different conversations, and before the Metrics Hub, the owner had no way to tell those two stories apart. He had no way to have an honest, specific conversation about which one was actually true, because he had nothing more granular than the final percentage to point to. Now he does. He's reviewing the shortfall with the employee directly, face to face, with a pay increase explicitly on the table contingent on the number improving. A September re-check is already scheduled to see whether it moves, now that both of them know exactly what's being measured, how it's being measured, and why.

That's the real outcome here, and it's worth being honest about what it is and isn't. This isn't a story about a dramatic revenue jump or a big efficiency win overnight. It's a smaller, more foundational win: a completely invisible, unverifiable, pay-linked number turned into something documented and auditable, with a monthly habit of checking it built on top. The owner committed to a simple written process, essentially a monthly checklist, for pulling this report every month going forward, specifically so this never goes dark again the way it had been for months already. For a small business trying to pay people fairly, that habit is worth more than it looks like on paper. A number you can verify every month is worth more than a bigger number you have to take on faith.

If any part of your pay plan depends on a number pulled out of your field service software, ask yourself whether you could actually produce the receipts behind it right now, for any employee, for any month. If the honest answer is no, you don't have a performance-based pay system, you have a percentage you're hoping is right. That's exactly the gap a real incentive pay platform is built to close: turning the raw data your field techs generate every day into a number both sides can actually see and trust, instead of a black box that happens to move money around. It's especially worth checking if you run an HVAC company, where techs are in and out of the field all day and status fields are the easiest thing in the world to skip between calls. The fix usually isn't more pressure on the team to click more buttons. It's building a system that catches the gap before it ever reaches a paycheck, so pay decisions get made on real data instead of a number nobody can actually stand behind. That's a small operational change with a big effect on how fair the whole pay plan actually feels to the people living under it.