Every managed IT service level agreement contains two numbers that look almost identical and behave nothing alike. One measures how quickly somebody acknowledges that your system is broken. The other measures how quickly that system actually starts working again. Providers quote both in the same sentence, and buyers routinely assume the first one implies the second.

It does not. A managed IT service level agreement can promise a fifteen-minute response and still leave a critical server offline for three working days without breaching a single clause. That gap between acknowledgement and restoration is where most support disputes begin, and it is almost always visible in the contract before anyone signs it.

This guide separates the two clocks properly. It covers how each one is measured, when each one starts and stops, how priority tiers multiply both, what the word “resolution” legally means, and which exclusions quietly suspend the whole arrangement. If you are comparing managed IT services providers, these are the clauses that decide what you actually receive.

Table of contents

What Your Managed IT Service Level Agreement Actually Promises

managed it service level agreement response vs resolution b split dial clock

A managed IT service level agreement is a contractual schedule of measurable commitments, not a statement of intent. It defines what is covered, how performance is measured, and what happens when the provider misses a target. Everything else in the document is context.

Two clocks, not one

The two headline metrics run independently. Response time is a communication commitment. Resolution time is an outcome commitment. A managed IT service level agreement that specifies only the first has committed the provider to answering the phone quickly and to nothing else. The distinction sounds pedantic until an outage runs into a second day.

Why buyers conflate the two numbers

Sales material compresses both into a single reassuring figure. A quoted “one-hour SLA” almost always refers to response, because response is cheap to guarantee and entirely within the provider’s control. Resolution depends on the fault, the vendor, the hardware lead time and sometimes on you. Providers price that uncertainty by declining to guarantee it.

The contractual language that matters

Look for the verbs. “Respond within”, “acknowledge within” and “make contact within” are response commitments. “Restore service within”, “resolve within” and “return to operational state within” are resolution commitments. A strong managed IT service level agreement uses both sets of language and attaches a consequence to each. A weak one uses the first set exclusively.

Response Time vs Resolution Time: The Core Difference

managed it service level agreement response vs resolution c priority tier stack

Understanding the difference is the single highest-value thing you can do before signing a managed IT service level agreement. The two metrics answer different questions and protect against different risks.

Response time measures acknowledgement

Response time is the interval between a ticket being raised and a qualified person confirming ownership of it. In most agreements the confirmation must be human and must be substantive, though weaker contracts allow an automated ticket receipt to stop the clock. Response time tells you how attentive a provider is. It tells you nothing about competence.

Resolution time measures restoration

Resolution time is the interval between the ticket being raised and normal service being restored. It is the number that maps to business impact, because it corresponds to the period during which staff cannot work. This is the commitment that costs a provider real money, which is precisely why it appears less often and carries more conditions.

A worked example

Consider a finance system failing at 09:00 on a month-end Monday. A one-hour response means an engineer confirms ownership by 10:00. Without a resolution target, that engineer may still be investigating on Wednesday afternoon while remaining fully compliant. With an eight-hour P1 resolution target, the provider is in breach at 17:00 on Monday and owes you something.

How Response Time Is Measured in Practice

managed it service level agreement response vs resolution d paused hourglass

In a managed IT service level agreement the measurement rules matter more than the headline number, because they determine when the clock is running and what stops it.

When the clock starts

Most managed IT service level agreements start the clock when a ticket is logged through an approved channel — a portal, a dedicated address or a support line. Tickets raised outside those channels frequently do not start any clock at all. A message to an engineer’s mobile or a comment in a chat thread is usually invisible to the contract, however reasonable it feels at the time.

What counts as a response

The strongest definition requires a named engineer to contact you with an initial assessment. A moderate definition requires human contact acknowledging the issue. The weakest definition accepts an automated confirmation email, which makes the metric meaningless because it measures nothing but server uptime on the ticketing platform. Check which definition your managed IT service level agreement uses.

Where response-time metrics mislead

Providers report response performance because it is easy to hit and flattering to publish. A dashboard showing 99.4% response compliance can coexist with a support experience that everybody involved considers poor. Response compliance measures the first sixty seconds of a ticket. It does not measure the next sixty hours.

How Resolution Time Is Measured — And Why It Is Often Missing

managed it service level agreement response vs resolution e shield with gap

Resolution commitments are the genuine differentiator between managed IT service level agreements. They are also the clauses most likely to be softened, qualified or omitted.

Target versus guarantee

Read whether resolution figures are described as “targets”, “objectives” or “guarantees”. A target creates no enforceable obligation and no service credit. Many buyers believe they hold a resolution guarantee when the schedule actually reads “resolution target”. A managed IT service level agreement with targets rather than guarantees is a statement of ambition.

The workaround loophole

Most managed IT service level agreements permit a workaround to stop the resolution clock. If a failed printer is worked around by redirecting jobs to another floor, the incident may be marked resolved while the original fault persists for weeks. Workarounds are legitimate and often sensible, but the contract should require the provider to continue toward a permanent fix under a separate, stated timescale.

Clock-stopping and pending states

Every managed IT service level agreement lets the provider pause the clock while waiting on you. That is fair. The risk is scope: some contracts pause for any third-party dependency, any information request, or any period outside covered hours. Stacked together, these can convert an eight-hour resolution target into several calendar days without any breach occurring.

Priority Tiers: The Hidden Multiplier on Both Clocks

managed it service level agreement response vs resolution f lens over grid

Neither number means anything until you know which priority tier an incident lands in. Priority is the multiplier applied to both clocks, and it is the most commonly disputed element of any managed IT service level agreement.

How providers classify incidents

Typical schemes run from P1 to P4. P1 covers total loss of a business-critical service or a site-wide outage. P2 covers significant degradation or a critical service affecting a department. P3 covers single-user faults with a workaround. P4 covers requests and cosmetic issues. Each tier carries its own response and resolution figures.

Who decides the priority

This clause decides everything else. If the provider assigns priority unilaterally, your P1 can be logged as a P3 and the generous headline figures never apply. Insist on either joint classification, a written matrix with objective triggers such as user counts and affected systems, or a documented right to escalate a classification you dispute.

Why misclassification is the most common dispute

Downgrading is rarely malicious; it is usually an engineer applying a matrix they read differently. But the effect is identical to a breach, and it is invisible unless somebody audits ticket classifications. Ask for a quarterly report showing incident volumes by priority so that a drift toward lower tiers becomes obvious early.

Coverage Windows and Business Hours

A four-hour resolution commitment means one thing at 10:00 on Tuesday and something quite different at 18:00 on Friday.

The 9-to-5 trap

If covered hours run 09:00 to 17:30 on weekdays, an incident raised at 17:00 on Friday with a four-hour target is not due until roughly 12:30 the following Monday. Nothing has gone wrong contractually. The agreement is working exactly as written, which is why covered hours deserve as much scrutiny as the numbers themselves.

Out-of-hours and on-call arrangements

Genuine 24/7 cover for P1 incidents is available and worth pricing separately. Confirm whether out-of-hours support is staffed or on-call, what the callout response is, and whether resolution clocks run overnight or resume at the start of the next business day. The answers vary enormously between providers at similar price points.

Public holidays and seasonal peaks

Check how holidays are treated and whether your own peak periods align with the provider’s quietest staffing. A retailer’s December and an accountancy firm’s January are precisely when reduced cover hurts most. Pairing coverage with proactive monitoring reduces how often you need out-of-hours response in the first place.

What "Resolution" Legally Means in Your Agreement

The definition of resolution is the most consequential paragraph in a managed IT service level agreement and the one buyers most often skip.

Permanent fix versus service restored

“Service restored” means users can work again. “Permanent fix” means the underlying fault is corrected. Most agreements commit to the former, which is reasonable — restoring work is the urgent priority. The problem arises when no obligation exists to progress beyond restoration, allowing recurring faults to be resolved repeatedly without ever being fixed.

Root cause analysis obligations

For P1 incidents, a good managed IT service level agreement commits the provider to a written root cause analysis within a defined window, typically five to ten working days. Without that clause you receive verbal reassurance and no documentation. Root cause reports are also the evidence base for any later argument about repeated failures.

Third-party dependencies

Connectivity, cloud platforms and line-of-business vendors sit outside the provider’s control. Reasonable managed IT service level agreements suspend resolution clocks during third-party dependency. Strong agreements still require the provider to own the ticket, chase the vendor and report progress at stated intervals. Weak agreements simply pass you the vendor’s number.

Service Credits and Why They Rarely Compensate

Service credits are the enforcement mechanism a managed IT service level agreement attaches to a missed target. Understanding their scale prevents unrealistic expectations.

How credits are calculated

Credits are normally expressed as a percentage of the monthly fee for the affected service. A missed P1 resolution might return five or ten per cent of one month’s charge. On a £3,000 monthly contract that is £150 to £300 — set against an outage that may have cost the business considerably more in lost productivity.

Caps, claims windows and forfeiture

Credits are almost always capped, commonly at 100% of one month’s fee and often much lower. They usually require you to claim in writing within a short window, frequently thirty days. Miss the window and the entitlement lapses. Very few organisations track missed targets closely enough to claim, so credits go unclaimed by default.

Credits are not damages

Most managed IT service level agreements state that credits are the sole and exclusive remedy for missed service levels. That wording removes your right to claim consequential loss. It is standard and usually non-negotiable for smaller contracts, but you should know it is there before assuming a serious outage carries serious financial consequences for the provider.

Exclusions That Quietly Void a Managed IT Service Level Agreement

Exclusions in a managed IT service level agreement do not merely reduce cover. They suspend the entire commitment for the affected incident, and they are drafted broadly.

Out-of-scope and unsupported systems

Anything outside the agreed asset list is excluded. So are systems the provider has formally flagged as end-of-life or unsupported. If a warning about an unsupported operating system was issued and not acted upon, incidents on that system typically fall outside every service level in the schedule.

Customer-caused delays

Unavailable staff, missing approvals, absent administrative credentials and refused change windows all pause or excuse the clock. This is reasonable in principle, but it means your own responsiveness directly determines whether the provider’s numbers are achievable. Nominate authorised contacts and deputies so that approvals never wait on one person’s diary.

Force majeure and vendor outages

Major incidents at cloud providers, national connectivity failures and genuine force majeure events are excluded almost universally. That is unavoidable. What you can negotiate is the communication obligation during such events, because during a large vendor outage the only thing your provider can offer is accurate, frequent information.

Realistic Response and Resolution Benchmarks

Benchmarks help you judge whether a proposal is competitive or quietly weak. Figures below reflect common UK small and mid-market managed service offerings.

P1 critical incidents

Expect a 15 to 60 minute response and a 4 to 8 hour resolution target during covered hours. Anything promising a one-hour P1 resolution guarantee deserves scrutiny, because hardware failure and vendor escalation cannot reliably be compressed that far. Overpromising here usually signals a target masquerading as a guarantee.

P2 and P3 incidents

P2 commonly carries a 1 to 4 hour response with same-day or next-business-day resolution. P3 typically carries a 4 to 8 hour response with a two to three business day resolution. P4 requests are often scheduled rather than clocked. These ranges are where most of your ticket volume actually sits.

Uptime alongside the two clocks

Uptime percentages measure availability, not incident handling, and the two are frequently confused. A 99.9% monthly availability commitment permits roughly 43 minutes of downtime per month. Availability, response and resolution together form the complete picture; any managed IT service level agreement quoting only one of the three is incomplete. The wider managed IT SLA guide covers uptime measurement in more depth.

How to Audit and Negotiate Your Agreement

Most of the leverage in a managed IT service level agreement exists before signature. Renewal is the second-best moment.

Questions to ask before signing

Ask who assigns priority and whether you can dispute it. Ask whether resolution figures are targets or guarantees. Ask what stops the clock. Ask what counts as a response. Ask whether resolution means restoration or permanent fix, what the credit percentages and caps are, and what the claims window is.

Evidence to request before signing

Request twelve months of anonymised performance data broken down by priority tier, not a single blended compliance figure. Ask for a sample root cause analysis report and a sample monthly service review pack. Providers who measure themselves properly produce these immediately; providers who do not will offer testimonials instead.

Where to push and where to concede

Push hardest on priority classification rights, the definition of resolution, and clock-stopping scope, because these determine whether the headline numbers are real. Concede on credit caps and the exclusive-remedy clause, which are near-universal. The structural clauses in a managed IT service level agreement matter far more than the compensation clauses. Reviewing them alongside the rest of your managed IT services contract gives you the full commercial picture, and comparing published support plans shows how coverage tiers translate into price.

Common Misreadings of a Managed IT Service Level Agreement

Three assumptions cause more friction than any others. Each is easy to correct before signature and expensive to discover during an outage.

“A one-hour SLA” means fixed within an hour

It almost never does. In practice that phrase refers to response, and the resolution figure sits further down the schedule or is absent entirely. Whenever a provider quotes a single number, ask which clock it belongs to and request the relevant page of the managed IT service level agreement in writing.

High uptime means downtime will be rare

A 99.9% availability figure permits roughly 43 minutes of downtime monthly, but it says nothing about when that downtime falls or how quickly it is handled. Availability and resolution are measured separately, and a managed IT service level agreement can comfortably meet its uptime figure during a month that felt disastrous to your staff.

Service credits will cover our losses

They will not. Credits are calculated against your monthly fee, capped, and usually declared the exclusive remedy. Treat them as a governance signal that a target was missed rather than as compensation. If the financial exposure from downtime is material, the answer is resilience engineering and insurance, not a larger credit clause.

Every incident gets the headline response time

Headline figures apply to the top priority tier only. The response you experience on a typical single-user fault is governed by the P3 row of the table, which is often measured in hours rather than minutes. Read every row of the matrix, not the marketing summary.

Tracking Performance After You Sign

A managed IT service level agreement only has force if somebody measures it. Providers report on themselves, and self-reporting drifts without an independent record.

Keep your own ticket log

Record the time you raised each ticket, the channel used, the priority assigned, the time of first human contact and the time service was restored. A simple spreadsheet is sufficient. Independent records are what turn a vague sense of poor service into a specific, evidenced conversation at review time.

Run structured monthly service reviews

Insist on a monthly or quarterly pack showing volumes by priority, response and resolution compliance per tier, missed targets with reasons, and open root cause actions. Compare it against your own log. Discrepancies in priority classification are the most common finding and the most valuable to correct early.

Escalate patterns rather than individual incidents

One missed target is noise. A quarter in which P2 incidents consistently miss resolution targets is a pattern, and patterns are what justify renegotiating tiers, pricing or scope. Framing escalation around trends rather than a single bad week produces far better outcomes with any managed IT service level agreement.

Frequently Asked Questions

Is response time or resolution time more important?

Resolution time, because it corresponds to how long your business is disrupted. Response time still matters as an indicator of attentiveness and as the trigger for escalation, but a managed IT service level agreement offering only response commitments leaves the risk that actually costs you money entirely uncovered.

Can a provider refuse to give resolution guarantees?

Yes, and many legitimately do for incident types involving hardware replacement or third-party vendors. The reasonable middle ground is guaranteed resolution for P1 and P2 incidents within covered hours, with documented targets and escalation paths for everything else, rather than a blanket refusal across all tiers.

What is a reasonable P1 resolution time?

Four to eight hours during covered hours is the common commercial range for UK small and mid-market agreements. Shorter commitments exist but usually carry significant exclusions or higher pricing. The formal concept is defined in the general service-level agreement framework, and incident priority practice derives largely from ITIL service management.

Does an SLA guarantee uptime too?

Only if it says so explicitly. Uptime is a separate commitment covering availability of infrastructure, measured monthly as a percentage. A managed IT service level agreement can contain response and resolution commitments with no availability commitment at all, so confirm all three are present and separately measured.

How often should the agreement be reviewed?

Annually at minimum, and after any major incident or significant change to your systems. Priority definitions and asset lists drift out of date quickly. A managed IT service level agreement reviewed once at signature and never revisited will not reflect the environment it is supposed to protect three years later.