Why This Roofing Company Piloted Incentive Pay With Just One Technician

Most companies that stall out on incentive pay stall on the design: what rate, what threshold, what counts as a win. This roofing and siding contractor had already cleared that part. The plan itself, an award pool tied to job efficiency, hours budgeted against hours actually spent, was built and ready to go. What stopped the rollout wasn't the plan. It was a quiet, growing suspicion that the numbers feeding the plan weren't trustworthy enough yet to put real pay behind them.

That suspicion turned out to be right, and finding out why took pulling apart four separate, unrelated data problems that had all been sitting underneath the same reporting layer, each one distorting the award pool in a different direction.

Quick facts

• Roofing and siding contractor with an operations and estimating team preparing a company-wide incentive rollout
• Warranty jobs, flagged but mislabeled by job type, were showing up in the technician awards dataset
• Gutter jobs quoted with flat per-foot pricing had no sold hours entered, making that entire category invisible to the plan
• One job's tracked hours differed by more than 10 hours between ServiceTitan and GPS truck-tracker data
• The company chose to pilot the cleaned-up plan with a single technician before a full rollout

The first problem was warranty work. Jobs flagged with a warranty checkbox, meaning no new revenue, work performed to make good on a prior job, were still showing up in the technician awards dataset because the job type field on those records had been left as ordinary roof repair. The checkbox said one thing. The field the report was actually reading said another. A warranty job with a real subtotal of zero dollars was sitting in the same list as fully paid work, which meant it could distort a technician's efficiency numbers without contributing a cent of real revenue to justify it.

The second problem was gutters. A meaningful share of the company's gutter work was quoted using flat, per-linear-foot pricing rather than an hours-based estimate, which meant no sold hours figure ever got entered into the system for those jobs. An efficiency-based incentive plan measures budgeted hours against actual hours worked. A job with zero sold hours on record isn't a job the plan can measure at all. It's a blind spot, and gutters weren't a small slice of the business, which meant a real chunk of completed, billable work was structurally invisible to the incentive calculation from the moment the estimate was written.

Two Different Answers For How Many Hours Did This Take

The third problem was harder to see coming, because it wasn't a missing number. It was two competing numbers that disagreed with each other. The company tracks technician hours two ways: through ServiceTitan's own service-time logging, and separately, through GPS data pulled from company trucks. On a normal job, those two sources should land close together. On at least one example the team reviewed, they didn't. ServiceTitan's initial pull on the job showed 18.37 hours of tracked time. The company's own master pay file, cross-checked against GPS truck data, showed a total closer to 28.9 hours, later corrected to 26 once someone dug into the discrepancy.

That's not a rounding error. It's a gap of roughly ten hours on a single job, and if an incentive plan is quietly built on the lower, understated number, it's underpaying a technician for real hours they actually worked, in a way that would have been effectively invisible unless someone happened to cross-check the two sources by hand. The company's answer was to formally designate its own master pay file, the version reconciled against GPS data, as the authoritative source of actual hours, rather than trusting whichever number ServiceTitan's report happened to surface first.

The fourth problem tied the other three together, and it's the kind of bug that erodes trust fastest because it undoes work that's already been done. Whenever the underlying jobs-and-timesheets report resynced, it risked silently overwriting sold-hour corrections that had already been manually reviewed and approved. In other words, a data problem the team fixed today could quietly reappear tomorrow, with no warning, because the next automatic refresh didn't know the correction had been intentional. Catching four bugs is only useful if the fifth thing you build doesn't let three of them sneak back in on their own.

The fix for that last piece was to separate what a report is allowed to do automatically from what requires a human decision: the report logic was rewritten to permanently exclude anything flagged as warranty work regardless of its job type label, and to treat manually approved sold-hour entries as protected values that a resync could add to but not silently overwrite. That distinction, between numbers a system can safely recalculate and numbers a person already checked and signed off on, is easy to overlook when you're building a reporting pipeline fast, and expensive to get wrong once real pay depends on it.

Why They Piloted With One Technician Instead Of Launching On Schedule

Here's the part of this story that's more useful than any individual bug fix: once the warranty filter, the gutter workaround, and the hours-of-record decision were all in place, the company still didn't flip the incentive plan on for the whole crew at once. They picked one technician, a specific person whose data the team already trusted, and piloted the corrected plan with him first.

That's a deliberate, slightly uncomfortable choice. A rollout date had presumably been floated already, and every week spent piloting with one person instead of the whole team is a week the rest of the crew isn't earning under the new structure yet. It's tempting to view that as lost time. It's more accurate to view it as insurance. An incentive plan that goes live company-wide on bad data doesn't just produce a few wrong paychecks. It produces wrong paychecks the whole team compares notes on, at the exact moment you're trying to convince them the new system is fair and worth trusting. A single-technician pilot contains that risk to one relationship instead of the whole crew, and gives the team a real, current example to point to instead of a promise.

The number that made the pilot worth greenlighting was small but real: with warranty jobs filtered out and the hours question settled, one completed job came in at 3.4 hours against a 4.0-hour budget, a clean 85 percent efficiency figure that could now flow into that technician's award with confidence, instead of sitting next to a warranty job's zero-dollar subtotal or an hours count nobody fully trusted. That's not a dramatic revenue story. It's a data-integrity story, and for a company about to attach real pay to a metric for the first time, that's exactly the kind of story that matters most. A job-efficiency incentive plan only works if a technician can trust that a good day of work reliably shows up as a good number, and a good number reliably shows up in their pay.

What To Check Before You Launch An Incentive Plan Company-Wide

• Look for any job category in your business, warranty work, flat-rate pricing, anything quoted outside your normal estimate process, that might not be feeding your performance metrics correctly.
• If you track hours two different ways, GPS and job software, timesheets and dispatch software, whatever the case, pull one real job and check whether the two numbers actually agree.
• Before rolling a new plan out to the whole team, consider piloting it with one trusted person first. A mistake caught in a pilot costs you a conversation. The same mistake caught after a company-wide launch costs you the team's trust in the plan itself.

None of the four problems this company found were exotic. Mislabeled job types, unpriced hours on flat-rate work, two hour sources that don't agree, and a sync process that can undo a manual fix without telling anyone, these are the kind of quiet data issues that exist in some form at almost every trades business running incentive pay on top of field service software. What made the difference here wasn't avoiding the problems. It was refusing to launch real pay on top of them until they were actually fixed, and testing the fix on one person before betting the whole team's trust on it. Read how another multi-trade contractor almost lost credit for a $51,000 rooftop job to a similar kind of tracking gap, or explore ShareWillow's approach to job-efficiency and award tracking to see how a plan like this gets built to survive contact with real, messy field data.