What a Good IT SLA Actually Looks Like

Response time and resolution time are two different promises

The most common mistake buyers make when reading a service level agreement is treating "response" and "resolution" as the same commitment. They are not, and the gap between them is where most disputes live.

• Response time is how fast a human acknowledges your ticket and starts working it. A one-hour response SLA means someone owns the problem within an hour — not that anyone has looked at your environment before then.
• Resolution time (sometimes "time to restore") is how fast service is brought back to a working state. This is the number that maps to business impact, and it is the one vague SLAs quietly omit.

A good SLA commits to both, per severity level. An SLA that only promises fast response is committing to answering the phone quickly, not to fixing anything. Ask directly: what is the target time to restore service for a total outage, and is that a target you measure or a target you are contractually bound to?

One more distinction worth pinning down: is resolution measured in clock time or in "SLA time" that pauses while the ticket is with you, a vendor, or waiting on a change window? Both are legitimate, but they produce very different real-world numbers. The contract should say which one it uses.

The priority matrix is the heart of the agreement

Every serious SLA is built on a priority (or severity) matrix. Priority is derived from two inputs: impact (how much of the business is affected) and urgency (how fast it degrades). A single user with a slow printer and a site-wide email outage cannot share the same clock.

A workable four-tier matrix looks like this:

• P1 — Critical. A core system is down or a whole site cannot work. Example: email, ERP, or the primary line-of-business application is unavailable. Response in 15 minutes; active, continuous work until restored.
• P2 — High. Significant degradation or a single critical user blocked, with a workaround that is painful or absent. Response within 30 to 60 minutes.
• P3 — Medium. A single user or non-critical function affected, workaround available. Response within 4 business hours.
• P4 — Low. Requests, questions, and scheduled changes. Response within one business day.

The exact minutes matter less than three things: the tiers are defined by business impact rather than by who is shouting loudest, the definitions are specific enough that both sides classify a ticket the same way, and you — not only the provider — can trigger a priority. Watch for contracts where the provider is the sole judge of severity. That is how a P1 becomes a P3 on paper.

Prioritization only works if the front door is staffed to act on it. That is a function of the managed helpdesk and support layer: triage, classification, and ownership from the first minute.

Coverage: business hours versus 24x7

An SLA number is meaningless without the hours it applies to. "One-hour response" during 8x5 business hours is a very different product from one-hour response 24x7x365. Nail down:

• Coverage window. 8x5, 12x5, or 24x7. If it is business hours, whose time zone, and what happens to a P1 that starts at 6 p.m. Friday?
• After-hours path. Is there a staffed on-call rotation, or does the ticket simply queue until morning? A real 24x7 commitment means a person, not a voicemail box and a promise.
• Holidays. Explicitly listed, or a source of surprise.

Most mid-market organizations do not need 24x7 for every ticket, but they do need it for P1 and P2 — an outage does not respect the calendar. A sensible structure is 24x7 for critical incidents and business-hours coverage for routine requests, which is exactly how a well-run complete IT support program is usually scoped.

Uptime: what a "nine" actually costs

Uptime percentages sound interchangeable until you convert them to downtime. Each additional nine is roughly an order of magnitude harder and more expensive to deliver:

• 99% ("two nines") allows about 3.65 days of downtime per year — roughly 7.2 hours a month. Fine for a test system, unacceptable for production.
• 99.9% ("three nines") allows about 8.77 hours per year, or roughly 43 minutes a month. This is the practical default for most business systems.
• 99.99% ("four nines") allows about 52 minutes per year — under 4.4 minutes a month. This requires redundancy, automated failover, and tested runbooks.
• 99.999% ("five nines") allows about 5 minutes per year. It demands fully redundant, geographically distributed architecture and a serious budget.

The point is not to chase the most nines. It is to match the number to what the system actually justifies and to read the fine print underneath it. A 99.99% figure attached to a single server with no failover is marketing. The honest question is: what is this percentage measured against — the network, a specific application, the data center — and what architecture makes it true? Higher availability is an engineering investment (redundant links, clustering, standby capacity), and the business continuity design behind it is what turns a promised number into a real one.

Credits, exclusions, and the fine print

Service credits are the remedy when the SLA is missed — usually a percentage of the monthly fee. They are worth having, but keep them in perspective: a credit of a few percent of one month's invoice does not come close to covering the cost of a day-long outage. Credits are an accountability signal, not compensation. Look for whether credits are automatic or require you to file a claim within a short window; "you must request the credit within five business days" clauses exist specifically so most credits are never paid.

Exclusions are where obligations quietly disappear. Common and often reasonable ones include scheduled maintenance windows, force majeure, and issues caused by third-party providers or by the customer's own changes. The problems start when exclusions are broad enough to swallow the commitment — for example, excluding any downtime "caused by third-party software" in an environment that is entirely third-party software. Read exclusions as carefully as the targets, and confirm how much maintenance-window downtime is permitted and how much notice you get before one.

Reporting and CSAT: the proof the SLA is real

An SLA you cannot see is a promise you cannot enforce. The reporting layer is what converts the contract into something measurable:

• SLA attainment reports — percentage of tickets that met response and resolution targets, by priority, each month. This is the headline metric.
• Ticket volume and trends — what is breaking, how often, and whether it is improving. Rising P1 counts are a signal, not just noise.
• Uptime reports — actual availability against the committed number, per system, with incident detail for any misses.
• CSAT — customer satisfaction scored per ticket. Attainment can be green while users are miserable; CSAT catches the gap between "closed on time" and "actually helped."

Insist on a recurring service review — monthly or quarterly — where these numbers are walked through and misses are explained. A provider that reports against its own SLA and shows up to discuss the misses is behaving like a partner. One that cannot produce the numbers is telling you the SLA was never operational.

Red flags in a vague SLA

Quick tells that an SLA is thinner than it looks:

• Response times promised, but no resolution or time-to-restore targets.
• A single blended uptime figure with no definition of what it measures.
• Priority levels the provider assigns unilaterally, with no customer trigger.
• "Best effort," "commercially reasonable," or "as soon as possible" standing in for numbers.
• No coverage hours stated, or 24x7 claimed with no staffed on-call path.
• Credits that require a claim within an impractically short window.
• No standard reporting and no scheduled service review.

The bottom line

A good IT SLA is specific and testable: distinct response and resolution targets, a priority matrix defined by business impact, clear coverage hours, an uptime number matched to a real architecture, honest credits and exclusions, and monthly reporting with CSAT that proves the whole thing is operating. Anything vaguer is asking you to trust a promise you cannot measure.

If you want your support measured against commitments like these — and reported on every month — talk to intSignal. We run complete IT support to defined SLAs so reliability is a number you can see, not a hope you are carrying.