Reactive Work Is Not the Exception

Planned preventive maintenance is what gets designed. It has schedules, checklists, frequencies and reports. Reactive work — the lift that stopped, the leak on level three, the door that will not lock — is handled as an interruption to that design, even though on most contracts it consumes more of the week than the planned work does.

The result is two operating models running side by side. One is well instrumented. The other runs on phone calls.

The evidence problem

Planned work produces evidence naturally, because the checklist is the record. A reactive job often produces none, or produces it in the wrong place: a photograph on a supervisor’s phone, a note in a WhatsApp thread, a verbal confirmation that the tenant is happy.

That gap surfaces at the worst possible moment. When a client disputes a response time or an insurer asks what condition the asset was in, the planned regime can answer and the reactive one cannot — despite the reactive job being the one that mattered.

Attaching evidence to the job rather than to a person is most of the fix. Not more paperwork; the same photograph, taken at the same moment, landing somewhere it can be found six months later by someone who was not there.

One view per site, not per work type

Supervisors covering multiple sites end up assembling the picture themselves — planned work from one system, reactive tickets from another, contractor attendance from an email. They become the integration layer, and the quality of the information depends on which supervisor is on.

The organisations that have got past this did not unify everything. They unified the view: every job at a site, planned or reactive, in one place, with its current state and who holds it. The underlying processes stayed different, because they genuinely are different. What changed is that nobody has to reconcile them manually to answer “what is happening at this building today”.

Reactive volume is a signal, not noise

If reactive work is only ever logged as individual tickets, it stays invisible in aggregate. Logged consistently against assets and locations, it starts answering better questions: which asset generates the most callouts, which site absorbs the most unplanned hours, which planned regime is not preventing what it was designed to prevent.

That is the argument for treating reactive work as a first-class part of the system rather than an exception to it. Not tidiness — it is the only route to knowing whether the planned programme is working.