Writing an SLA that actually holds up
A good SLA is specific, measurable, and something you can hit consistently. Here's what every SLA should cover, how to set targets you won't regret, and how the SLA differs from the SLOs and OLAs behind it.
What an SLA should cover
Whether it's for customers, an internal helpdesk, or a vendor contract, a complete SLA has the same seven parts. The generator above assembles all of them and injects your targets into the response and resolution table.
- 01Purpose & scopeWho and what it applies to
- 02DefinitionsResponse, resolution, priority
- 03Service hoursWhen and where you're reachable
- 04Response & resolution targetsBy priority
- 05EscalationWhat happens when a target slips
- 06ExclusionsWhat isn't covered
- 07Reporting & reviewHow performance is tracked
Setting realistic response & resolution targets
The most common SLA mistake is committing to numbers you can't hit. Separate first response (how fast someone replies) from resolution (how fast it's fixed), and set resolution targets by priority — critical issues in hours, normal requests in days. Look at your last quarter of actual response times before you commit: an SLA you beat 95% of the time builds trust, while one you miss erodes it faster than having none at all. Build in headroom by keeping your internal targets stricter than the SLA you publish.
SLA vs SLO vs OLA
An SLA is the external promise to your customer. An SLO (service level objective) is the stricter internal target you set to stay inside that promise, measured against an SLI — the actual metric. An OLA (operational level agreement) is the internal agreement between teams that makes the SLA possible — for example, IT committing to engineering that they'll provision access within an hour. The SLA is what the customer sees; the SLO and OLA are how you keep it. To keep any of them, you need to track every request against its target and let an AI agent handle the instant first response — which is what makes an ambitious SLA realistic.
