The Duplicate Truck Record That Was Costing a Water Tech His Bonus

Field service metrics have a specific way of failing: quietly, and in a direction that looks almost plausible. A number that's off by ten percent gets shrugged off as normal variance. A number that's off by three hundred percent gets noticed, but not always for the right reason, and not always fast.

That's roughly what happened at a small, lean residential water treatment company running a handful of technicians on daily service routes. During a routine monthly operations review with their ShareWillow implementation rep, the owner brought up something that had been bothering them: revenue per mile, a metric they used to sanity-check route efficiency, looked wildly high for July. "It's, like, triple the number compared to other places, but it doesn't really seem right," they said. They were right not to trust it, and the reason turned out to be almost invisible unless you knew exactly where to look.

Revenue per mile is one of those metrics that only works if both halves of the fraction are trustworthy. Most owners spend their energy double-checking the revenue side, since that number is directly tied to invoicing and gets scrutinized constantly. The mileage side, pulled automatically from a fleet tracking tool, tends to get trusted by default simply because nobody thinks to question it. That default trust is exactly what let this particular gap sit undetected for a full billing period.

A truck with two names

The company's fleet tracking tool had two separate records for the exact same vehicle. At some point, the truck had been renamed, from a custom nickname to a plain numeric ID, and instead of updating the existing record, the change created a second, duplicate one. Both records technically existed. Only one of them was actually populated with mileage data going forward. The other sat there, empty, silently uncounted.

The problem was that ShareWillow's revenue-per-mile calculation happened to be pulling from the empty record. Total revenue for the technicians assigned to that truck was correct; nothing was wrong with the numerator. But the mileage denominator was missing an entire vehicle's worth of driving, which meant every mile that truck actually logged was invisible to the math. Divide real revenue by a fraction of the real miles, and the number that comes out looks great on paper and means almost nothing.

Fifty-nine hours in a three-day week

A second issue surfaced the same call, unrelated to mileage but just as strange on its face: one technician's payroll report showed 59 hours worked in a week where he'd only actually been in the field for three days. That's not a rounding error. That's a number that should stop anyone in their tracks.

The root cause traced back to a habit on the office side, not a bug in the platform. When a technician had a day off, the scheduling notes read something like "he's booked off this day." The field service software interpreted that note as a scheduled, all-day event rather than a note, which generated a clock entry of nearly 24 hours for each day off. Two days off in that pay period meant two phantom entries of just under 24 hours each, both of which the payroll report dutifully summed into his total. The fix here wasn't a platform change so much as a scheduling convention change, catching a pattern before it repeated and quietly inflated someone's hours every time an office staffer typed a similar note.

A compliance metric that flagged almost everyone

The third issue was the strangest of the three. The company tracks whether staff follow up on unpaid invoices, using a flag for "manager contacted for unpaid invoice" as a rough compliance signal tied to technician accountability. In one week, that flag fired 19 times, nearly every single job the team had closed that period.

Two things were compounding here. First, a filter left over from a prior working session on the ShareWillow side had altered how the report pulled that data, inflating the flag count well beyond what was actually happening. Second, even once that was reverted, the underlying business process had a timing problem: the bookkeeper didn't always mark e-transfer payments as "paid" the same day they came in, which meant a job that was, in reality, already settled could still get flagged as an unpaid invoice simply because the paperwork hadn't caught up yet.

Fixing three unrelated problems in one sitting

None of these three issues had anything to do with each other technically, but all three got resolved in the same working session, which is worth noting on its own. The mileage fix was the most straightforward: the rep found the duplicate vehicle flag in the fleet tracking tool, switched the revenue-per-mile report to pull from the correct, populated vehicle record, and resynced the month's data. "I'll just show you on the sheet, and now it's showing at an average of $14 per mile," the rep said, pulling the corrected number up live. "That's much more aligned with where we would expect it to be."

The compliance flag took two layers of fixing. The leftover filter was reverted immediately, which alone brought the count down dramatically. But rather than stop there, the team built in a structural fix for the underlying timing problem: an invoice now only counts against a technician if it's still marked unpaid and the manager-contacted field is blank a full three days after the invoice date, giving the bookkeeper's payment processing time to catch up before anyone gets flagged for something that was already resolved. A related metric, tracking how quickly staff responded to customer comments, got tightened the same way: instead of counting any comment ever added as compliant (even one added a week late), the logic now only counts a response made within the next working day, and that result locks in permanently so old records can't be retroactively inflated by a late entry.

The phantom-hours issue was handed back to the customer to solve on their end, since it was a scheduling convention rather than a platform bug, though the rep offered an optional logic-based cap as a backstop if the habit didn't change.

What the numbers looked like once they were real

The clearest before-and-after was the mileage figure. Once the missing vehicle's driving was restored to the calculation, revenue per mile across the team's roughly $112,600 in July revenue settled at an average of $14 per mile, down from a number the owner had already flagged as roughly triple that. That's not a cosmetic correction. A route efficiency metric that's off by a factor of three isn't useful for anything, whether that's staffing decisions, pricing, or figuring out which routes are actually profitable.

The compliance flag told an even starker story. Nineteen flags in a single week, essentially the entire week's job volume, dropped to four flags across the entire following month once the leftover filter was reverted and the three-day grace period took effect. That's not a small tuning adjustment. That's the difference between a metric nobody trusts because it flags everything and a metric that actually points at real problems worth a manager's attention.

You're the best. You guys' customer service is so awesome. You guys blow me away. Really appreciate it.

That's the owner, closing out the call. It's a small line, but it says something real: fixing three unrelated, quietly wrong numbers in one sitting is the kind of thing that builds trust in a platform faster than any sales pitch could.

Why a metric being wrong is worse than a metric being missing

There's a version of this story where the lesson is just "check your fleet tracking software for duplicate records," and that's true as far as it goes. But the bigger lesson is about what a wrong metric actually does versus what a missing one does.

A missing number gets noticed. Nobody trusts a blank field. But a wrong number that looks plausible, a revenue-per-mile figure that's high but not absurdly high, a compliance flag that fires often but not literally every time, gets trusted right up until someone happens to compare it against their own gut instinct. That's exactly what happened here: the owner didn't catch the mileage issue because a report broke. They caught it because a number felt off, and they were paying close enough attention to say so out loud instead of letting it slide.

That instinct is worth protecting in any shop running metrics-based pay, whatever the trade. A number that's driving someone's compensation or a manager's attention needs to survive being double-checked, not just look reasonable at a glance.

There's a broader habit worth building here too. Metrics that feed pay or performance reviews deserve a periodic audit the same way a set of financial books do, not because anyone expects fraud, but because small, unrelated errors accumulate quietly in systems nobody is actively watching. A duplicate vehicle record, a scheduling note, a leftover filter: none of these were connected to each other, and none of them were caused by carelessness. They were just the ordinary entropy of running a real business with real software, and they only got caught because someone made a habit of asking whether the numbers still made sense.

A quick check for any route-based service business

You don't need a water treatment route specifically to have a version of these three problems sitting in your own data. A few places worth a look this week:

• Duplicate asset records. If a vehicle, technician, or piece of equipment ever got renamed in your fleet or field service software, check whether that created a second, silently empty record instead of updating the original.
• Scheduling notes versus scheduled events. If your office team writes free-text notes for days off or special circumstances, confirm your software isn't quietly converting those notes into logged hours somewhere downstream.
• Compliance and accountability flags. Any metric meant to catch exceptions (unpaid invoices, missed callbacks, slow responses) should be spot-checked periodically for whether it's actually rare enough to be useful. A flag that fires on nearly everything isn't a signal anymore.
• Payment timing versus flagging logic. If a metric depends on payment status, make sure it accounts for the real-world lag between a payment arriving and someone marking it received.

None of this requires new software, just a habit of trusting a gut check when a number looks off, and a willingness to trace it back to the source instead of assuming the report is right because it usually is.

You're not the only route catching this

Data quietly going bad in route-based and metrics-driven pay plans is more common than most owners assume, and it shows up in different shapes depending on the business. Another water route dealt with a related issue where false payroll alerts were flooding a manager's queue until the underlying trigger got tightened, and a different multi-technician shop found unbilled revenue quietly skipping their commission calculation entirely.

The pattern across all of them is the same: the fix wasn't more software, it was someone willing to trace a number back to its source instead of trusting the summary. If your team runs on any kind of metrics-based incentive or commission plan, whatever corner of field service you're in, it's worth an afternoon periodically confirming the numbers feeding it are actually measuring what you think they're measuring.