The $51,000 Rooftop Job That Almost Never Got Credited

Picture a multi-trade contractor running roofing, install, and service crews, technicians ranked in tiers by experience, and a dedicated HVAC install team working alongside them. The company had just rolled out a performance pay plan and was closing in on its first month of ever finalizing a live payout, real money about to move based on real numbers for the first time. That kind of first month is exactly when you want every number to be right, and exactly when small gaps are easiest to miss because nobody yet knows what "normal" is supposed to look like.

The first problem showed up as an absence, not an error. The company's office administrator was reviewing the numbers ahead of that first payout and noticed a service technician who had been active all month, running jobs, closing tickets, doing the same work as everyone else on the crew, had nothing populating for him at all. "His average ticket is zero, even though I can see it on yours," she said. "Something weird is happening." A technician cannot earn an incentive off a system that does not know he exists, and this one, at the data level, did not.

What had happened was simple and easy to miss: his profile in the field service software had never been fully mapped into the incentive system. The job data was there. The commissions were there. But without that connection, none of it flowed through, so every metric tied to him, average ticket size, revenue, callbacks, all read as zero, not because he had not earned anything, but because the pipe carrying his numbers had never been connected in the first place.

The second problem was subtler and, in dollar terms, considerably larger. A different technician, a level-9 tech who normally worked service calls but occasionally picked up install work, had closed out a rooftop job that month. Not a small one. The owner caught it while reviewing that technician's numbers: "I think that'll actually impact this month, because there was a $51,000 rooftop that he put out that he should get credit for." The problem was that service revenue and install revenue lived in two separate reports inside the company's field service software, and the incentive calculation was only pulling from one of them. A technician who crossed departments for a single job, service by trade, install by task, fell into a gap between two reports that were never designed to talk to each other.

Neither of these was a dramatic system failure. Nothing crashed. No number went negative. They were both quiet gaps, the kind that only show up when someone reviews every technician's numbers individually instead of scanning a total and moving on. And because this was the company's first live payout, there was no prior month to compare against, no baseline that would have made a zero or a missing $51,000 job jump out on its own. Someone had to go looking.

Two Different Kinds Of Invisible

What connects a technician who never got mapped into the system and a job that fell between two disconnected reports is the same root cause: data that existed somewhere, but never made it into the one place that decided who got paid what. Neither technician did anything wrong. The work happened. The revenue was real. It just was not visible to the system responsible for turning that work into a payout.

Reconnecting The Missing Technician

The fix for the first technician was mechanical once the team knew where to look: resync his profile and remap it into the incentive system so his job data, revenue, and callback history all flowed through the same way every other technician's did. Once that connection was rebuilt, his numbers stopped reading as zero and started reading as what they actually were. His average ticket settled at roughly $259 for the month, and a projected award of $220 appeared on his account, a number the office administrator confirmed simply "wasn't there before." Nothing about his actual performance had changed. What changed was whether the system could see it.

Building A Report That Actually Crosses Departments

The $51,000 rooftop job needed a structural fix rather than a one-time correction, because the underlying problem would keep happening to any technician who crossed between service and install work. The team built a combined service-and-install revenue report so a technician's incentive calculation pulls from both sources instead of just one, whichever department the work technically falls under. Once that report existed, the $51,000 job was applied retroactively to the technician's incentive for the month it was actually completed, rather than being lost to a report boundary that had nothing to do with when or how the work got done.

Alongside both fixes, the team added a photo-compliance qualifier to every install plan going forward: technicians now need at least 80 percent job-site photo documentation through the company's CompanyCam integration before a job counts toward their incentive payout. That was not a response to either bug specifically. It was the kind of guardrail that makes sense to add while you are already deep in the plan's mechanics for the first time, tying payout eligibility directly to documentation instead of leaving job quality as a separate, unenforced expectation.

The order mattered here too. Fixing the missing technician's mapping first meant his numbers were correct before anyone tried to reconcile the payout as a whole. Building the combined revenue report second meant the $51,000 job had a place to land instead of getting logged as a manual, one-off exception that someone would have to remember to repeat next time a technician crossed departments. A company that only fixed the more dramatic $51,000 gap and left the missing technician unresolved would have shipped a payout that still had one person's numbers reading zero, just a quieter kind of wrong than the one that got caught first.

Once both fixes were in place, the owner's read on the broader payout logic shifted too. Reviewing a separate technician whose numbers looked lower than expected, he realized the gap was not a bug at all, just a qualification threshold the technician had not yet hit. "That's good to know," he said, "if people start complaining their payout doesn't look like it's coming, it's likely because they're not qualified yet." Understanding which gaps are bugs and which are simply the plan working as designed is its own kind of clarity, and it only comes after you have gone through the exercise of finding and fixing the ones that are not supposed to be there.

By the time that first live payout went final, the missing technician's numbers were populating correctly, average ticket and all, and the $51,000 rooftop job was credited to the technician who had actually put it out, retroactively, for the month he earned it. Neither fix required a bigger incentive budget or a new pay structure. Both required someone looking at an individual technician's numbers, noticing they did not make sense, and refusing to let a first-month payout go out with either gap still open.

The real result was not just one corrected report and one remapped profile. It was a company entering its second month of live payouts with a combined revenue report that will keep catching cross-department work automatically, a photo-compliance qualifier that ties payout to documented job quality, and a much clearer sense of which gaps in a technician's numbers are bugs worth chasing and which are simply the plan doing what it was built to do.

What This Means For Other Roofing And Multi-Trade Shops

Any multi-trade contractor running technicians across service and install work, roofing crews included, carries some version of this exposure. Field service software is often organized by report type or department first and technician second, which means a person who crosses those lines, even occasionally, is exactly the kind of case that falls through a gap nobody built on purpose. The first payout cycle is when these gaps are most likely to hide, because there is no prior month's numbers to compare against and notice something is missing.

What To Check Before Your Own First Payout

A few checks are worth running before any incentive plan goes live, and they matter even more on the first cycle. Confirm every technician's profile is fully mapped and pulling real data, not just the ones who look obviously active, since a mapping gap reads as a quiet zero rather than an error message. Ask specifically whether your reporting separates service and install revenue, and if it does, ask what happens to a technician's incentive when a single job crosses both. And build your documentation and quality qualifiers into the plan from the start rather than bolting them on later, because it is easier to set a photo-compliance threshold before the first payout than to retrofit one after technicians have already gotten used to how payouts work.

None of this requires guessing at what might go wrong. It requires reviewing every technician's numbers individually before the first check goes out, the same way this company's office administrator and owner did, one zero and one $51,000 rooftop job at a time, until every number on the payout actually matched the work that had been done.

The First Payout Sets The Tone For Every One After It

There is a reason this company caught these two gaps instead of letting them slide into the next month unnoticed. It was the first live payout, which meant nobody yet had a habit of just glancing at the total and moving on. Every technician's number was still new enough to warrant a second look. That is worth remembering for any contractor about to launch a performance pay plan of their own: the diligence you bring to the first payout is the diligence your team will assume applies to every payout after it. Cut a corner in month one and it becomes the baseline. Catch a $51,000 gap in month one and that becomes the baseline instead.

It is also worth noting what did not happen here. Nobody widened the incentive pool or added a bonus to smooth over the mistake. The fix was structural: reconnect the data that was missing, build the report that should have existed from the start, and apply what was owed to the person who actually earned it. That is a meaningfully different outcome than throwing more money at a plan that is not yet measuring the right things. A performance pay plan only works if the technicians on it believe the numbers behind it are accurate, and accuracy has to be earned before trust follows, not the other way around.

For a multi-trade shop especially, that trust matters more than it might for a single-trade operation, because technicians who cross departments are watching closely to see whether the system actually accounts for the full range of what they do. A roofer who also handles the occasional install job, or a service tech who steps in on a bigger project, needs to see that kind of work reflected in their payout, not lost in the space between two reports that were never designed with them in mind.