What is the difference between response time and resolution time in an SLA?

Response time is how long it takes for a qualified person to acknowledge and begin working on a ticket. Resolution time is how long it takes to fix the issue or provide a workaround. An SLA should state both separately, since they depend on different factors and conflating them creates unrealistic expectations.

How many priority levels should an IT service desk SLA have?

Four levels, typically critical, high, medium and low, is usually enough to be useful without becoming difficult to apply consistently. Each level needs concrete impact and urgency criteria rather than being left to subjective judgement at the point a ticket is logged.

What should an IT service desk SLA exclude?

Common exclusions include outages caused by third-party services or ISPs outside the desk's control, delays caused by the client not providing required access or approval, pre-agreed scheduled maintenance windows, and force majeure events. These should be named specifically rather than left as a vague catch-all.

Does an SLA need to cover out-of-hours support?

It needs to state clearly whether out-of-hours coverage exists, what it covers if so, and what happens to tickets raised outside standard business hours if it does not. Leaving this unstated is one of the most common sources of dispute between clients and service desks.

How often should SLA performance be reported?

Monthly reporting is typical, covering ticket volume by priority, actual performance against response and resolution targets, and documented reasons for any breaches. Reporting should be reviewed with the client, not just filed.

Should SLA targets ever change after the agreement is signed?

Targets should be reviewed periodically against actual reported performance. If a target is being missed consistently, that points to either an unrealistic target or a resourcing gap, and both are better addressed through a review than by letting the same breach repeat every month.

What is a reasonable resolution target for a critical incident?

This varies by organisation and sector, but a resolution or documented workaround within a small number of hours, alongside a response target of 15 to 30 minutes, is a common baseline for a genuinely critical, organisation-wide issue.

Vendor-neutral guide · 9 min read

An IT service desk SLA template: priorities, targets and exclusions

Name: 247connect
Brand: 247connect

Written by the 247connect Marketing Team

Shape of the topic

Write it down, work the list, review it: a policy is only useful once it becomes a repeatable checklist.

In short

A service level agreement that only states a single response time is not really an SLA, it is a slogan. A working SLA defines how priority is assessed, sets separate targets for response and resolution, states the hours it applies during, lists what is excluded, and commits to regular reporting against the targets it sets. This template sets out each of those sections, so an IT manager or service desk lead can adapt it rather than negotiating one from a blank page.

Key takeaways

A usable SLA needs a defined priority matrix based on impact and urgency, not a single generic response time for every ticket.
Response and resolution targets are different commitments and should never be stated as if they were the same thing.
Business hours coverage needs to be explicit, including what happens outside them, since silence on this point causes the most disputes.
Exclusions protect both sides by stating upfront what the SLA does not cover, such as third-party outages or client-caused delays.
Regular reporting against the SLA is what turns it from a contractual document into an operating discipline.
SLA targets should be reviewed periodically against actual performance, not fixed permanently at the point of signing.

The priority matrix: impact and urgency

Every ticket needs a priority, and that priority should come from a matrix combining impact, how many people or which systems are affected, with urgency, how quickly the situation is getting worse or how time-critical it is. A single user unable to print is different from an entire site losing network connectivity, and the SLA needs to say so explicitly rather than leaving priority to the judgement of whoever picks up the ticket.

A simple four-level matrix, critical, high, medium and low, mapped against a small number of impact and urgency bands, is usually enough. The definitions need to be concrete: 'critical' should name the conditions that qualify, such as a full site outage or a security incident in progress, rather than being left as a subjective label applied inconsistently between engineers.

Critical: full site or organisation-wide outage, security incident in progress, safety-critical system down
High: a business-critical system down for a single team or department, no workaround available
Medium: a single user or non-critical system affected, workaround available
Low: cosmetic issues, requests for information, minor inconvenience with no operational impact

Response versus resolution targets

Response time is how long it takes for a qualified person to acknowledge the ticket and begin working on it. Resolution time is how long it takes to actually fix the problem or provide a workaround. These are different commitments with different drivers, response time depends mostly on service desk staffing and triage, resolution time depends on the complexity of the fault, and an SLA that conflates them sets an expectation it cannot reliably meet.

Targets should scale with priority: a critical incident might carry a 15-minute response target and a four-hour resolution target, while a low-priority request might have a same-day response and a five-day resolution target. These numbers should be set based on what the desk can genuinely sustain, since a target missed routinely does more damage to trust than a slightly less ambitious one that is consistently met.

Critical: response within 15 to 30 minutes, resolution or workaround within a small number of hours
High: response within one hour, resolution target measured in hours, not days
Medium: response within four business hours, resolution within one to two business days
Low: response within one business day, resolution within three to five business days

Business hours and out-of-hours coverage

The SLA needs to state, without ambiguity, the hours during which targets apply, for example 8am to 6pm, Monday to Friday, excluding public holidays, and what happens to a ticket raised outside those hours. Does the clock start when the desk reopens, or is there an out-of-hours service with its own, typically reduced, coverage for critical issues only?

This is one of the most common sources of dispute in practice, a client raising a critical ticket at 9pm assumes urgency, while the SLA may only guarantee response from 8am the next morning unless an out-of-hours arrangement is separately purchased. Stating this plainly, and pricing out-of-hours coverage as an explicit option if it is not included by default, avoids the disagreement entirely.

Exclusions

An SLA needs to state what it does not cover, protecting both parties from disputes over delays that were never within the service desk's control. Common exclusions include outages caused by third-party services or internet providers outside the desk's management, delays caused by the client failing to provide access, information or approval needed to proceed, and scheduled maintenance windows agreed in advance.

Exclusions should be specific rather than a vague catch-all, since a broadly worded exclusion clause tends to be read by the client as evasive and undermines confidence in the rest of the agreement. Naming the actual categories, third-party outages, client-caused delay, force majeure, pre-agreed maintenance, is both fairer and more credible.

Outages caused by third-party services, ISPs or software vendors outside the desk's control
Delays caused by the client not providing required access, information or approval
Scheduled maintenance windows communicated in advance
Force majeure events affecting either party's ability to deliver

Reporting

An SLA without regular reporting against it is a document nobody checks until there is a dispute. Reporting should show ticket volume by priority, actual response and resolution times against target, and a breakdown of any breaches with the reason recorded. This should be produced on a fixed schedule, monthly is typical, and reviewed with the client rather than simply filed.

Where reporting shows targets are consistently missed for a particular priority level, that is a signal to review either the target itself or the resourcing behind it, rather than letting the same breach repeat every reporting period. Where a platform supports unlimited operators and fixed pricing, such as 247connect, scaling desk capacity to meet SLA targets does not carry the same cost pressure that per-seat licensing can create.

Best-practice checklist

1. Define the priority matrix
Set concrete impact and urgency criteria for each priority level, avoiding subjective labels.
2. Set separate response and resolution targets
State both clearly for each priority, and make sure the desk can sustain them.
3. State business hours explicitly
Define coverage hours and what happens to tickets raised outside them.
4. Decide out-of-hours coverage
State whether it is included, excluded, or available as a separate paid option, and what it covers.
5. List exclusions by name
Name specific categories such as third-party outages, client-caused delay and scheduled maintenance.
6. Agree a reporting schedule
Commit to a fixed cadence, typically monthly, showing performance against every target.
7. Review targets periodically
Check reported performance against targets and adjust either resourcing or targets if they are consistently missed.
8. Define escalation for missed targets
State what happens, and who is notified, when a target is breached.

Common pitfalls

Setting a single response time for all tickets regardless of priority or impact
Confusing response time with resolution time in the wording of the agreement
Leaving out-of-hours coverage unstated, causing disputes the first time a critical issue is raised late at night
Writing exclusions as a vague catch-all rather than naming specific categories
Producing no regular reporting, so breaches are only discovered when the client complains
Setting targets the desk cannot sustain, damaging trust every time they are missed

What to measure

Metrics for IT service desk SLA template

Response time met by priority level	Target 95%+ per priority, tracked monthly
Resolution time met by priority level	Target 90%+ per priority, tracked monthly
Tickets correctly prioritised at logging	Track re-prioritisation rate as a quality signal
SLA breaches with recorded root cause	Target 100% of breaches documented
Monthly SLA report delivered on schedule	Target 100%

Select any column heading to sort.

Frequently asked questions

What is the difference between response time and resolution time in an SLA?: Response time is how long it takes for a qualified person to acknowledge and begin working on a ticket. Resolution time is how long it takes to fix the issue or provide a workaround. An SLA should state both separately, since they depend on different factors and conflating them creates unrealistic expectations.
How many priority levels should an IT service desk SLA have?: Four levels, typically critical, high, medium and low, is usually enough to be useful without becoming difficult to apply consistently. Each level needs concrete impact and urgency criteria rather than being left to subjective judgement at the point a ticket is logged.
What should an IT service desk SLA exclude?: Common exclusions include outages caused by third-party services or ISPs outside the desk's control, delays caused by the client not providing required access or approval, pre-agreed scheduled maintenance windows, and force majeure events. These should be named specifically rather than left as a vague catch-all.
Does an SLA need to cover out-of-hours support?: It needs to state clearly whether out-of-hours coverage exists, what it covers if so, and what happens to tickets raised outside standard business hours if it does not. Leaving this unstated is one of the most common sources of dispute between clients and service desks.
How often should SLA performance be reported?: Monthly reporting is typical, covering ticket volume by priority, actual performance against response and resolution targets, and documented reasons for any breaches. Reporting should be reviewed with the client, not just filed.
Should SLA targets ever change after the agreement is signed?: Targets should be reviewed periodically against actual reported performance. If a target is being missed consistently, that points to either an unrealistic target or a resourcing gap, and both are better addressed through a review than by letting the same breach repeat every month.
What is a reasonable resolution target for a critical incident?: This varies by organisation and sector, but a resolution or documented workaround within a small number of hours, alongside a response target of 15 to 30 minutes, is a common baseline for a genuinely critical, organisation-wide issue.

Sources

Independent, standards-body and peer-reviewed material. None of these sources is affiliated with 247connect.

ITIL 4: Incident Management Practice
AXELOS / ITIL
Framework reference for priority classification based on impact and urgency.
10 Steps to Cyber Security
NCSC
Guidance on incident management planning relevant to setting realistic response and resolution targets.
Guide for Cybersecurity Event Recovery (SP 800-184)
NIST
Background on structuring recovery timelines and priorities relevant to resolution target-setting.

Putting it into practice

This guide is deliberately product-neutral. If you want to see how one implementation handles these requirements — attended and unattended access, named operator accounts, AES-256 encryption, audit logs and fixed pricing — the reference pages on this hub document 247connect in detail, and the product itself lives at 247connect.cloud.

What is 247connect?See a worked example