Your contract says 90 minutes from first contact to technician on site. The client's building manager is calling your control room at 11pm because a passenger is trapped in their elevator. Your dispatcher pulls up a spreadsheet to find the on-call engineer.
That spreadsheet has no concept of time elapsed. It doesn't know the SLA started 12 minutes ago. It doesn't know which technician is on call this weekend. And it won't send anyone a warning if the clock is about to expire.
This is the SLA management problem, and it is not unique to emergency response. It plays out dozens of times a week across every maintenance contract your company holds, on routine preventive maintenance visits, fire alarm tests, refrigeration checks, and everything else you're contracted to do on time.
This guide covers how SLA management actually works in the maintenance industry: the different types of SLAs, how the clock starts and stops, what escalation should look like, and why the difference between a spreadsheet and purpose-built software is measured in real money.
What SLAs actually cover in maintenance contracts
SLA is a broad term. In maintenance contracts, there are typically four distinct time commitments being tracked simultaneously.
Response time SLA
This is the time from the moment a fault is reported (or an alarm activates) to the moment a technician acknowledges the job and begins travelling. In elevator maintenance, a response SLA of 60–90 minutes covers the period from the trapped passenger call to technician departure. In fire safety, a response SLA on a critical alarm is often 4 hours; for routine faults it might be 24 hours. The response SLA does not require the technician to be on site, it requires demonstrable action.
Resolution time SLA
This is the time to close the job, fault corrected, system restored to service, paperwork signed. Resolution SLAs vary enormously by contract tier. An emergency-priority elevator fault typically carries a 4-hour resolution SLA. A routine HVAC fault with parts available might be 8 hours. A fault requiring specialist parts that must be sourced might carry a 5-day resolution target. The distinction between response and resolution is important: you can meet your response SLA while still breaching your resolution SLA if the job runs long.
PPM completion rate SLA
Planned preventive maintenance is contracted at a set frequency, quarterly, biannual, annual. The SLA here is not a response time but a completion rate. NFPA 25 requires sprinkler inspection at defined intervals; BS 5839-1 Clause 34.2 specifies the minimum frequency of contractor visits for fire alarm systems in different risk categories; LOLER 1998 sets the six-monthly thorough examination schedule for passenger lifts. A PPM SLA breach is not missing a phone call, it is missing an inspection window entirely, which can constitute a breach of the maintenance contract and, depending on the asset type, a regulatory violation.
Escalation time SLA
Some contracts include a secondary commitment: if a fault is not resolved within X hours, it must be escalated to a senior engineer or the client notified. This is rarely tracked separately in manual systems, which is where it tends to be missed.
How the clock should start
The most common SLA calculation error in field service is measuring from the wrong point in time.
In software that generates SLA timestamps automatically, the clock starts at work order creation. The work order is created the moment the fault is logged, when the call comes in, when the automated alarm fires, when the customer submits a fault report online. Not when the dispatcher assigns the job. Not when the technician accepts it.
This distinction matters because there is always a gap between when a fault is reported and when a dispatcher processes it. At 2am, that gap could be 15 minutes if the control room is busy. If your SLA clock started at assignment rather than creation, your reports show a 90-minute response when the client experienced a 105-minute response. That discrepancy will surface when your client reviews the annual performance report or, worse, during a penalty review.
The correct hierarchy:
- Clock start: Fault reported, call received, alarm activated, email logged
- Acknowledgement: Dispatcher creates and assigns the work order
- Response: Technician en route (GPS confirmation or status update)
- Resolution: Job completed, system restored, sign-off obtained
SLA compliance is measured against the elapsed time between clock start and each milestone. Every minute of delay inside your organisation, a dispatcher slow to process, a technician slow to accept an assignment, a parts-wait that isn't logged as a valid clock pause, counts against you.
Clock stop and pause mechanics
Not all time counts against your SLA, and any competent contract will define this. But the exemptions must be documented in real time, not reconstructed from memory after a breach.
Valid clock pauses include:
- Waiting for client-side access, the building manager has not unlocked the plant room
- Parts on order, documented parts request submitted, ETA confirmed
- Client decision pending, a quoted repair is awaiting written approval before work proceeds
- Third-party dependency, waiting for a specialist subcontractor or utility provider
Clock pauses that will not hold up in a dispute:
- "We couldn't get hold of anyone" (without documented call attempts at specific times)
- "The parts were in transit" (without a purchase order timestamp)
- "The client hadn't approved the quote" (without a quote issue date and a named contact who received it)
When a client challenges an SLA calculation, the burden of proof sits with you. A note in a spreadsheet column saying "waiting for parts" will not satisfy a client whose contract includes financial penalties for breach. A timestamp-anchored audit trail in a field service platform will.
SLA breaches in practice: three verticals
Understanding how breaches happen is easier with real examples. Here are three scenarios across different verticals.
Elevator: trapped passenger rescue
The contract specifies a 90-minute response SLA for trapped passenger events. The clock starts when the in-car alarm activates and your control room receives the call.
Typical failure points:
- Dispatcher takes 8 minutes to identify the shaft (no phone-to-asset mapping)
- First on-call engineer does not answer; 12 minutes lost locating the backup
- Travel time is 42 minutes, but the dispatcher didn't know the backup engineer was 12 minutes further away than the primary
Total: 62 minutes before the technician arrives, within the 90-minute target, but only because a competent dispatcher managed the delays manually. Add 10 minutes to the shaft identification, and you have a breach. Add a traffic incident to the travel, and you have a breach plus a trapped passenger who has been in a stationary car for over 90 minutes.
EN 81-28 Clause 5.3 requires the alarm monitoring record to document the time of every intervention in the rescue sequence. If you can produce that log, you can demonstrate exactly where the time went. If you cannot, the breach is undefended.
Fire safety: quarterly PPM visit
A retail site with a BS 5839-1 L2 system requires quarterly contractor visits. Your contract with the facilities manager guarantees visits in January, April, July, and October within a ±14-day tolerance window.
The technician visits in January and July. April's visit is rescheduled twice at the client's request; the second rescheduled date falls outside the tolerance window. October's visit happens on time.
Result: one PPM SLA breach. The client's insurer asks for the inspection record during an annual audit. The April gap is visible. The facilities manager escalates. Your company faces a contract penalty clause of one month's maintenance fee, £1,400 in this case, and an informal review of whether the contract is renewed.
In a spreadsheet environment, this breach is invisible until it is raised from outside. In a managed PPM system, the April visit would have flagged amber at day 7 past the due date and escalated to a manager at day 10.
HVAC: cold chain response SLA
A pharmaceutical cold storage facility has contracted you for emergency response on refrigeration units. The SLA is 4 hours from alarm to technician on site, 24/7. The penalty for a breach is £500 per hour over the SLA threshold, capped at the monthly contract value.
An alarm fires at 3:15am on a Saturday. The on-call engineer receives the callout notification via SMS. He misses the message. The second notification method, a phone call, is not configured in the system. The dispatcher on the overnight shift logs the fault but assumes the SMS will be sufficient.
The engineer calls in at 5:45am. He is on site at 6:30am, 3 hours 15 minutes after the alarm. Within the 4-hour SLA, but only just. More importantly, the 30-minute window between the SMS being sent and the call being logged as unanswered has no documentation.
If the unit had tripped rather than alarmed, if the temperature had actually crossed the threshold and pharmaceutical stock had been compromised, the £500/hour penalty would have applied from hour 4 onward, and the absence of a documented escalation attempt at, say, 3:45am would have been a serious problem.
What escalation should actually look like
Escalation is the mechanism that converts a potential SLA breach into a managed event. Most companies describe an escalation process. Fewer actually have one that runs automatically.
A functioning escalation chain for a critical fault looks like this:
T+0, Work order created, technician notified (push notification + SMS) T+10 min, If no acknowledgement from technician: automatic re-notification to same engineer plus a notification to the escalation contact (typically the team lead) T+20 min, If still no acknowledgement: escalation to secondary on-call engineer, alert sent to operations manager T+45 min, If response SLA is under 90 minutes and no technician is en route: operations manager receives an escalation call, not just a notification T+70 min (for a 90-min SLA), Pre-breach warning: 20 minutes remaining, technician not yet on site, automatic notification to site contact that response is imminent but tight
The critical distinction between a spreadsheet and a managed platform is that this chain runs without anyone manually watching the clock. The dispatcher does not need to check back at T+10 to see if the engineer responded. The system does it.
Pre-breach warnings, notifications sent before the SLA is breached, not after, are what separate reactive SLA management from proactive management. A notification at T+80 (10 minutes after the breach) tells you what already went wrong. A notification at T+70 gives you a 20-minute window to still get someone on site.
The spreadsheet problem
It is worth being specific about what spreadsheet-based SLA management actually prevents you from doing, because the failures are predictable.
No real-time clock. A spreadsheet does not know what time it is. You can record a start time in a cell, and you can manually calculate elapsed time, but neither of those things generates a proactive alert. Nobody is notified that a breach is approaching.
No escalation triggers. An escalation workflow requires a system that can send notifications at defined intervals without human input. A spreadsheet cannot do this.
Reporting requires manual reconstruction. Producing a monthly SLA compliance report from a spreadsheet means someone pulling data from multiple tabs, reconciling timestamps, and calculating compliance percentages by hand. This takes 4–8 hours per month for a company with 100+ active contracts. It is also prone to the kind of calculation errors that appear during client review meetings.
No pause tracking. If a job is on hold waiting for parts, that needs to be logged with a start and end timestamp that can be verified. A cell comment or a column entry labelled "on hold" is not equivalent.
Multiple sites, no consolidation. If your company has 200 maintenance contracts across 15 technicians, the SLA status of every open job cannot be held in a single spreadsheet that updates in real time. The dispatcher's spreadsheet, the scheduler's spreadsheet, and the engineer's notebook all have different versions of the truth.
The transition away from spreadsheets is not a technology preference. It is a risk management decision. Every month you operate on spreadsheets is a month where an undetected SLA breach is possible, and where the audit trail to defend yourself in a dispute is incomplete.
SLA reporting: what clients actually want
Monthly or quarterly SLA reporting is a contractual obligation in most managed maintenance agreements. Clients at the facilities management level, and particularly at the corporate level, have their own reporting obligations to building owners, insurers, and in regulated industries to their own regulators.
The report structure that clients want:
Response SLA compliance rate. What percentage of reactive jobs met the response time target this period? Broken down by priority tier.
Resolution SLA compliance rate. What percentage of jobs were fully resolved within the contracted resolution window? Including clear notation of jobs where the clock was paused and why.
PPM completion status. Which scheduled visits were completed, which are outstanding, and what the completion rate is against the contracted schedule for the period.
Breach summary. Any SLA breaches in the period: job reference, breach duration, reason, and action taken. Clients do not expect zero breaches, they expect transparency and evidence of corrective action.
Trend data. Month-over-month comparison. Is performance improving, stable, or declining?
Software that generates this report automatically from the work order data, pulling timestamps, calculating compliance percentages, and formatting for output, eliminates the manual report preparation overhead and reduces the risk of presenting a client with a figure that does not match their own records.
Penalty clauses and how they are triggered
Most multi-site maintenance contracts include financial penalty clauses for SLA non-compliance. The structures vary, but the common patterns are:
Per-breach fee. A fixed amount per SLA breach, typically £100–£500 depending on priority tier and contract value.
Percentage deduction. A monthly fee reduction of 5–20% if the overall SLA compliance rate falls below a defined threshold (typically 95% for response, 90% for resolution).
Escalating penalties. Breaches above a defined frequency in a rolling period trigger a step-change penalty. Three response SLA breaches in a quarter might incur no penalty; the fourth triggers a monthly deduction.
Termination trigger. Some contracts allow termination without notice if SLA performance falls below a defined floor for two consecutive periods.
Penalty clauses are enforceable. If you are tracking SLA compliance on a spreadsheet, you may be unable to dispute a client's penalty calculation, not because you are wrong, but because your records are insufficient to demonstrate the correct timestamps for each job.
Building SLA management into your contracts
Effective SLA management starts before the contract is signed. The way SLAs are worded in your contract determines how much flexibility you have when things go wrong.
Define the clock start precisely. "From notification of fault" is ambiguous, notification by whom, to whom, through which channel? A contract that specifies "from the time the fault is logged in the maintenance management system" gives you control over the timestamp.
Define valid pause conditions. List them explicitly: third-party access delays, waiting on parts over a specified value, client-directed postponement. Vague language ("force majeure" or "circumstances beyond reasonable control") will not protect you from a penalty charge for a parts wait.
Set realistic SLA tiers by asset type. A response SLA of 4 hours for a pharmaceutical refrigeration unit may be contractually achievable. The same 4-hour SLA for an elevator in a high-rise residential building in a city with heavy overnight traffic may not be. Agreeing to an SLA you cannot consistently meet is a penalty risk, not a competitive advantage.
Include a reporting schedule. Define the format and frequency of SLA reports in the contract. Clients who receive regular performance data proactively are less likely to spend the contract period waiting for a breach to use as a negotiating point.
How RemoteOps handles SLA management
RemoteOps was built for the maintenance verticals where SLA compliance is not a performance metric, it is a contractual and sometimes regulatory obligation.
The platform starts the SLA clock automatically at work order creation, whether the job was generated by an inbound call, an automated alarm, a scheduled PPM trigger, or a manual entry. The clock is visible in real time on every open work order, colour-coded by how much of the SLA window remains.
Escalation runs on configurable rules: if a technician has not acknowledged a job within 10 minutes, the next escalation contact receives a notification. If a job reaches 75% of its SLA window without a technician en route, the operations manager is alerted before the breach, not after it.
PPM schedules are generated automatically from contract data. When a quarterly visit is due, the work order is created, assigned, and tracked without a scheduler manually checking a calendar. If a visit is at risk of falling outside the contracted window, the system flags it.
For elevator maintenance specifically, RemoteOps identifies the asset from the incoming call number before the dispatcher picks up, the shaft, building, contract, and response SLA are on screen within seconds of the call connecting. The SLA clock starts at the moment the call is received, not when the dispatcher finishes logging it.
Monthly SLA reports export directly from the work order data with no manual compilation.
FAQ
What is a standard SLA for elevator trapped passenger response?
Most residential and commercial elevator maintenance contracts in the UK and EU specify a 60–90 minute response SLA from the moment the in-car alarm is activated to technician arrival on site. EN 81-28 Annex A provides guidance on response expectations for alarm monitoring services. Premium contracts for high-rise or high-traffic buildings may specify 45 minutes or less.
How should clock pauses be documented to hold up in a dispute?
Each pause needs a start timestamp, a reason from a defined list (access delay, parts on order, client decision pending), and an end timestamp when the pause is lifted. The person who initiated the pause and the person who ended it should both be recorded. Narrative comments in a free-text field are supporting evidence; they are not a substitute for structured timestamps.
What is a typical PPM completion rate SLA?
Most managed maintenance contracts set a minimum PPM completion rate of 95% per period. Some clients in regulated industries (hospitals, pharmaceutical storage, nuclear facilities) require 100% completion within a defined tolerance window. The tolerance window, typically ±14 days either side of the scheduled date, is a separate and important parameter; completing a visit 30 days late still counts as a breach even if it was completed.
Can I retroactively apply SLA clocks to old jobs?
No. SLA clocks must be applied at job creation. Retroactive assignment of a start time introduces a gap between when the fault was actually logged and when your system says it was logged, exactly the kind of discrepancy that creates problems in a penalty review. Migrating to a managed system means setting a cutover date; jobs before that date are not SLA-tracked, and you communicate that to clients transparently.
What happens to SLA compliance when a technician is off sick?
The contract SLA does not pause because your on-call engineer called in sick. This is a business continuity problem, not an SLA definition problem. Your escalation chain and on-call rota should be configured so that a single technician absence does not cascade into a response failure. If your escalation chain reaches an empty slot, a named technician with no active backup, the SLA risk is yours.
Internal links
- Field Service Management Software Buyer's Guide, evaluating FSM platforms for critical infrastructure
- Elevator Maintenance Software Comparison, how platforms compare on elevator-specific workflows
- How to Reduce Trapped Passenger Rescue Time, the rescue workflow stage by stage
- Pricing, RemoteOps plans and contract tiers