# What is an SLA (service level agreement) and how is it measured in a maintenance contract? > What an SLA or service level agreement is, what it measures in a maintenance contract, when the clock starts, calendar vs business hours, penalties and a sample clause. Joaquín Tenés · 2026-11-14 · https://delegic.com/en/glossary/sla In a maintenance contract, the SLA is the line that says “emergencies within four hours”. It looks like a detail, but it decides whether there’s a penalty at the end of the month, which requests are handled first and, often, whether the customer renews. Here’s what it is, what it measures, when the clock starts, how penalties are written and how to meet it without living by the stopwatch. ## In short - SLA stands for service level agreement. - In maintenance it usually sets three deadlines per priority: respond, arrive and resolve. - What causes the most arguments is when the clock starts and whether it runs at night and on weekends. - With four calendar hours, a request at 7 p.m. on Friday is due that night; with four business hours, on Monday at noon. - What’s missed gets paid for, usually as a discount on the monthly fee, and what’s badly measured gets argued about. ## What is an SLA? [IBM](https://www.ibm.com/think/topics/service-level-agreement) defines it as a contract between a service provider and its customer that sets out what service will be provided and what level of performance can be expected. The key word is “level”: a maintenance contract says which equipment is maintained and which inspections are done; the SLA says how fast the provider responds when something breaks, with figures that can be measured and checked. Field service companies, building maintenance firms, IT providers and anyone who handles incidents use them, and large customers, public tenders and service management software all speak of SLAs. ## What does an SLA measure in a maintenance contract? The usual approach is to set three deadlines, with different ones for each priority. The **response time** is how long it takes to log the request and get back to the customer; IBM describes it as the acceptable time for the provider to log and respond to an incident. In field service, many contracts use “response time” for something else, the time until the technician arrives, and it’s worth writing down which of the two is measured. The **arrival time** is exactly that: from the request until the technician is standing in front of the equipment. And the **resolution time** runs from the request until the equipment works again. For critical installations, **availability** is sometimes added: the percentage of time the equipment is running over a period, which IBM illustrates with an example of 99.5% every 30 days. And in contracts with preventive maintenance, the SLA may also set [PM compliance](/en/glossary#pm-compliance): the share of scheduled inspections that must be done on time. How each one is calculated is in [maintenance KPIs](/en/blog/maintenance-kpis). What usually doesn’t work is an SLA with a single deadline for everything. A cold room that’s warming up and a noisy split unit can’t run on the same clock, so the SLA goes hand in hand with written priority criteria: what is urgent, what is normal and what gets scheduled. Without them, the SLA ends up being decided by whoever complains loudest. How to set the priority of each request, with examples, is in [the work order](/en/blog/work-order). ## When does the clock start? This is the question that causes the most arguments, and it has two parts. The first is the starting point. For the customer, the clock starts when they report the problem: when they call, send the WhatsApp message or write the email. For many offices, it starts when the request is entered into the system. If a request comes in by phone at 7 p.m. and is logged at 9 a.m. the next day, the system will say it was answered right away and the customer will say they waited fourteen hours. The contract has to say which moment counts, and the fair one is the first. The second part is whether the clock runs at night and on weekends. There are two ways to count. In **calendar hours**, the clock never stops. In **business hours**, it only runs within the agreed schedule, for example Monday to Friday from 8 a.m. to 6 p.m. The customer service platforms of the big players, like [Zendesk](https://support.zendesk.com/hc/en-us/articles/4408829459866-Defining-and-using-SLA-policies), ask you to choose one of the two for each priority. With a four-hour SLA and a request on Friday evening, the difference is huge: With the same number in the contract, one customer expects someone that same night and the other on Monday at noon. If the contract doesn’t say, each side will read it in its own favor. Software, for its part, falls back on the stricter reading: in Microsoft’s Dynamics 365, if no schedule is defined, it assumes work goes on all day, every day. [Microsoft Learn](https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/define-service-level-agreements) documentation on Dynamics 365 SLAs, accessed on November 14, 2026. ## What happens if it isn’t met? An SLA without consequences is a statement of intent. The contract normally sets compensation when the provider doesn’t make it in time, and it should be proportionate: IBM mentions financial compensation, service credits or other arrangements, and a clause that’s sometimes forgotten, the one that lets the provider earn those credits back if it beats the agreed level in the following months. In maintenance, a common form is a discount on the monthly fee for each request outside the deadline, with a cap, and the option to terminate the contract if the breach repeats. This is how it might be written. It’s an illustrative example, not legal advice, and the percentages and deadlines are made up: each contract sets its own. Sample service level clause 1. **Priorities.** A request is urgent if there’s a risk to people, to the building or to stock, or if it leaves a whole installation without service. It’s normal if it leaves one unit not working with an alternative available. Everything else is scheduled with the customer. 2. **Deadlines.** For emergencies, the technician will arrive within 4 calendar hours at most. For normal requests, within 24 business hours, Monday to Friday from 8 a.m. to 6 p.m. Scheduled work, on the date agreed. 3. **Counting.** The deadline runs from when the customer reports the request through any of the channels in the annex, not from when it’s logged. It stops only if the customer doesn’t provide access or asks to postpone the visit, and the reason is noted on the request. 4. **Compensation.** For each emergency outside the deadline, 2% of that month’s fee will be discounted, up to a maximum of 10%. Three consecutive months above the maximum allow the contract to be terminated. 5. **Reporting.** Each month the provider will send the list of requests with the time they came in, the arrival time and the resolution time. ## What’s the difference between an SLA, an SLO and a KPI? The three get mixed up because they talk about the same thing, the level of service, from different angles. The **SLA** is the commitment to the customer, in writing and with consequences. An **SLO**, service level objective, is each specific target within that agreement; IBM defines it as the agreed performance target for a service over a period, for example “95% of emergencies within four hours”. And a **KPI** is any indicator the company tracks on its own, whether it’s in the contract or not, like mean time to repair or first-time fix rate. Many companies set themselves an internal target stricter than the contract, for example reaching emergencies in three hours when the SLA says four. It’s the margin that absorbs a traffic jam or an afternoon with three emergencies at once without paying a penalty. ## How do you meet an SLA without living by the clock? Most SLAs aren’t missed on the road but earlier: in the request nobody picked up, the one logged the next day or the one that came in as normal when it was urgent. Every time a customer has to call again because nobody answered, SLA time has already run. So the first thing is that every request is logged with the time it arrived, whichever way it comes in, at night and on weekends too. The second, that it’s classified by the written criteria and not by eye, and that emergencies reach the on-call technician straight away. The third, warning before it’s due: the big platforms have a “nearing noncompliance” alert, as Microsoft calls it, so the office can rearrange the schedule in time. And the fourth, producing the monthly report the contract asks for with the real times, not the logging times. The first part is what an AI agent does in the office. At [Delegic](/en), the agent takes the request by phone, WhatsApp, email or chat at any hour, leaves it in your system with the time the customer reported it, asks what’s needed to classify it and passes emergencies to the on-call technician according to your rules. The SLA clock starts with accurate data, and nobody has to reconstruct it afterwards. ## Frequently asked questions ### What does SLA stand for? Service level agreement. Watch out when searching: SLA is also a resin 3D printing technique, which has nothing to do with it. ### Is an SLA mandatory? Between businesses, no: it’s something agreed in the contract. Many large customers, public bodies in their tenders and almost every maintenance contract for critical installations require one. ### What response time is normal? There’s no standard figure: it depends on the equipment, how critical it is and what the customer pays. What is common is to separate emergencies, with deadlines in hours, from everything else, with deadlines of one or more days, and to say what kind of hours are counted. Before signing one, it’s worth measuring how long it takes today, using the requests from the last few months. ### Does the clock run if the customer isn’t there? Only if the contract doesn’t say otherwise. The reasonable approach is for the clock to stop when the technician can’t get in because of the customer, and for that to be noted on the request with the time. ## Related terms - [Response time](/en/glossary#response-time): from when the request comes in until it’s handled. - [On-call](/en/glossary#on-call): who handles emergencies outside office hours. - [PM compliance](/en/glossary#pm-compliance): scheduled inspections done on time. - [Work order](/en/glossary#work-order): the record of each request, with its times. - [MTTR](/en/glossary#mttr): mean time to repair.