64 Hours On The Screen. 25 Were Real.

Picture the moment a technician opens his phone and sees his overtime for the week. Now picture that number being roughly double what he actually worked, not because anyone lied to him, but because a truck sitting in a drive-through line got logged the same way as a truck parked at a job site with a tech inside doing the work. That's not a hypothetical. It's close to exactly what was happening at a residential energy and HVAC services company running its technician pay through ServiceTitan.

The company had genuinely good intentions behind the setup. Hours worked, including overtime, fed directly into how technicians were paid, which is a reasonable and common way to run a field service payroll. The problem wasn't the idea. It was what ServiceTitan's GPS integration was quietly counting as "hours worked" underneath that idea. Idle time, meaning any stretch where a truck's engine is running but it isn't moving, was getting swept into paid time right alongside actual job labor. A tech waiting in a coffee line before the first call of the day. A truck sitting at a red light. A stop that had nothing to do with a customer's job. All of it counted the same as wrenching on a unit.

One Technician, 64 Hours On Paper

The clearest example surfaced during a support call between the company's operations lead, Nancy, and ShareWillow. One technician, working what should have been a normal week, showed roughly 64 hours logged in the system. Even accounting for a heavy week, that's not a number that survives contact with reality for a field tech running a standard schedule. Buried inside that total were long stretches of idle time being counted as if they were productive, paid hours, including entries that stretched past 24 hours in aggregate. Once you're crediting someone with a full extra day of "work" that was actually a truck sitting still with the engine running, the whole number stops meaning anything.

This wasn't just an accounting curiosity. It was actively becoming a payroll dispute. Overtime numbers feed straight into a technician's paycheck, and a tech who opens the app expecting to see his real week reflected back at him, and instead sees a number inflated by idle time he had no reason to think about, is going to ask questions the company didn't have a clean answer for yet. Nancy put it plainly on the call: the team needed the number fixed before it became a conversation with an upset technician, not after.

An overtime number a technician doesn't recognize isn't a minor glitch. It's the fastest way to make an entire pay system feel untrustworthy, even when almost everything else about it is working fine.

There was a second layer to the problem sitting just underneath the first. The company's GPS provider inside ServiceTitan, a tool called Fleetpro, was giving noticeably worse visibility than the system it had replaced. Where the previous GPS vendor tracked location second by second, Fleetpro's picture was coarser, which made it harder to tell the difference between a truck idling at a job site for a legitimate reason and a truck idling somewhere it had no business being. Nancy also raised a fair operational concern buried inside the fix: idle time isn't only a payroll nuisance, it's also a signal. Excessive idling can point to real issues, wasted fuel, a tech taking routes he shouldn't be taking, time that isn't being used well. Simply hiding idle time from view to fix the overtime number risked throwing away a legitimate management signal along with the bad data.

We've written before about how a single bad data point can distort pay math well past the one number it directly touches, like the property management company whose payroll sync bug briefly credited one technician 1.7 hours as 137.49, an eighty-fold error. This wasn't as extreme a multiple, but the mechanism was the same: a system faithfully doing exactly what it was told to do, counting everything ServiceTitan labeled as time, without anyone having gone back to ask whether every label deserved to be trusted the same way.

A Filter, Applied Live, Not A Redesign

The fix didn't require rebuilding the pay plan or renegotiating what counts as a technician's job. ShareWillow's Danielle applied an idle-time filter directly during the call, excluding idle entries from the hours calculation feeding into the technician's overtime number. The effect was immediate and visible on the same screen everyone was already looking at: the technician's overtime dropped from the roughly 64-hour figure down to about 25 hours once the idle entries stopped being counted as work. That's not a rounding correction. That's the difference between a number that would have started a fight and a number close enough to reality that it could actually be trusted.

Danielle didn't stop at flipping the filter and calling the call finished. Because Nancy raised the legitimate concern about losing visibility into idling for operational reasons, the fix was scoped specifically to how idle time factors into pay, not to whether the company could still see idling behavior at all. Those are two different problems wearing the same word. One is "should a tech get paid for this." The other is "should the ops team know this is happening so they can coach it." A filter on the pay calculation doesn't have to mean losing the second thing to fix the first.

As a bridge while the underlying ServiceTitan settings got sorted out, Danielle set up a manual verification tracker, a shared Google Sheet where Nancy could log confirmed hours for technicians whose numbers still needed a second look, starting with the technician at the center of the 64-hour figure and one other tech flagged for the same reason. It's not a permanent solution, and nobody treated it like one. It's the kind of stopgap that buys a team breathing room to fix the real, structural issue underneath: ServiceTitan's own payroll settings needed to correctly reflect the company's actual overtime policy, time and a half after 40 hours in a week, and nobody on the team currently had clear access to confirm those settings were configured that way in the first place.

That access gap is worth naming directly, because it's more common than owners tend to assume. A platform can be technically correct and still produce numbers a team can't fully trust, simply because the people closest to the pay decisions don't have visibility into the settings driving those decisions. Fixing the idle-time filter solved the symptom the same day. Getting eyes on the actual overtime configuration inside ServiceTitan was queued up as the next step, with Danielle syncing separately with the company's broader ops contact to close that gap for good rather than leaving it as a recurring manual patch.

A related, quieter issue came up in the same conversation: subcontractor and crane costs, the kind of expense that shows up on bigger energy and HVAC installs, weren't being consistently excluded from the "sold by" revenue figure used to calculate commission. If a job's revenue includes a $4,000 crane rental or a subcontracted portion of the install, and that cost isn't stripped out before commission gets calculated, a technician can end up earning commission on money that never actually reflected the value of his own labor. It's the same underlying discipline as the idle-time fix, just applied to a different number: know exactly what's feeding into a pay calculation, and be deliberate about what belongs there and what doesn't. We've seen this exact category of miscount show up before in a multi-trade contractor's generator commission fix, where cost categories that looked properly excluded on paper were quietly leaking into a commissionable number.

Why Same-Day Matters More Than It Sounds Like

It's tempting to read a story like this and file it under routine software maintenance. It isn't. The gap between a technician seeing an accurate overtime number and an inflated one, discovered and corrected before that pay period closed rather than after a paycheck already reflected it, is the difference between a minor internal fix and a genuine trust problem with the people doing the actual work. Field techs talk to each other. One tech seeing a wildly wrong number on his phone, even briefly, tends to travel through a crew a lot faster than the correction does.

What made this fix work wasn't a clever piece of engineering, it was a straightforward habit: when a number looks wrong, go find out exactly what's feeding it before assuming the person is wrong or the system is simply broken beyond fixing. In this case, the system wasn't broken. It was doing precisely what it had been told to do, treating every GPS-logged minute as equally real, without distinguishing a truck idling at a coffee stop from a truck idling because a tech was mid-repair on a rooftop unit. That's not a flaw in the platform. It's a configuration decision nobody had gone back to question, sitting quietly underneath a pay plan everyone assumed was working correctly.

The system wasn't broken. It was doing exactly what it was told, which is precisely the problem when nobody has gone back to check what it was told to do.

If your technicians are paid off hours or overtime pulled automatically from a fleet-tracking or GPS integration, this is worth checking directly rather than assuming it's fine because nobody has complained yet. Pull one technician's hours for a real week, not a slow one, and look at what's actually feeding the total. Idle time, drive time, and job time often live in the same field unless someone has explicitly told the system to treat them differently. If idle time is quietly padding the number, it's padding every technician's number, not just the one loud enough to flag it.

The company's next steps after this call were exactly the right ones: get the underlying ServiceTitan overtime settings corrected so the fix doesn't have to be reapplied by hand every pay period, get subcontractor and crane costs mapped cleanly so commission reflects a technician's own labor and nothing else, and keep a manual verification tracker running in the meantime as a safety net while those structural fixes land. None of that is glamorous. All of it is the actual work of keeping a performance pay plan honest, which has less to do with picking the right formula once and much more to do with continuing to ask, every so often, whether the number on the screen still matches the week that actually happened.