Insights / Guide / Managed IT services and infrastructure support
GuideService levels explained in plain language
A service level agreement should tell you what you can expect, how fast, and what happens if it is missed. Here is how to read one, and how to write a better one.
A service level agreement, usually shortened to SLA, is the part of an IT support contract that says what the supplier will do and how quickly. In theory it protects you. In practice, many SLAs are written in language that only the supplier’s lawyers enjoy, with targets that sound reassuring but measure the wrong things.
A good SLA should say three things clearly: what you can expect, how fast, and what happens if it is missed. This guide explains the key terms in plain language, shows how to set priorities that reflect your business, and describes the reporting and review rhythm that keeps a service honest over time. It applies whether the support comes from an external managed service provider or from your own internal IT team.
Response versus resolution
The most important distinction in any SLA is between response and resolution. They are often confused, sometimes deliberately.
- Response time is how soon someone acts: a qualified person acknowledges the issue and starts working on it.
- Resolution time is how soon the problem is fixed, or a workaround restores normal working.
- An automated email saying that your ticket has been logged is not a response. Agree that a response means a person has looked at the issue.
Many contracts promise fast response and say little about resolution. A fifteen-minute response is comforting, but if the problem then takes three days to fix, the business still loses three days. Agree both, with resolution targets that reflect how long your operations can reasonably tolerate the problem.
Workaround or fix?
Many SLAs count the clock as stopped when a workaround restores service, even if the underlying fault remains. That is reasonable, provided the permanent fix is tracked separately with its own target, so temporary measures do not quietly become permanent.
Priorities by business impact
Not every problem deserves the same urgency. A system that stops a factory is not the same as a broken mouse. Priorities should be defined by the impact on the business, not by how loudly someone complains or how senior the person reporting it happens to be.
A common structure uses four levels. The exact targets will depend on your operations, your budget and what your supplier can realistically deliver, but the shape below works for many mid-sized organisations.
- Priority 1, critical: a core service is down for many users or a key operation has stopped, such as production, order taking or payments. Immediate response, around the clock if the business runs around the clock, with continuous work until service is restored.
- Priority 2, high: a core service is seriously degraded, or a single critical user or site cannot work. Rapid response within working hours, with a resolution target measured in hours.
- Priority 3, normal: an individual user has a problem that limits their work but has a workaround. Response within the working day, resolution within a few days.
- Priority 4, low: requests, minor faults and questions, such as a new starter’s equipment or a change to a mailing list. Handled in order, with targets measured in days.
Making priorities work in practice
Write down examples for each priority that make sense in your organisation. For a distributor, a priority 1 might be the warehouse management system failing on a weekday morning. For a professional services firm, it might be email and document storage being unavailable before a filing deadline. Examples remove most arguments about classification before they start.
- List your critical systems and the business processes they support, and agree their priority in advance.
- Allow the business to raise a ticket’s priority when impact grows, and record why.
- Define when priority 1 incidents must be escalated to named senior people on both sides.
- Check periodically that priorities are being assigned consistently, not inflated or deflated.
When the clock starts, pauses and stops
The fine print around timing makes a large difference to what an SLA actually guarantees. Read it carefully, and if the wording is vague, ask for it to be made specific.
- Service hours: are targets measured around the clock or only during business hours? A four-hour resolution target in business hours could mean the following afternoon.
- Start: does the clock start when you report the issue, or when the supplier logs and categorises it?
- Pause: under what conditions does the clock stop, for example when waiting for a user to respond or for a third-party supplier? Pauses should be reasonable and visible in reporting.
- Stop: who confirms the issue is resolved? The user, or the supplier closing the ticket?
Availability targets deserve the same scrutiny. A promise of high uptime sounds impressive, but check what it covers. Is it measured per system or across the whole estate? Is planned maintenance excluded, and if so, when can it happen? Is it measured monthly or annually? A target that allows several hours of unplanned downtime during your busiest week may be met on paper while the business suffers.
What happens if targets are missed
An SLA without consequences is a statement of intent. Many contracts include service credits, small reductions in the monthly fee when targets are missed. They are useful as a signal, but rarely large enough to compensate for real business disruption. Treat them as an incentive for attention, not as insurance.
More valuable are clear escalation routes and improvement obligations. If targets are missed repeatedly, the contract should require a formal improvement plan, with named actions and dates, and give you the right to exit if performance does not recover. These provisions are rarely used, but their presence changes how a supplier prioritises your account.
Report and review
Monthly reports and regular reviews keep the service honest. Without them, performance can slip gradually and nobody notices until a crisis forces the question.
What a useful monthly report contains
- Tickets raised, resolved and still open, by priority.
- Performance against response and resolution targets, with every breach explained.
- Availability of critical systems, including planned and unplanned downtime.
- Trends: recurring issues, the systems generating most tickets and how this compares with previous months.
- Progress on agreed improvements and projects.
Ask for the underlying ticket data as well as the summary. Averages can hide a great deal: a service that meets its average resolution target can still leave a handful of users waiting weeks.
The review meeting
Hold a short monthly review with your supplier’s service manager, and a broader quarterly review that includes a senior sponsor from each side. The monthly session focuses on performance and open issues. The quarterly session steps back: is the service meeting the needs of the business, are the priorities still right, and what should change?
The best reviews spend less time on whether targets were met and more on why the same problems keep returning.
IT operations manager
Invite one or two business users to the quarterly review. They will tell you things a dashboard cannot: that the service desk is polite but slow to understand the warehouse, or that a particular application has become unreliable at month end. That perspective keeps the service anchored to the people it exists to support.
Getting started
If you already have an SLA, read it this week against the points in this guide. Check that it distinguishes response from resolution, that priorities reflect business impact with examples you recognise, and that the timing rules are clear. Then ask for the last three months of reports and look at the trends, not just the averages.
If you are negotiating a new contract, start from your critical systems and processes, decide what the business can tolerate when each one fails, and work back to the targets. A supplier that engages seriously with that conversation is usually a supplier worth working with.
Source: Intelliversal analysis.
