Consent Preferences
backicon

The AI Pilot Penalty in FM

Published on :

September 21, 2026

by

Anisha Bhattacharjee

view

Views...


98% first-time fix. 45% fewer repeat truck rolls. Quality inspections increasing from 2–3 to 5–6 per week.

These are outcomes from an Xempla deployment now operating across roughly 2,000 distributed solar sites, spanning multiple OEM platforms and the teams responsible for monitoring, maintenance, installation and quality.

Those numbers are the result. Getting there depends on more than running the AI. It depends on how that AI operates within the data, workflows and decisions already in place. In the industry, this gap has a name: the AI pilot penalty, the gap between running AI and actually getting value from it. Closing that gap doesn't necessarily mean overhauling the operation. In this deployment, it came down to connecting AI to specific workflows that were already there.


Why production is different

A pilot runs under conditions a team can control: a defined set of assets, curated data, a known set of scenarios. Production is different. Thousands of assets behave differently from each other, multiple systems generate overlapping signals, some alerts matter and others clear on their own, and a work order being raised doesn't tell you whether the underlying problem actually got fixed. Once the capability has been proven, the harder question is whether the operation can absorb it and turn its output into outcomes that hold up.


What changed, point by point

In this deployment, the value didn't come from a single AI capability. It came from connecting a few parts of the operation into a more continuous workflow.

1. From waiting for complaints to identifying problems earlier.

Before Xempla, maintenance was largely reactive: a customer experienced a problem and contacted the service team, or someone manually noticed an alarm during a periodic review. Xempla brought asset data from multiple OEM platforms into a central operational layer, allowing the operation to monitor behaviour continuously and identify performance deviations before they became customer-reported issues.

2. From raw alerts to qualified field action.

Across roughly 2,000 sites, not every alert represented a genuine problem. Some were temporary conditions or auto-clearing signals that didn't require intervention. Xempla Agents perform the initial triage of these alerts against severity, duration, asset behaviour and historical trend, turning raw alerts into qualified operational cases: automatic work order, human review, observation, or no action. A truck roll can now be triggered by a qualified operational issue, rather than simply because an alarm fired.

3. From "work completed" to "problem verified."

Previously, a work order closed once a technician reported the job done, with only a sample of completed jobs checked afterward. Xempla checks the asset's behaviour again once work is reported complete, and the case is closed only once the expected condition has been confirmed as restored. If it isn't, the case returns to the field for another look. That closed loop is a key part of what sits behind the improvement in first-time fix and repeat truck rolls.

4. From installation completion to validated handover.

An installation being marked complete doesn't guarantee it's ready for the service and warranty stage. Issues like a leak or an incorrect meter installation can surface much later. Xempla evaluates installation checkpoints before handover, so problems get caught and rectified at that stage instead.

5. From manual inspection admin to more inspection capacity.

Inspectors used to visit a site, then return and manually prepare the report. With capture built into the same app used on-site, most of that report-writing disappears. Reducing that report-writing workload helped increase inspection capacity from 2–3 to 5–6 visits per week.

The operational change is measurable. Its impact is not always captured in a percentage. An issue can be addressed before a customer has to report it. A technician isn't sent out simply because an alarm fired. A completed job doesn't have to be taken on faith. And an inspector can spend more of the week inspecting sites instead of writing reports about them. The point isn't just that the numbers improved. It's that less of the operation depends on people manually holding all of the pieces together.


AI doesn't have to replace the systems already in place

None of this required replacing the operational stack. The customer still runs its OEM platforms, maintenance systems and field teams. Xempla sits as an intelligence and decision layer across that environment, connecting information from multiple systems to the workflows that turn it into action. In this deployment, the gap closed not by adding another standalone AI capability, but by connecting AI to the workflows and decisions already running the operation.

Running AI is not the same as getting value from it. A pilot can show that a capability works. Production tests whether it can hold up within the complexity of the real operation. The pilot penalty closes when that capability becomes part of the workflow and the operation starts producing different outcomes.

The proof of AI in operations isn't the demo. It's what keeps working after the demo is over.


At a glance

  • ~2,000 sites
    Multiple OEM platforms → Centralised operational layer
  • First-time fix
    ~50% → 98%
  • Truck rolls per WO
    1.9–2.0 → 1.0–1.2
  • Quality inspections/week
    2–3 → 5–6
  • Generation loss recovered
    3.498 MW
  • Carbon emissions avoided
    2.484 tonnes CO₂e

If you're thinking about what it takes to move AI beyond the pilot

Start a conversation


FAQs

What is the "AI pilot penalty" in facilities management?

The AI pilot penalty is the gap between running AI and actually getting value from it. In facilities management, that gap depends on how the AI is connected to existing data, workflows and decisions, not simply on whether the AI has been deployed.

Why do AI pilots in facilities management work in testing but struggle to deliver the same value in production?

A pilot runs under conditions a team can control: a defined set of assets, curated data and a known set of scenarios. Production is different. Thousands of assets behave differently from each other, multiple systems generate overlapping signals, and a work order being raised doesn't confirm the underlying problem was actually fixed.

How is a "verified" problem different from a "closed" work order in AI-driven facilities management?

A closed work order only confirms a technician reported the job done. A verified outcome means the asset's behaviour is checked again after that report, and the case is only closed once the expected condition is confirmed as restored. If it isn't, the case returns to the field.

Does AI in facilities management replace our existing CMMS, BMS or OEM platforms?

No. In this model, the customer continues running its OEM platforms, maintenance systems and field teams as before. The AI operates as an intelligence and decision layer across that environment, connecting information from multiple systems into the workflows that turn it into action.

What results did AI deliver after moving from pilot to production in this deployment?

Across roughly 2,000 distributed solar sites, results included a 98% first-time fix rate (up from a 50% baseline), 45% fewer repeat truck rolls, and quality inspections increasing from 2–3 to 5–6 per week.