A real IT support SLA defines both response time and resolution target for each priority level, in writing, with consequences for missing them. A typical 2026 benchmark: 15 to 30 minutes response for a critical outage, one hour for high priority, four business hours for standard requests. Most SLAs businesses actually sign define only the first number, measure it generously, and attach no consequence at all. This guide covers what to demand instead.
The industry’s favourite sleight of hand. “15-minute response” means someone acknowledges your ticket within 15 minutes. It says nothing about when the problem gets fixed. A provider can hit a 15-minute response SLA at 100 per cent while your server stays down all day, because the auto-reply counted as the response.
A genuine SLA has two numbers per priority: response (a qualified human starts working) and resolution target (when it is expected to be fixed or escalated). Resolution targets are honest ranges rather than guarantees, because nobody can promise a fix time before diagnosing a fault. But a provider that refuses to state resolution targets at all is telling you it does not measure them.
| Priority | What it covers | Response | Resolution target |
|---|---|---|---|
| P1 Critical | Whole business or site down, security incident in progress | 15-30 min, all hours | 4 hours, worked continuously |
| P2 High | Department or key system impaired, single user completely unable to work | 1 hour | 8 business hours |
| P3 Standard | Single user degraded, workaround exists | 4 business hours | 2 business days |
| P4 Request | New starter setups, changes, questions | 1 business day | Scheduled and agreed |
Two details matter more than the numbers. First, who assigns the priority: if the provider grades every ticket themselves, everything mysteriously becomes P3. The definitions should be objective enough that a ticket describing “nobody can access the file server” cannot be graded standard. Second, the clock rules: does the timer pause when the provider marks a ticket “waiting on client”? It should, but the pausing needs to be visible in your ticket portal, because it is the easiest place to hide missed targets.
Almost every provider claims 24/7 something. The claims mean wildly different things. 24/7 monitoring usually means automated alerts fire around the clock; whether anyone acts on them before 8am is a different question. 24/7 support means humans answer around the clock, sometimes at 1.5 to 2 times standard rates. The question that cuts through the marketing: “A critical system fails at 7pm Friday. Walk me through exactly what happens, minute by minute, and who is involved.” A provider with a real after-hours model answers in specifics. A provider without one answers in adjectives.
An SLA without consequences is a brochure. Reasonable teeth for a mid-market agreement: missed targets reported transparently in monthly service reports (not only when you ask), a defined escalation path to a named senior person after repeated breaches, and service credits or termination rights if performance stays below target for consecutive quarters. We would rather be measured than trusted on faith, which is why the reporting matters more than the credits: providers that publish their numbers every month rarely need the penalty clause.
Also check what is being measured. An SLA met 95 per cent of the time sounds strong until you learn the 5 per cent were all P1s. Ask for SLA performance split by priority.
Here is the part most SLA discussions skip: response times are an output of how the provider is built, not a number they choose. Fast response comes from proper dispatch and triage, enough engineers per client, documentation that lets any engineer pick up your environment, and increasingly, AI-assisted triage that routes and enriches tickets before a human touches them. We run AI across our own service desk for exactly this reason, and it is a large part of how response times hold during Monday-morning surges rather than only on quiet Wednesdays. When you evaluate a provider, ask how their desk actually works. The SLA number is downstream of the answer.
SLA terms sit inside the broader agreement scope, which we covered in what managed IT support actually includes, and the price attached to different service levels is in our 2026 IT support cost guide.
Find your current SLA and check it for the two-number test. If it defines response but not resolution targets, or has no priority matrix at all, you have a marketing document, not a service level agreement.
Ask your provider for last quarter’s SLA performance, split by priority. A provider measuring properly produces it within days. If the report does not exist, neither does the SLA in any meaningful sense.
Benchmark against a published standard. Our managed IT support agreements put the full priority matrix in writing, and our free IT assessment includes a review of your current agreement’s SLA terms. Contact us on 1300 EPIC IT to book one.
In 2026, a good IT support SLA commits to 15 to 30 minutes response for critical outages, one hour for high-priority issues, and around four business hours for standard requests. Response time alone is not enough: a genuine SLA also states resolution targets per priority and reports performance against both.
Response time is when a qualified person starts working on your ticket. Resolution time is when the problem is actually fixed. Many providers advertise only response time because it is easy to hit, sometimes with an automated acknowledgement. Always ask for both numbers for each priority level.
Not necessarily. 24/7 monitoring usually means automated systems generate alerts around the clock, while human response may only run during business hours or at after-hours rates. Ask the provider to walk you through exactly what happens when a critical system fails at 7pm on a Friday, step by step, and who is involved.
At minimum, misses should be reported transparently in monthly service reports without you having to ask, with an escalation path to a named senior person for repeated breaches. Stronger agreements add service credits or termination rights for sustained underperformance. An SLA with no consequences and no reporting is a marketing document.
The SLA should define priorities objectively by business impact, so a whole-site outage cannot be graded as standard. If the provider assigns priorities with no defined criteria, tickets tend to drift to lower priorities where the SLA is easier to meet. Check that priority definitions are written into the agreement and that you can dispute a grading.
