What is an SLA in IT support, and why most of them fail

An SLA, or service level agreement, is the agreed time to respond to and resolve a request, set by priority and by business impact. An SLA the team cannot meet is worse than no SLA: it produces tidy reports, broken expectations and a monthly argument about the number rather than about the service.

Most IT teams have lived some version of this story. Someone decides that “every ticket must be resolved within four hours”. The target goes into a board presentation, and three months later compliance sits at 60% and nobody trusts the figure. The team is rarely the problem. The way the SLA was designed usually is.

This article explains what an SLA covers in IT support, why response and resolution need separate targets, how to set priority from impact instead of from whoever shouts loudest, the three reasons SLAs turn into fiction, and how to measure compliance without turning it into a hunt for culprits.

A quick note on terms. Strictly speaking, the service level agreement is the document agreed between IT and the business (or between a provider and its customer). The targets inside it, such as “first response within 30 minutes for high priority”, are service level targets. In day-to-day IT support, people say “SLA” for both, and that is how we use it here.

Response time and resolution time are different targets

An SLA in IT support almost always contains two clocks, and mixing them up is the first source of confusion.

• Response time measures how long it takes for a person on the support team to make first contact with the user. An automatic “we received your ticket” email does not count. The point of the response target is that the user knows a human has seen the problem and is working on it.
• Resolution time measures how long it takes until the ticket is closed with the service restored or the request fulfilled.

A ticket can be answered in ten minutes and still take two days to resolve. Both facts matter, and they tell you different things. A slipping response time usually points to a queue or staffing problem: tickets sit unassigned. A slipping resolution time usually points to a knowledge, process or supplier problem: tickets are picked up but get stuck.

That is why each needs its own target and its own report. A single “time to close” figure hides where the delay actually happens.

It also helps to separate incidents from service requests. An incident is something broken: the VPN drops, the ERP is down. A service request is something asked for: a new account, access to a folder, a laptop for a new hire. Requests are predictable, so their targets are usually set per item in the service catalogue rather than in the incident priority matrix.

Priority is not urgency: the impact matrix

The most common mistake in prioritisation is letting the requester decide. When the form has a “priority” field, nearly everyone picks “high”, because to the person raising the ticket the problem always feels urgent. The queue fills with high priorities, and priority stops meaning anything.

The alternative is to calculate priority by combining two objective criteria:

• Impact: how many people, processes or customers stop working. A faulty laptop affects one person; an ERP outage affects the whole company.
• Urgency: how long until the problem becomes critical. A printer down during payroll close is more urgent than the same printer down on a quiet Friday afternoon.

The requester can state urgency, because they know their own deadline. Impact is set by the service desk, using published criteria. Priority comes from the combination:

Impact Urgency	High	Medium	Low
High (company, customer or critical process stopped)	P1	P2	P3
Medium (one department or team affected)	P2	P3	P4
Low (one person, with a workaround)	P3	P4	P4

Each priority then gets its own response and resolution target. The figures below are a common starting point for mid-sized IT teams. Treat them as suggestions and adjust them to your real capacity before publishing anything.

Priority	Example	Response time	Resolution time	Clock
P1 – Critical	ERP down, branch network offline	15 minutes	4 hours	24/7, if there is on-call cover
P2 – High	Email down for a whole department	30 minutes	8 business hours	Business hours
P3 – Medium	Department printer down, workaround available	2 business hours	2 business days	Business hours
P4 – Low	How-to question, minor configuration change	4 business hours	5 business days	Business hours

The value of the matrix is that it takes the debate out of the realm of opinion. If a ticket was classified P3, anyone can see why: medium impact, medium urgency. If someone disagrees, they argue about the criteria, not about the technician’s mood.

Write down what “critical process” means in your organisation. For a manufacturer it may be the production line; for a retailer, the point of sale; for an accounting firm, the tax system at month end. Without that list, impact drifts back into opinion.

To build your own version: pull three to six months of ticket history, see how long each priority band actually took, set the first targets slightly above that baseline, agree them with the business, and review them every quarter as volume and staffing change.

Three reasons SLAs become fiction

1. The target comes from ambition, not capacity. Management wants “everything in four hours”, but the team has three technicians for 600 tickets a month. The maths does not work, and everyone knows it from day one. A credible SLA starts from volume and capacity data. If the desired target is different, the conversation becomes one about resources, not about effort.

2. The clock never pauses. A ticket waiting on the user’s reply, a supplier’s spare part or a third-party site visit is not in the team’s hands. If the clock keeps running, the metric measures the supplier’s patience, not IT’s performance. The rule needs to be explicit: statuses such as “waiting for user” and “waiting for supplier” pause the SLA. Work that depends on third parties only carries an SLA when the supplier contract includes a compatible commitment.

3. The requester chooses the priority. As described above, if users set priority, everything becomes P1. Technicians learn to ignore the field, genuinely critical tickets get lost in the queue, and the P1 target becomes the most breached line in the report.

There is a quieter fourth failure: measuring the SLA and doing nothing with the result. A report nobody reads does not improve the service. Each breach is a data point about capacity, process or suppliers, and it should feed a decision.

Measuring without turning it into a witch hunt

An SLA is a tool for managing the service, not for grading individuals. Once it turns into a technician league table, the team quickly learns to protect the number: tickets are closed early, priorities are quietly downgraded, one problem is split into several tickets. The metric improves and the service gets worse.

A few practices keep the focus where it belongs:

• Measure by queue and service, not by person. The question is “where does the process get stuck?”, not “who failed?”.
• Watch the trend, not the single month. One bad month may have a one-off cause. Three months of decline point to a capacity or process problem.
• Classify every breach by cause. Understaffing, supplier dependency, missing knowledge, wrong classification. Each cause calls for a different fix.
• Track reopened tickets. High resolution compliance with many reopened tickets means problems are being closed, not solved.
• Publish the rules. When everyone knows how priority is set and when the clock pauses, the number stops being a source of suspicion.

It also helps to agree on a simple monthly routine: thirty minutes to review the period’s breaches, group them by cause and decide on one or two concrete actions. That might be a new knowledge base article, a conversation with a supplier, an adjustment to the matrix or a request for more staff. That loop, not the percentage itself, is what turns an SLA into continuous improvement.

So what is a good compliance rate? Stability and auditability matter more than the number itself. A 90% rate that holds month after month and can be checked ticket by ticket is worth more than 99% that nobody can explain. In best-practice terms, service level management is a practice in ITIL 4, and ISO/IEC 20000-1 requires service levels to be agreed, documented, monitored and reviewed.

None of this survives long in a spreadsheet. For an SLA to be trusted, the tool has to calculate targets by priority and calendar, pause the clock in the right statuses, warn before a deadline is missed, and produce reports anyone can audit. OTRS handles this natively, with escalations and calendars per queue, and Aufiero helps IT teams across Latin America and the US with licensing and rollout. Learn more on the OTRS page.

FAQ