Every team that serves someone else, whether customers or colleagues in another department, makes promises, spoken or not. “We will reply quickly.” “The system is basically always up.” A service level agreement turns those vague promises into something both sides can measure. This guide answers the questions people ask most: what an SLA is, what goes in it, and how to set targets you can actually keep.
What is a service level agreement?
An SLA is a written agreement between a service provider and the people who depend on it. It states what level of service will be delivered, how it is measured, and what happens if the level is missed. It can be external, between a company and its customers, or internal, between two teams such as IT and finance.
What should an SLA include?
- Scope. What the service covers and, just as important, what it does not.
- Metrics. The numbers you will report, such as availability, first response time, resolution time or error rate.
- Targets. The value each metric must reach, for example 99.5% availability or a first response within four business hours.
- Measurement window and method. Per month or per quarter, measured with which tool, counting which hours.
- Responsibilities. What the customer must provide, such as access, information or timely approvals.
- Remedies. Service credits, escalation or a review meeting when a target is missed.
- Exclusions. Planned maintenance, events outside your control and requests outside the scope.
SLA, SLO and SLI: what is the difference?
The three terms are often mixed up. A service level indicator (SLI) is the measurement itself, such as the percentage of requests answered within two seconds. A service level objective (SLO) is the internal target for that measurement, such as 99.9%. The SLA is the agreement, with consequences attached. A healthy habit is to set your internal SLO slightly tighter than the SLA, so you get a warning margin before a promise is broken.
How do you set realistic targets?
Start from data, not ambition
Look at your last three to six months of real performance. If you resolve 80% of tickets within two days today, promising 95% within one day is a wish, not a target. Pick a number you already meet most of the time, then improve it deliberately.
Ask what customers actually need
A faster response is not always valuable. Ask users which delays hurt and which they barely notice. A four-hour first response may satisfy them completely, while a one-hour promise would cost you extra staffing for no real benefit.
Account for capacity and dependencies
Your target is only as strong as your weakest supplier. If your service depends on a vendor that guarantees 99.5%, you cannot honestly promise 99.9%. Check staffing, holidays and time zones too.
Use tiers rather than one number
Not every request is equal. Define priority levels, with a tight target for urgent incidents and a looser one for routine requests. Keep it to three or four levels so people can remember them.
Write targets as percentages
“Every ticket answered in four hours” will be broken on day one. “95% of tickets answered within four business hours” is honest about the occasional bad day.
A simple example
An internal IT team supports 200 employees. Last quarter it answered 88% of tickets within four business hours and resolved 90% of urgent incidents within eight hours. It might set these targets:
- Urgent: first response within one hour, 90% resolved within eight hours.
- Normal: first response within four business hours for 92% of tickets.
- Low: first response within two business days for 95% of tickets.
These sit slightly above current performance, so they stretch the team without being fantasy.
Common SLA mistakes
- Promising 100%. No service is perfect, and a target with no room for failure will be broken.
- Too many metrics. Three to five well-chosen numbers beat twenty that nobody reads.
- Measuring what is easy, not what matters. Uptime can read 100% while users cannot log in.
- Setting it once and forgetting it. Needs change, and the agreement should change with them.
- No review and no conversation. An SLA that is never discussed is just a document.
Reviewing and reporting
Report results on a regular rhythm, monthly for most teams, and discuss misses without blame: what caused them, and is the target or the process wrong? Review the targets themselves every six to twelve months. A spreadsheet is enough to start. If you already track operations in FulcrumGrid Command Center, you can keep SLA metrics next to your other KPIs and projects, so a slipping response time is visible before the monthly review rather than during it.
Start with real data, promise what you can keep, and revisit it often. A realistic SLA builds more trust than an impressive one you cannot meet.
Frequently asked questions
What is the difference between an SLA and a contract?
A contract covers the whole commercial relationship, including price, liability and term. An SLA is usually one part of it, focused only on measurable service levels and what happens when they are missed.
What is a good uptime target for an SLA?
It depends on what you can deliver and what users need. 99.5% allows about 3.6 hours of downtime per month, 99.9% about 43 minutes. Check your own history and your suppliers before choosing.
Do internal teams need SLAs?
Often yes. An internal SLA between, say, IT and finance clarifies expectations and priorities without legal weight. Keep it short and focus on the few requests that matter most.
How often should an SLA be reviewed?
Report results monthly and review the targets themselves every six to twelve months, or sooner after a major change in staffing, tools or demand.
FulcrumGrid Command Center
See your service levels at a glance
FulcrumGrid Command Center helps you track KPIs and projects in one place, so response times and targets stay visible all month.