Reactive vs Planned Maintenance: Getting the Balance Right

Reactive maintenance means responding to failures after they happen. A pump stops, a light goes out, a tenant reports a leak, a fire door fails an inspection — and someone goes to fix it. It is sometimes called run-to-failure, breakdown maintenance, or corrective maintenance, and for some assets it is a perfectly rational choice. A cheap light fitting that is fast to swap and harms nothing when it dies does not need a service schedule. You run it until it fails and replace it.

The trouble starts when reactive becomes the default for everything. Unplanned failures arrive at the worst times, often in clusters, and they cost more than the same work done on a schedule. You pay overtime or emergency call-out rates, you order parts at short notice, and the failure of one component frequently damages others around it. A small water leak left to become a burst pipe is the classic example: a fitting that would have cost little to replace turns into a flooded floor, ruined finishes, and a displaced occupant.

There is also a hidden tax that never shows up on an invoice. A team stuck in reactive mode spends its day interrupted, chasing the loudest problem rather than the most important one. There is no slack to do the preventive work that would reduce the failures, so the backlog grows and the firefighting deepens. Reactive maintenance is not a failure of effort — busy teams are often exhausted — it is a failure of visibility and planning.

Planned maintenance covers any work you schedule in advance rather than wait for. It includes preventive maintenance — servicing assets at set intervals or after set usage, like changing filters quarterly or inspecting a roof before winter — and condition-based maintenance, where you act on a measured signal such as vibration, temperature, or a wear reading before failure occurs. The shared idea is that you intervene on your own terms, when it is convenient and cheap, instead of on the asset's terms, when it is urgent and expensive.

The payoff is steadier and more controllable than reactive work. Planned tasks can be batched, scheduled into quiet periods, and resourced with the right parts on hand. Equipment that is serviced on time tends to last longer and run more efficiently, and you catch small defects while they are still small. Crucially, planned work smooths out the peaks: instead of three emergencies landing on the same Monday, you have a predictable flow of jobs you can staff and budget for.

Planned does not mean perfect, and it is possible to over-plan. Servicing an asset far more often than it needs wastes labour and parts, and aggressive schedules can even introduce faults — every time you open a sealed unit, you risk reassembling it wrong. The goal is not maximum planning; it is enough planning that the assets which matter rarely surprise you, while you let genuinely disposable items run to failure.

There is no universal split between reactive and planned work, but there is a useful rule of thumb: the more an asset costs to fail — in money, safety, disruption, or compliance — the more it deserves a plan. Sort your assets into rough tiers. Critical assets whose failure stops operations, endangers people, or breaches a legal duty belong firmly in the planned camp. Important-but-tolerant assets can run on light preventive schedules. Truly disposable items can stay reactive, because planning their upkeep would cost more than the failures.

A common benchmark in facilities and field-service work is to aim for the majority of labour hours to be planned rather than reactive — many mature teams target something like seventy to eighty percent planned. Treat that as a direction, not a law. A brand-new building with assets under warranty may sit far more reactive and be fine; an ageing site full of end-of-life equipment may need heavy planning just to stay ahead of failures. The right ratio is the one where emergencies are rare and the planned schedule is actually being completed, not endlessly deferred.

Whatever ratio you choose, measure it honestly. Track the share of jobs and hours that were planned versus reactive, and watch the trend over months rather than weeks. If the reactive share keeps climbing, your schedules are either wrong or being skipped, and the backlog is winning. If you can steadily shift hours from reactive to planned without failures rising, you are getting the balance right.

Teams rarely choose to be reactive — they get trapped there. The trap is circular: you are too busy fixing failures to do the preventive work that would stop them, so failures keep coming, so you stay busy. Breaking out takes a deliberate investment of time the team feels it does not have. That is a leadership and scheduling problem as much as a technical one, and it will not solve itself by working harder.

But there is a quieter reason teams stay stuck, and it is about data. To plan, you need to know what is actually failing, how often, and where. Most reactive teams cannot answer that, because their issues live in places that do not add up: a voicemail, a text message, a sticky note, a half-remembered conversation in the corridor. Each fix gets done and forgotten, leaving no record. Without a trail of past issues, you cannot see the pattern — the same valve failing every few months, the same building generating most of the call-outs — so you cannot target a plan where it would do the most good.

This is the insight that changes everything. The shift from reactive to planned is not mainly about buying scheduling software or hiring more people. It starts with capturing every issue properly, so that the flow of reactive work becomes the evidence base for your plan. Good issue reporting is what turns a stream of random emergencies into a map of which assets actually need attention — and that map is the prerequisite for planning at all.

Start by making sure every reactive job is recorded the same way, with the same minimum detail: what failed, where exactly, a photo, and when. That sounds basic, but consistency is what makes the data usable later. If half your issues are logged with a precise location and half say "the thing in the back room," you cannot aggregate them. A standard capture format on every report is what lets you later count failures by asset, by category, and by location.

Once you have a few months of consistent records, the patterns surface on their own. You can see which assets generate repeat call-outs, which categories of fault dominate, and which sites or units consume the most hours. Those repeat offenders are your planning shortlist. An asset that has failed three times reactively this year is telling you it needs a preventive schedule, a condition check, or replacement — and now you have the evidence to justify the spend to whoever holds the budget.

From there the loop tightens. You convert the worst repeat failures into scheduled tasks, you watch whether the reactive call-outs for those assets fall, and you keep feeding new issue data back in. The reactive work never disappears entirely — and it should not, because it is your early-warning system — but its share shrinks as your plan absorbs the predictable failures. The teams that escape firefighting are simply the ones that treated every reported issue as data, not just a job to close and forget.

SnagGrid is built to capture issues consistently enough that they become a planning tool, not just a to-do list. Whoever spots a problem — a technician, a caretaker, a resident through a public no-login form with its own QR code — snaps a photo and drops a map pin, and the address auto-fills so the location is right without typing. They add rough notes, and AI drafts a clear, factual report they approve before it sends. It never invents facts, so the record reflects exactly what was seen. That uniform capture across every report is precisely what makes the data add up later.

From there SnagGrid emails the right recipient through per-category routing, logs every item to an audit trail, and gives one-tap follow-up reminders so nothing stalls into a fresh emergency. A team dashboard with roles shows the whole flow of reactive work in one place, and CSV export plus a scoped REST API with webhooks let you pull that history into your own analysis — so you can finally see which assets keep failing and which deserve a plan. Pricing is $29 per month per organization for one seat, plus $15 per month for each extra seat, which keeps it practical for a small team to give everyone a way to report.

The point is not the tooling for its own sake. It is that a clean, complete record of your reactive work is the raw material for planning. When every issue is captured the same way and kept in one trail, the move from constant firefighting to a deliberate maintenance schedule stops being a someday ambition and becomes something you can actually measure and act on.