What a service level agreement is
A service level agreement, often shortened to SLA, is a written statement of what level of service a provider will deliver and how that will be measured. The provider might be an internal IT team serving colleagues, or an outside company serving a customer. The point is the same in both cases: replace vague hopes (“we’ll get to it soon”) with expectations that both sides understand.
A good agreement protects everyone. Users know what to expect and when to worry. The provider has a fair, documented standard instead of an impression of how fast it should be. When something goes wrong, the document gives both sides a calm place to start.
Some agreements are legal contracts with penalties; internal ones are often simpler commitments. This article is general information and not legal advice, so involve qualified advisers if a contract carries financial or legal consequences.
The core parts
Most agreements cover a similar set of topics.
Purpose and parties
Say who the agreement is between, what it covers and the period it applies to. A sentence or two is enough.
Services covered
List the services in terms users recognize, such as “email,” “file storage” or “device support,” not internal system names. State what is included and what is not. The exclusions are as important as the inclusions, because misunderstandings usually sit at the edges: personal devices, third-party software, custom projects.
Hours of service
State when support is available, in which time zone, and how holidays are treated. If out-of-hours help exists for certain priorities only, say so explicitly. Many disputes come from one party assuming round-the-clock cover.
Targets
This is the part people think of first. Targets are measurable goals, for example:
- Response time: how soon someone acknowledges the request.
- Resolution time: how soon the problem is expected to be fixed or a workaround provided.
- Availability: how much of the time a service should be working, usually as a percentage over a period.
Resolution targets are often tied to priority levels, so a critical fault has a shorter target than a minor request. Deciding those levels is covered by ticket prioritization practice, and the agreement should reproduce the definitions in short form.
Responsibilities
Both sides have duties. The provider might agree to log all requests and keep users informed. The customer might agree to report issues through the right channel, provide accurate details and give access when needed. Writing these down avoids the situation where the clock keeps running while the provider waits for information.
Measurement and reporting
Explain how each target is measured, where the data comes from and how often results are shared. Say how time is counted: does the clock stop while waiting for the customer? Does it run outside support hours? An unclear counting rule makes figures meaningless. Sharing results in a short regular report helps keep the agreement real.
What happens when targets are missed
Be clear about the consequences. In external contracts this may be service credits or other remedies. In internal agreements it may be a review and an improvement plan. Avoid drama; the aim is a fair, predictable process.
Exclusions and planned downtime
Name the situations that fall outside the targets, such as scheduled maintenance, events beyond the provider’s control or problems caused by changes the provider was not told about. Link planned maintenance to normal change management so people hear about it in advance.
Review and change
Needs shift over time. Set a regular review, perhaps yearly, and describe how changes are agreed.
Writing so people understand
An agreement nobody reads does not help. A few habits make it easier.
- Use plain words. Say “we will reply within four business hours” rather than “initial acknowledgment shall be provided within the designated period.” The habit of explaining technical matters without jargon, as in good technical communication, applies here.
- Define terms once. If “business hours” or “resolved” has a special meaning, explain it.
- Use examples. A short example of a ticket and how its target is counted clears up more than a paragraph of rules.
- Keep it short. A couple of pages for a simple service is often enough. Put long detail in appendices.
- Make the numbers visible. A small table of priorities and targets is easier to read than prose.
Choosing targets you can keep
Set targets from evidence, not hope. Look at your past tickets to see how long things take now, and consider your staffing. A target you meet nearly every time builds trust, while an ambitious one you regularly miss undermines it. Promise less, then deliver reliably, and tighten later if the data supports it.
A hypothetical example: if past data shows most routine requests are resolved within two business days, a target of “three business days for routine requests” leaves a margin and is more honest than promising one day.
Be careful about availability percentages as well. A figure that sounds impressive may allow more downtime than people assume once it is converted to hours per month, so show what the number means in practice.
Agreements with outside suppliers
When the provider is a vendor, read the SLA with extra care. Check what is actually measured, what is excluded and whether the remedy would meaningfully compensate for the harm. Consider how its availability promises line up with your own recovery objectives and your disaster recovery plan, since a supplier commitment can be weaker than what your business needs. These points are important in IT outsourcing arrangements, and they also matter for cloud services, where promises of availability do not remove your own responsibility to plan for failures.
After you publish
Share the agreement with the people it affects and brief the support team so they can explain it. Review the reports, discuss misses openly and update the document when reality changes. A living agreement that people trust is worth far more than a polished one that sits in a folder.