Published on :
September 4, 2026
by
Anisha Bhattacharjee
Views...
A stitch in time saves nine. Everyone knows the idea: deal with a small problem early, and you avoid a much bigger one later. But facilities management rarely allows for it. Maintenance needs typically outpace available budget, labour, and time, so some work has to wait. The real challenge isn't whether something gets deferred. It's knowing which item can wait, why it can wait, and when it should stop waiting. This is the challenge of deferred maintenance.
Deferred maintenance is work that's been identified as necessary but postponed because available budget, labour, time, or maintenance windows are being allocated to higher-priority needs. The asset may still be operating. That means there is still a choice about when the work gets done, but the need for it doesn't disappear while that decision is being made.
That distinction, known work that's postponed versus work forced by a failure, is also what separates deferred maintenance from reactive maintenance. Reactive maintenance is work triggered by a failure, fault, or immediate operational issue, rather than planned in advance.
Some level of deferred maintenance is inevitable in a resource-constrained environment. The problem isn't having a backlog. The problem is losing track of what's in it, why it's there, and whether that reasoning still holds.
Deferred maintenance grows when demand exceeds resources, and when teams lack enough information to consistently judge what needs attention now versus what can safely wait. A few factors typically drive it:
Budget and labour are largely structural constraints, not something a maintenance team can solve on its own. But the quality of the prioritisation decision is more directly within its control. A well-reasoned deferral is also easier to defend when teams have to justify where limited budget and labour should go, though where the work sits under a service agreement, what's defensible and what the agreement actually permits aren't always the same thing. Even where the contract limits the decision, the evidence still has value: it's what lets the case be taken back to the client, rather than carrying the risk alone.
A public-sector example shows how fast this can compound. The U.S. Department of Defense's estimated deferred maintenance backlog grew from $137 billion in FY2020 to $285 billion in FY2025, according to a GAO facilities report. The figure isn't directly comparable to a commercial FM portfolio, but it illustrates how quickly deferred needs can accumulate when maintenance demand outpaces available resources.
Maintenance should be deferred only when there's enough evidence to understand the risk of waiting, the consequences of delay, and the conditions that would require revisiting the decision. Every deferral needs three things:
This is where deferred maintenance stops being a backlog problem and becomes a decision problem.
Deferred maintenance can increase repair costs, downtime, safety and operational risk, and ultimately affect productivity and profitability as asset deterioration continues.
Reducing deferred maintenance means auditing the backlog, assessing condition and criticality, prioritising by risk and impact, and reassessing regularly as conditions change.
The process itself is straightforward. Doing it consistently across hundreds or thousands of assets isn't, because the difficulty lies less in the prioritisation logic than in having the right information available for each decision. A CMMS holds work orders and history. A BMS holds operational data. IoT sensors add another layer of signals. Each works well on its own, but judging one issue's priority usually depends on condition, criticality, history, and operational consequence all at once. When that context has to be assembled by hand, prioritisation becomes another task competing with the urgent work already in front of a team.
The result is a familiar loop: an issue is identified, deferred, and urgent work takes priority. It sits in the backlog while conditions quietly change, until it fails and becomes reactive, and something else takes its place. The goal isn't to eliminate every deferral. It's to prevent deferral from becoming passive: the difference between "we haven't done this yet" and "we've deliberately deferred this because of X, and we'll revisit it when Y happens."
The real shift isn't collecting more information. It's making the information that already exists usable at the point of decision. Much of the information needed to prioritise a deferred issue already exists across the CMMS, BMS, and sensor feeds; the gap is that this context often isn't brought together at the moment a decision needs to be made.
That's the thinking behind Xempla's approach to autonomous maintenance: bringing that information and asset context together so teams can move from spotting an issue to understanding its significance, prioritising it, and deciding what to do next. The intent isn't to take people out of the decision. It's to give them consistent context to make it well, even when time, budget, and labour are limited. That same context also becomes a stronger basis for conversations about priorities, resourcing, and capital spend.
A stitch in time saves nine. But in facilities management, you don't always get to take every stitch when it appears.
There will always be more maintenance needs than available resources. The goal was never zero deferred maintenance. It's informed deferred maintenance: knowing what's being deferred, having evidence for why it can wait, and knowing what would make that decision change.
Because the real risk was never that something waits. It's that something waits and nobody can say whether it still should.
Pick any item currently sitting in your deferred maintenance backlog. Was there evidence for the original call, and is that evidence still on record, not just in someone's memory?
Most backlogs can answer what's outstanding. Far fewer can answer why a specific item is still waiting, once time has passed and the person who made the original call has moved on to the next priority.
Deferred maintenance is work that has been identified as necessary but postponed because available budget, labour, time, or maintenance windows are being allocated to higher-priority needs. The asset may still be operating, so a decision has been made to wait, but the underlying need for the work hasn't gone away.
Deferred maintenance is known work that gets postponed as a deliberate decision, made before anything goes wrong. Reactive maintenance is work triggered by a failure or urgent issue that has already occurred. Deferred maintenance carries a risk that can still be assessed in advance; reactive maintenance responds to consequences that are already materialising.
Backlogs grow when maintenance demand outpaces budget and skilled labour, when reactive failures absorb capacity meant for planned work, and when teams lack a consistent way to prioritise or revisit items once they're logged. Fragmented information across CMMS, BMS, and IoT systems makes it harder to judge urgency consistently, which compounds the problem over time.
Deferred maintenance is work that has been identified as necessary but postponed because available budget, labour, time, or maintenance windows are being allocated to higher-priority needs. The asset may still be operating, so a decision has been made to wait, but the underlying need for the work hasn't gone away.
Reducing the backlog involves auditing what's outstanding, assessing asset condition and criticality, prioritising by risk and impact, allocating available resources accordingly, and reassessing deferred items regularly as conditions change. Xempla's approach to autonomous maintenance brings CMMS, BMS, and IoT context together at the point of decision, so teams can prioritise consistently without assembling that context by hand for every item.
© Xempla. All rights reserved.