Every IT company’s website promises rapid response times, and if you’re comparing providers you’ve probably noticed the numbers are suspiciously similar — and suspiciously impressive. Here’s the thing those headline figures don’t tell you: a 15-minute response commitment can coexist perfectly legally with your problem taking three days to fix. Understanding why is the difference between buying a service level and buying a sentence.
This guide decodes the terms, sets out the benchmarks Indigo IT considers reasonable for a 20–250 person business, and gives you the questions that separate a real service commitment from marketing.
Response is not resolution — and the gap is where service lives
Response time is how quickly the provider acknowledges your ticket and a human starts dealing with it. Resolution time is how long until the problem is actually fixed. Most SLAs commit firmly to the first and loosely (or not at all) to the second — partly for a legitimate reason: nobody can honestly promise to fix an unknown problem in a fixed time. A failed server part might need a supplier; a corrupted database might need hours of careful recovery.
So the mark of a serious provider isn’t a resolution guarantee — it’s transparency about resolution: published averages, live ticket visibility, and escalation commitments when something drags. If a provider commits only to responding and then goes quiet on everything after, the SLA is telling you where their effort stops.
Priority levels: the small print that decides everything
SLA targets are always tiered by priority, and the definitions matter more than the numbers. A typical structure for an SME contract looks like this:
- P1 — Critical — Whole business or a whole site down — email out, network down, ransomware suspected. Expect response within 15–30 minutes during business hours, all hands until restored, and a named escalation path.
- P2 — High — A team or key system badly degraded — the finance system crawling, a department without phones. Response within an hour or so; active work the same day.
- P3 — Standard — One person impaired but able to work — a misbehaving laptop, a printer issue, a software fault with a workaround. Response within 2–4 hours; resolution typically within a couple of business days.
- P4 — Request — Requests and changes — a new starter, extra software, a permission change. Scheduled rather than reactive; a good provider gives lead times for these too, because ‘new starter set up on day one’ matters as much as any outage.
Now the question that exposes weak SLAs: who decides the priority? If the provider classifies every ticket, your business-down emergency can become their P3. Look for definitions written in business terms — number of people affected, revenue impact — not technical ones, and for your right to say “this is critical” and be believed. It’s how Indigo IT structures priority with clients: the definitions are agreed in plain English at onboarding, so nobody is negotiating severity in the middle of an outage.
The clauses to read twice
- Coverage hours — ‘Business hours’ — whose? 8am–6pm weekdays is common; check it matches when your business actually operates, and what out-of-hours cover costs before you need it.
- Measurement — ‘Best efforts’ or ‘target’ response times — targets without measurement are decoration. Ask how performance is reported to you, and how often. If the answer isn’t ‘you’ll see the numbers in every service review’, assume nobody is counting.
- Remedies — Service credits — most SME contracts offer none, and honestly, credits are a weak remedy anyway: a few pounds back doesn’t compensate for a lost day. The better protections are a short notice period and no long lock-in — a provider confident in its service doesn’t need to imprison its clients.
- Exclusions — Exclusions — third-party software, ‘acts of vendors’, problems on unmanaged devices. Reasonable in principle; just make sure the exclusions don’t quietly cover half your estate.
What to actually judge a provider on
After years of running a helpdesk for SMEs across Surrey, Hampshire and Berkshire, Indigo IT’s honest view is that the SLA table is the least useful page of most contracts. The numbers that predict your experience are operational: average time to resolution (not just response), first-contact fix rate, ticket volume per client trending down over time (evidence of prevention, not just reaction), and client satisfaction scores gathered per-ticket rather than per-year. Any provider genuinely proud of its service can show you these for the last quarter. Ask. The reaction to the question is itself the answer.
Frequently asked questions
What’s a reasonable response time for a critical issue?
15–30 minutes within business hours is a fair expectation for a P1 at SME scale, with work beginning immediately on response — not merely an acknowledgement email. Faster headline numbers exist; verify they mean a human engaging, not an auto-reply.
Should we push for resolution-time guarantees?
Push instead for resolution transparency: published averages, escalation triggers (for example, automatic escalation to a senior engineer after a set time), and your visibility of open tickets. A provider who offers hard resolution guarantees on unknown faults is telling you the guarantee is unenforceable.
Do SLAs apply to new-starter setups and routine requests?
They should — request-class work is where slow providers quietly fail, and it’s highly visible to your staff. Agree lead times for the common requests (starters, leavers, new equipment) alongside the fault-response targets.
