Managed IT Support
What is an IT support SLA, and what response times are reasonable?
IT support SLAs explained: response versus resolution, P1 to P4 priority examples, business hours versus 24/7, what to check in the contract and the red flags.
By Dig IT SolutionsUpdated 8 September 20267 min read
Short answer
An IT support SLA is the part of your contract committing the provider to respond to, and usually resolve, issues within set times by priority level, during defined hours, with remedies if targets are missed. Reasonable UK business-hours SLAs commonly commit an engineer to start on a whole-business outage within an hour and on single-user issues within a working day.
Every IT support provider says it is responsive. The service level agreement is where that claim becomes a commitment you can measure and, if necessary, enforce. This guide explains what an SLA contains, how priority levels work, what response times are reasonable for a UK business, what to check in the contract, and the red flags that suggest the SLA is decoration rather than substance.
What an SLA actually is
A service level agreement is the part of your support contract that defines the service in measurable terms. For IT support it normally sets out:
- Priority levels and how issues are classified into them.
- Response time per priority: how quickly an engineer starts work.
- Resolution or update commitments per priority: how quickly it is fixed, or how often you are updated until it is.
- Covered hours: when the targets apply, and what happens outside them.
- Measurement and reporting: how performance is tracked and shown to you.
- Remedies: what happens if targets are missed, such as service credits or a right to terminate.
It is a contractual document. A response time on a website or in a sales conversation is not an SLA unless it appears in the signed agreement.
Response versus resolution
The two are often confused, and the confusion favours the provider.
Response is the time from you logging an issue to an engineer beginning to work on it. Not an automated acknowledgement email, which takes zero seconds and proves nothing. A human, looking at your ticket, doing something.
Resolution is the time from logging to the issue being fixed or a workaround being in place so that work can continue.
Most providers will commit firmly to response and more loosely to resolution, and there is a fair reason: a failed server may depend on a part arriving, a line-of-business application may depend on its vendor, and the provider does not control those. A reasonable contract handles this by committing to resolution targets where the provider controls the outcome, and to regular updates at fixed intervals where it does not.
What you should not accept is a contract that only mentions response. A provider can hit every response target and still leave you broken for days.
Priority levels with examples
Most UK contracts use four priorities. The definitions matter more than the names, because the provider decides which category your ticket falls into, and a P1 that is logged as a P3 gets a P3 response.
| Priority | Definition | Typical examples | Common business-hours response target |
|---|---|---|---|
| P1 Critical | Whole business or a critical system down, no workaround | Internet or network down for the office, main server or application unavailable, email down for everyone, suspected ransomware or account compromise | Within 1 hour, often much faster in practice |
| P2 High | A team or an important function is stopped, or a critical system is degraded | A department cannot access its shared drive, the phone system is down, a key user cannot work at all, a site-to-site VPN is offline | Within 2 to 4 hours |
| P3 Medium | One person affected, or a workaround exists | A user cannot print, Outlook keeps prompting for a password, a laptop is slow, a file has been deleted and needs restoring | Within 1 working day |
| P4 Low | Requests and questions with no operational impact | New starter set-up with notice, a software question, a licence change, a request for a new mailbox | Within 2 working days |
The targets in the last column are what we commonly see in UK business-hours contracts for firms of up to 250 people. They are an illustration of the market, not a promise about any particular provider. Faster is available and costs more. The point is to check that your contract has a table like this, that the definitions are clear, and that you know who decides the priority and how to challenge it.
One useful clause: the right for you to declare a P1. If your finance director says it is critical, it is critical, and the provider should treat it as such even if the technical impact looks smaller.
Business hours versus 24/7
Two separate questions get merged here: when is the helpdesk available, and when is monitoring running?
Helpdesk hours. Most managed contracts for office-based businesses cover something like 8am to 6pm, Monday to Friday, excluding bank holidays. The SLA clock runs during those hours. A P3 logged at 5.30pm on Friday with a one-working-day target is due on Monday, not Saturday.
Monitoring. Remote monitoring tools run continuously regardless of helpdesk hours, so a server that fails at 2am raises an alert that is waiting when engineers start, or is acted on overnight if the contract includes that.
Out-of-hours support. Some providers offer 24/7 helpdesk cover as a tier, at a higher price. Others offer an emergency route outside hours at an agreed call-out rate. Either is acceptable if it is written down. What you want to avoid is assuming out-of-hours cover exists because the website mentions it, then discovering at 7pm that the phone goes to voicemail.
For most businesses that work office hours, business-hours cover with continuous monitoring and a defined emergency route is the sensible balance. If you trade in the evenings or at weekends, scope extended cover and pay for it explicitly. We do not claim 24/7 support unless it is in your contract, and you should hold every provider to the same standard.
What to check in the contract
Before you sign, read the SLA section for these items.
- A priority table with definitions, examples and targets for both response and resolution or updates.
- Covered hours stated precisely, including bank holidays.
- Clock rules. When the clock starts (ticket logged, not acknowledged), whether it pauses when the provider is waiting on you, and how out-of-hours logging is handled.
- Who sets the priority, and your right to escalate or declare a P1.
- Escalation path. Named roles, not just a general number, for when a ticket is stuck.
- How to log a ticket. Phone, email and portal, and whether a phone call is required for a P1 (it usually should be).
- Reporting. Monthly or quarterly performance against the SLA, by priority.
- Remedies. Service credits, a right to terminate after repeated failure, or at minimum a formal review trigger.
- Exclusions. Issues caused by third parties, unsupported hardware or your own changes are often excluded from targets, which is fair if it is explicit.
- Changes. Whether the provider can alter the SLA unilaterally, and how you are notified.
The wider contract questions of term, notice, exclusions and exit are covered in what to look for in an IT support contract.
Red flags
- No SLA table at all. The proposal talks about "fast response" but the contract has no numbers.
- Response only. Targets for picking up the ticket, nothing about fixing it or updating you.
- Acknowledgement counted as response. An auto-reply within five minutes that satisfies the SLA while nobody looks at the ticket.
- Website averages. "Average response 12 minutes" on the homepage, no commitment in the contract. An average across all clients is compatible with your P1 waiting hours.
- Vague priorities. No definitions, so every ticket becomes a P3.
- No reporting. If the provider does not measure it, you cannot hold them to it.
- No remedy. Targets with no consequence are aspirations.
- 24/7 in the sales deck, business hours in the contract.
If you recognise several of these in your current agreement, the signs of bad IT support may be worth reading too.
Why averages advertised on websites are not SLAs
This deserves its own section because it is the most common confusion we see when businesses compare providers.
An average response time is a description of the past. It is calculated across every ticket from every client, most of which are low-priority requests that are easy to pick up quickly. It says nothing about what the provider will do for your business, for your P1, next month. It has no definitions, no hours, no measurement you can see and no remedy.
An SLA is a promise about the future, specific to your contract, broken down by priority, with defined hours, reporting and consequences. It is the only version of "responsive" that a court, or your finance director, will recognise.
When a provider quotes an average, ask what the contract commits to for a P1, and what happens if they miss it.
What to do next
If you are choosing a provider, ask each one for their SLA table and put them side by side with the priority definitions, hours and remedies, not just the headline numbers. If you want to talk through what a sensible SLA looks like for your business, contact us and an engineer will walk you through the one we use, including what it does and does not cover.