How to Write an IT Service Level Agreement (SLA) That Works

A service level agreement (SLA) sets out what an IT service will deliver, how quickly, and how performance will be measured. Done well, it gives both sides clarity: the customer knows what to expect and the provider knows what it must achieve. Done badly, it becomes either a document nobody reads or a source of constant dispute. Whether you are a business engaging an external IT provider or an internal IT team agreeing service levels with the rest of the organisation, the same principles apply. This guide walks through how to structure an SLA, which metrics matter, and the mistakes that most often undermine them.

What an SLA is and is not

An SLA is a set of measurable commitments about service quality. It usually sits within or alongside a wider contract or master services agreement that covers legal terms such as liability, data protection, payment and termination. Keeping the SLA focused on service performance makes it easier to read and review.

An SLA is not a guarantee that nothing will go wrong. It defines how problems will be handled when they occur. Nor is it a substitute for a good working relationship; the best SLAs support collaboration rather than replacing it. Internally, the equivalent document is sometimes called an operational level agreement (OLA), particularly when it describes commitments between teams within the same organisation.

Essential sections of an IT SLA

1. Parties and purpose – who the agreement is between and what it aims to achieve.
2. Scope of services – exactly which services, systems, users and locations are covered, and explicitly what is excluded.
3. Service hours – when support is available, including any out-of-hours or emergency arrangements, and how public holidays are handled.
4. How to request support – the channels for raising issues, such as a portal, email or telephone, and which are appropriate for urgent matters.
5. Priority definitions – how incidents are categorised by impact and urgency.
6. Service targets – response, resolution and availability targets for each priority level and service.
7. Responsibilities – what the provider must do and what the customer must do.
8. Measurement and reporting – how performance is measured, how often it is reported and to whom.
9. Escalation – named routes for escalating unresolved issues or concerns.
10. Remedies – what happens if targets are consistently missed.
11. Review and change – how and when the SLA is reviewed and updated.

Defining priority levels

Priority levels are the heart of most IT SLAs. They should be based on business impact and urgency, not on who raised the ticket or how loudly. A typical four-level scheme looks like this:

The response and resolution times attached to each level depend on the service you are buying and what you are prepared to pay for. Faster targets generally require more staff on standby, so be realistic. Agree the definitions with examples relevant to your business, and include a mechanism for either party to adjust a ticket's priority with justification.

Choosing metrics that matter

The most common SLA metrics are:

• Response time – how long until a qualified person acknowledges and begins working on an issue. Specify that an automated acknowledgement does not count.
• Resolution time – how long until the issue is fixed or a workaround restores service. Define whether the clock pauses while waiting for the customer.
• Availability – the percentage of agreed service hours a system is available, with planned maintenance windows defined and excluded.
• First contact resolution – the proportion of issues resolved without escalation.
• Customer satisfaction – feedback collected after tickets are closed.

Beware of metrics that can be met while service remains poor. A provider can hit every response target with prompt but unhelpful replies. Pair speed metrics with quality measures such as satisfaction scores, reopened ticket rates and a regular review of a sample of tickets. Measuring a small number of meaningful things well is better than tracking dozens of figures nobody acts on.

Responsibilities on both sides

SLAs often focus solely on the provider, but service depends on both parties. Customer responsibilities commonly include:

• Reporting issues through the agreed channels with sufficient detail.
• Providing timely access to people, premises and systems when needed.
• Notifying the provider of planned changes such as new starters, office moves or new software.
• Not making unapproved changes to managed systems.
• Maintaining supported versions of hardware and software, or accepting best-effort support for those that are not.

Spelling these out avoids disputes when a missed target was caused by circumstances outside the provider's control.

Reporting, review and remedies

Agree a regular reporting cycle, typically monthly, showing performance against each target, volumes by category, trends and any major incidents with root-cause summaries. Hold periodic service reviews, perhaps quarterly, to discuss the figures, recurring problems and upcoming changes.

Remedies for missed targets range from service credits, where part of the fee is refunded, to formal improvement plans and, ultimately, termination rights for persistent failure. Service credits are common but are rarely large enough to compensate for real business disruption; their main value is as a signal. Often more useful is a requirement for a documented improvement plan when targets are missed for consecutive periods.

Common mistakes to avoid

• Vague scope, leaving it unclear whether items such as mobile phones, printers or home working setups are covered.
• Priority definitions without examples, leading to arguments over every ticket.
• Resolution targets that ignore third-party dependencies, such as an internet provider's repair times.
• No definition of when the clock starts, pauses and stops.
• Unrealistically aggressive targets that drive up cost without matching business need.
• Agreeing the SLA once and never reviewing it as the business changes.

SLA drafting checklist

• Scope and exclusions clearly listed
• Service hours and support channels defined
• Priority levels with business-relevant examples
• Response, resolution and availability targets per priority
• Clock rules for pausing and stopping timers
• Responsibilities of both parties
• Reporting format and frequency agreed
• Escalation contacts named
• Remedies and improvement process defined
• Review date set

Conclusion

An effective SLA is clear, measurable and realistic. It defines what is covered, how issues are prioritised, what targets apply and how performance will be reported and improved. Most importantly, it is treated as a living document that both parties use and review, not something filed away after signing. If you take the time to agree priority definitions with real examples, choose metrics that reflect actual service quality and set responsibilities on both sides, your SLA will become a practical tool for better IT service rather than a source of friction.