Setting realistic reactive maintenance response times

Response time targets often get set once, early, and then never revisited — a number picked because it sounded reasonable at the time, not because anyone checked whether it reflected actual team capacity, contractor availability or the mix of urgency levels a typical week brings. A target nobody's hitting consistently isn't really a target any more; it's background noise everyone's learned to tune out.

Start from urgency tiers, not one number

A single response time target applied to every reported issue is almost always wrong for most of what comes in. A burst pipe and a flickering light in a rarely used corridor don't belong in the same tier, and forcing them into one target either makes the urgent tier too slow or makes the whole system look like it's constantly missing deadlines because low-urgency jobs are dragging the average down.

Base targets on evidence, not aspiration

A realistic target starts from what the team has actually been achieving, not what would look good in a report to leadership. If genuine data shows most urgent jobs currently get a first response within four hours, setting the target at four hours (and then working to improve it) is more useful than setting it at two hours and immediately missing it on most weeks. Aspirational targets that are consistently missed erode trust in the whole reporting system faster than honest ones that are occasionally tight.

• –Urgent / safety-related: fastest tier, response measured in hours, reviewed against genuine current capacity
• –Standard operational issues: a same-week or few-day tier, most of the routine volume lands here
• –Low priority / cosmetic: a longer window, batched where sensible rather than treated as individually urgent
• –Contractor-dependent jobs: a realistic buffer added on top, since availability isn't within direct team control

Where the target actually gets tested

Response time promises get tested hardest during a busy week, not a quiet one — which is exactly the moment planned and reactive work compete most directly for the same hours. A target that only works when the week is calm isn't really a target, it's an assumption dressed up as a commitment.

Getting the initial report right also shortens the effective response time without changing the target at all — a clearly triaged report that lands correctly categorised the first time saves the minutes or hours that would otherwise go into re-routing a miscategorised job.

A target nobody can meet is worse than none

A four-hour response target on an estate whose engineer coverage makes four hours impossible on a Friday afternoon does not improve response. It produces a target that is missed routinely, then quietly stops being reported, then stops being referred to at all. Meanwhile the genuinely urgent jobs get no more attention than they would have done, because the target did not distinguish them.

Tiering is what makes targets survive. A small number of genuinely urgent categories with a short target the team can actually hit, and a longer, honest target for everything else, gives a more useful picture than one aspirational number applied to every job regardless of consequence.

Common mistakes

• –One response target applied to every job regardless of urgency
• –Setting targets on aspiration rather than on what the resourcing supports
• –Letting the reporter set the urgency with no triage
• –Measuring time to attend without measuring time to resolve
• –Not reviewing targets as the estate or the team changes
• –Reporting against a target everyone knows is not met, until it is dropped