MSP SLA: Response Time Is Not Resolution Time

An MSP SLA almost always guarantees response time, not resolution time. A fifteen-minute response commitment means someone acknowledges the ticket within fifteen minutes. It says nothing about when your system works again. Reading the difference, and the three clauses around it, is most of what service level review involves.

I am Amelia S. Gagne, CEO of Kief Studio. We deliver against service levels, so this is the buyer's version of a document I sit on the other side of. The scope companion is what an MSP scope of work should say, and the selection stage is how to evaluate a managed service provider.

Why does an MSP SLA measure response instead of resolution?

Because resolution time is partly outside the provider's control, and a commitment nobody can keep is worse than an honest one.

If the cause is a failed hardware component, a cloud provider outage, or a software vendor's defect, the provider can escalate and coordinate but cannot fix. Guaranteeing resolution across those cases would mean pricing in risk they cannot manage.

That is a fair position and it is still not the whole answer. A provider can commit to resolution targets where the cause is within their control, to continuous effort on critical incidents, and to communication intervals during an outage. The absence of all three is a choice, not a constraint.

The question to ask is not "will you guarantee resolution." It is "what do you commit to after acknowledgment." The answer separates providers quickly.

Who decides an incident is critical?

This clause matters more than the response numbers and gets read less.

If the provider classifies severity, the agreement is partly self-graded. An outage you experience as business-stopping can be logged as a standard ticket, and the fifteen-minute commitment never applies because the ticket was never P1.

The fix is to define severity in business terms rather than technical ones. Not "server unavailable" but "a system required to take orders, deliver service, or pay people is unavailable to more than X users." That definition can be applied by either party and produces the same answer.

Two supporting provisions are worth asking for: your right to declare an initial severity, and a documented disagreement path that does not stop the clock while it is resolved.

Severity definitions that only one party understands are the same failure as scope categories that only one party has defined. Both are the mechanism in why your team games every metric you set, which is not about dishonesty so much as about what a measurement rewards.

What do typical response tiers look like?

Commonly published tiers cluster around fifteen minutes for a critical outage, an hour for major degradation, same day for moderate impact, and next business day for low priority. Treat these as a starting point rather than a benchmark, since most published tiers come from provider marketing rather than independent survey work.

The more useful exercise is to derive your own tiers from your own incident history. How long can order entry be down before it costs real money? If the answer is two hours, a fifteen-minute acknowledgment with no resolution commitment does not address the risk you actually carry.

NetDiligence's 2026 Cyber Claims Study, covering 10,309 claims from 2021 through 2025, found that incidents involving business interruption cost small and mid-sized organizations more than five times as much on average as incidents without it. Duration is the expensive variable, and duration is the one most agreements do not commit to.

What are the remedies actually worth?

Usually a service credit, and usually a small one.

A credit of one month's fee against a day-long outage is not compensation, it is a discount on the month in which you were harmed. If your provider bills $6,000 a month and a full-day outage costs you $40,000, the remedy addresses fifteen percent of the loss in the best case.

This is not a scandal. Service credits are an industry norm and no provider at normal pricing can indemnify your business interruption. The point is to see the remedy clearly and place the real coverage where it belongs, which is your own business interruption insurance and your own architecture.

Two things are worth negotiating anyway. First, credits that escalate with repeated misses, because a pattern is different from an incident. Second, a termination right triggered by repeated service level failure over a defined window, which gives cause-based termination something measurable to attach to. That clause is discussed in technology vendor contract exit terms.

What about measurement and reporting?

An SLA without independent visibility is self-reported.

Ask who measures, what the source system is, whether you get direct access to ticket data or only a monthly summary, and how the clock handles pauses. That last item does most of the work in practice. A ticket placed in "awaiting customer" status typically stops the clock, and a provider can meet every published target while a user waits days, simply through status handling.

Reasonable asks: direct read access to your own ticket data, a defined limit on how long a ticket can sit in a paused state before it resumes, and reporting that shows time to resolution alongside time to response even where only the latter is guaranteed. Measuring resolution without guaranteeing it costs the provider nothing and tells you almost everything.

Numbers reported by the party being measured need a source you can check, which is the general argument in data lineage.

What is changing in what is achievable?

Delivery automation is moving the baseline. Omdia's 2026 MSP trends work credits leading providers with technician productivity improvements in the range of 15% to 25% and substantially faster ticket resolution where automation is applied well.

The buyer-side implication is that yesterday's response targets are no longer ambitious, and that resolution commitments are becoming more feasible in the categories where automation actually applies: provisioning, routine access requests, patch deployment, and common break-fix patterns. Those are reasonable places to ask for a resolution target rather than a response target.

What automation does not shorten is the human coordination around a genuine incident, which is where the maintenance-is-the-job point applies. Ask which categories the provider automates and hold them to tighter numbers there specifically.

How we run operations at that ratio is described at ltfi.ai. Brian Gagne handles the infrastructure and monitoring architecture, and briansgagne.com goes deeper on that side.

Related reading

• What an MSP scope of work should say
• How to evaluate a managed service provider
• Co-managed IT without splitting accountability
• Business continuity is architecture, not a binder
• Five metrics that connect to revenue

Frequently Asked Questions

What is the difference between response time and resolution time in an MSP SLA?

Response time is how long until someone acknowledges the ticket. Resolution time is how long until the problem is fixed. Most managed services agreements guarantee only the first, so ask what the provider commits to after acknowledgment: resolution targets where the cause is theirs, continuous effort on critical incidents, and defined communication intervals.

Who classifies incident severity under an SLA?

Often the provider, which makes the agreement partly self-graded. Define severity in business terms both parties can apply, such as a system required to take orders or pay people being unavailable to a stated number of users, and ask for the right to declare an initial severity.

Are SLA service credits meaningful compensation?

Rarely. A credit of one month's fee against a day-long outage typically covers a small fraction of the actual loss. Treat credits as a signal rather than protection, negotiate escalating credits for repeated misses, and place the real coverage in business interruption insurance and architecture.

How do SLA clock pauses work?

Tickets moved to a status such as "awaiting customer" usually stop the clock. This means a provider can meet every published target while a user waits days. Ask for a limit on how long a ticket can remain paused before the clock resumes.

Should I ask for resolution time guarantees?

Ask for them in the categories the provider automates, such as provisioning, access requests, and patch deployment, where Omdia reports leading providers achieving substantial resolution-time improvements. For incidents with external causes, ask for continuous effort and communication intervals instead.