Whether an IT service provider responds "quickly" or a system is "mostly" available remains a matter of opinion as long as nothing has been agreed. An SLA makes these expectations measurable and therefore verifiable. It is usually part of a service contract, for example for managed IT or cloud services, but is also used between internal IT and business departments.
How an SLA is structured
Typical components are:
- Service description: which services are covered and which are explicitly not.
- Service hours: when the service provider can be reached, for example on weekdays during office hours or around the clock.
- Response and resolution times: usually tiered by priority. The response time indicates when work begins, the resolution time when the disruption is fixed or worked around.
- Availability: a percentage over a period. 99.9% in a month with 30 days mathematically allows about 43 minutes of downtime.
- Measurement and reports: how the values are collected, usually via the ticketing system in the service desk and IT monitoring, and how often reports are made.
- Consequences of non-compliance: for example service credits or defined escalation paths.
In IT service management, an SLA is often supported by further agreements: operational level agreements (OLAs) govern the cooperation of internal teams, and contracts with suppliers (underpinning contracts) secure third-party services.
Typical examples
- A support contract specifies that work begins much faster when a central system fails than when a single workstation has a problem.
- A cloud provider guarantees monthly availability and grants credits if it falls short.
- An internal IT department agrees extended service hours for the ERP system with management during month-end closings.
What companies should keep in mind
- Define priorities unambiguously so that it is clear when a disruption counts as critical.
- Do not confuse response time and resolution time: a short response time says nothing about when the problem will be fixed.
- Record when a deadline starts and whether it counts only within service hours.
- Check how availability is measured and whether planned maintenance windows are excluded.
- Align SLA values with actual business requirements, for critical systems for example with RPO and RTO.
- Agree on regular reports and review them together.