Consent Preferences
backicon

Why Does the Same Asset Need Another Truck Roll After the Work Order Is Closed?

Published on :

September 25, 2026

by

Anisha Bhattacharjee

view

Views...

‍
Repeat truck rolls rarely have a single cause. Sometimes a repair genuinely needs a second visit. Sometimes the first intervention didn't fully resolve the issue, and nobody caught it before the ticket closed. Either way, the result looks the same on paper: another dispatch to an asset that's already had work done.
‍

Field-service benchmarks show that first-time resolution remains far from universal. Aquant's 2026 benchmark reports a 77% first-time fix rate across its benchmark, with top-performing teams reaching 88%. The benchmark is broader than facilities management, but it illustrates the underlying problem: sending someone to the asset doesn't necessarily mean the problem is resolved.
‍

We saw a version of this first-hand, on a solar operations portfolio spanning roughly 2,000 sites in Australia. Xempla was already identifying performance deviations and giving the site team contextual recommendations. What the workflow didn't yet include was a verification step to confirm whether the recommended action had actually restored the asset. The maintenance workflow around those recommendations was otherwise business as usual: identify the problem, send the contractor, complete the work, close the work order.
‍

At one site within that portfolio, this gap showed up on a specific fault. Several inverters were showing MPPT-level generation issues, with roughly 65 kWp of capacity affected. The eventual investigation identified twelve faulty fuses and one faulty MC4 connector. Resolving the issue took three site visits. The workflow had no step to establish whether the original intervention had actually closed the performance gap before the work was considered complete.
‍

That was the gap the verification workflow was designed to address. Once it was added to this deployment, truck rolls per work order across the portfolio fell from roughly 1.9–2.0 to 1.0–1.2. We've covered the fuller deployment, and what else changed alongside verification, in The AI Pilot Penalty in FM.
‍

So what's actually driving these repeat visits, and what changes when they're verified?
‍


Where repeat visits actually start

An intervention can be completed without confirming the original problem is gone. A work order can be completed even when the original performance deviation hasn't disappeared. If nobody checks the asset afterward, the next alert may become the first sign that the issue was never fully resolved.

How Xempla addresses it:

Xempla verifies the asset's condition against what was originally identified and requested before the case counts as resolved, so an unresolved deviation is caught immediately rather than at the next failure.

The next visit starts without the previous context. When a fault returns, the follow-up can be treated as a new event rather than a continuation, leaving the next technician to reconstruct what a previous visit already found.
‍

How Xempla addresses it:

Xempla keeps an unresolved issue connected to the existing investigation, so the follow-up visit begins with what's already known instead of starting over.

There's no clear evidence, at portfolio scale, of which interventions actually held. A work-order report shows how many jobs were completed and whether response targets were met. It doesn't show how many of those interventions actually restored the intended condition, so repeat visits can stay buried inside metrics that otherwise look healthy.
‍

How Xempla addresses it:

Outcomes are checked and recorded rather than assumed, giving teams a portfolio-level view of how many interventions actually held.
‍


Why this matters on both sides of the contract

For a service provider, SLA attainment and a resolved outcome are not the same measure. Being able to show that an intervention actually held is different evidence at contract review from showing that it was completed on time. It can also reduce the technician time spent repeatedly diagnosing the same unresolved fault, freeing capacity for genuinely new issues. 
‍

For an asset owner, the picture shifts from "the SLA was met" to whether the intervention actually restored the asset's condition.  A portfolio can look fully compliant on paper while the same assets keep quietly generating repeat visits underneath. Verification helps surface that gap earlier, rather than leaving it to show up later as cost or reliability.
‍

Some repeat visits are unavoidable: a second component may only become apparent once the first is opened up, or the required part may not have been on the van the first time. The one worth eliminating is different: a visit that repeats only because nobody checked whether the last one actually worked.
‍

A truck roll tells you someone went to the asset. Verification tells you whether that visit resolved the problem.
‍

Want to see where repeat truck rolls are coming from across your portfolio?

Start a conversation

‍


FAQs

Why do repeat truck rolls happen in facilities management?

Repeat truck rolls can happen when a work order is closed based on reported task completion without a subsequent check that the underlying issue was resolved. When it resurfaces, the follow-up can be logged as a new case rather than a continuation of the original. 
‍

Does closing a work order mean the problem is fixed?

Not necessarily. Work-order closure confirms the assigned work was reported complete. It doesn't confirm the underlying asset condition was restored.
‍

What is work order verification?

A check performed after work is reported complete, comparing the asset's actual condition against what was originally identified and requested. If the intended outcome wasn't achieved, the case continues rather than a new one being opened.
‍

Does Xempla's verification workflow replace a CMMS?

No. Xempla works as a layer above the CMMS and other systems already running the operation, using the data they generate to verify whether an intervention actually resolved the issue.