How to read an IT support SLA (and the tricks hiding in the small print)

Every IT support contract comes with an SLA, and almost every buyer reads it the same way: find the response time, nod at the number, move on. Which is exactly what the SLA was written for. The number in bold is rarely the part that decides what your Tuesday looks like when the server dies.

Target or average? The distinction that decides everything

“We respond within 2 hours” can mean two very different things. As a target, it means they aim for it, hit it when things are quiet, and miss it when they are busy, which is precisely when you need them. As a measured average, it means someone counted, across every ticket including the bad days.

A target is a hope with a number attached. An average is evidence.

Ask for last month’s actual average response time across all tickets. A provider measuring this can answer in one email. A provider who cannot, or will not, has answered a different question just as clearly.

Response is not resolution

First response is when a human engages with your ticket. Resolution is when the problem is gone. An SLA that only commits to response can be met by an email saying “we’ve logged your ticket” while the actual fix takes three days.

You want both numbers: average first response and average resolution time. And you want to know who responds, because a 10-minute response from a first-line agent who cannot fix anything is slower, in real terms, than a 30-minute response from the engineer who can. (We wrote more about that filter in the signs your provider is coasting.)

The “critical issues only” trick

Read what the SLA actually covers. A common structure commits to fast response for “P1/critical” incidents only, then defines critical so narrowly (total outage, all users, confirmed by them) that almost nothing qualifies. Your finance system being down is your emergency; in a badly written SLA it can be a “P3, next business day”.

What happens when they miss it?

An SLA with no consequences is a brochure. Look for a clause that says what happens on a miss: service credits, escalation, reporting of every breach, or in the best case an exit route. Then look for the quiet get-outs that neutralise it: exclusions for “periods of high demand”, for third-party faults, for anything raised outside a narrowly defined channel.

The other consequence that matters is contractual. If performance collapses, how long are you trapped? A provider confident in their numbers does not need a three-year lock-in to keep you. We run a 60-day exit clause in every contract for exactly this reason: the SLA keeps us honest because leaving is easy.

Reporting: the part that makes the rest real

Every commitment above is only verifiable if you see the data. A provider should send a monthly report with tickets raised, average first response, average resolution, and SLA compliance rate, without being asked. If reporting is an add-on, on-request, or a satisfaction survey with no numbers, then the SLA is unfalsifiable, and an unfalsifiable SLA is not a commitment.

The honest summary

Four questions expose almost any weak SLA: What was your measured average response last month, across all tickets? What is your average resolution time? What exactly does the SLA cover, and who defines priority? And what happens when you miss it? Good providers enjoy answering these. The other kind change the subject to their account management structure.