Response vs resolution: what a managed services SLA should actually promise

Two different promises

A response target is a promise about attention: within a set time, a qualified engineer has picked up your incident, understood the impact and told you what happens next. A resolution target is a promise about outcome: within a set time, the service is working again, either fixed or running on an agreed workaround.

Many contracts lead with response times because they are easy to meet. An automated "we have received your ticket" email is not a response, and neither is a triage queue that nobody is working. When you read an agreement, look for the definition of response. It should name a person with the skills to act, and a first human update to you. If the agreement has no resolution target at all, you are buying attention, not outcomes. That can be a fair deal, but only if you know it is the deal.

Severity decides everything, so define it in writing

Every target in the agreement hangs off a severity level, so vague severity definitions make every target negotiable after the fact. A common four-level model works well when each level is defined by business impact rather than technical symptoms. P1: a production service is down or a major outage affects most users, with no workaround. P2: major degradation or a key function unavailable, with a limited workaround. P3: partial or non-critical impact with a workaround available. P4: a minor issue, a question or a cosmetic defect.

Agree who sets the severity. The usual arrangement is that you propose it when you report the incident, and the provider can re-classify it with a written reason you can see. Agree too that severity can move up when the impact grows, and that a dispute goes to a named escalation contact rather than sitting in the ticket. An incident filed as P3 at 17:00 that becomes a full outage by 19:00 should be handled as a P1 from the moment it became one.

Which clock is running

A four-hour target means very different things depending on the clock. Calendar time runs every minute of every day. Business hours run only inside an agreed working day, so a four-business-hour response to a P3 raised at 16:30 on a Friday may fall due on Monday morning. Coverage hours are whatever the agreement defines, such as 24x7 for P1 and business hours for everything else.

Neither clock is wrong, but the agreement has to say which one applies to each severity, in which time zone, and how public holidays are treated. A good test is to ask the provider to work through an example in writing: a P2 reported at 22:00 on a Saturday, and when its response and resolution fall due. If the answer needs a meeting, the clock is not defined yet.

When the clock may pause, and when it may not

Some pauses are fair. If the engineer needs access, a log file or a decision that only you can provide, it is reasonable for the resolution clock to stop while the incident is waiting on you and to restart the moment you reply. What matters is that each pause is recorded, visible to you, and tied to a specific request.

Other pauses are not fair and should be written out of the agreement. Waiting on the provider's own suppliers, such as a hardware vendor, a cloud provider or a software publisher, is the provider's risk unless the agreement says otherwise. So is waiting for a change window the provider controls. An agreement that allows the clock to stop "pending third-party input" with no limit has quietly removed the resolution target.

Resolution is not root cause

Resolution normally means service restored, sometimes on a workaround, not that the underlying fault has been found and removed. That is the right priority during an outage: restore first, investigate second. The investigation still needs its own commitment.

For P1 incidents, and for any recurring P2, ask for a written post-incident review within an agreed number of working days. It should cover what happened, the timeline, the root cause as far as it is known, and the actions that will stop it recurring, each with an owner and a date. Then check the next monthly review to see whether those actions were closed.

Measure per incident, report per month

Attainment should be measured per incident and reported per severity: the share of P1s responded to and resolved within target this month, and so on for each level. Averages hide the incident that mattered. A mean response time of 20 minutes can include one P1 that waited three hours.

Ask for the underlying records, not just the percentages. Each incident should carry its due times, the times it was actually acknowledged and resolved, and any paused time. With those you can check the report yourself instead of trusting it.

Service credits compensate; they do not restore

Service credits are usually a small percentage of the monthly fee and are often capped. They are a useful signal that the provider takes the targets seriously, but they will never cover the cost of a real outage, so do not choose a provider on the size of its credits.

The terms that protect you during a bad incident are operational. Look for a named escalation contact, a communication cadence for major incidents with an update at least every 30 to 60 minutes until the service is restored, and a clear rule on who can declare a major incident. Those terms shape the worst hour of your year. The credit arrives a month later.

Exclusions worth reading twice

Every agreement has exclusions, and most are reasonable: scheduled maintenance, outages you caused, unsupported software versions and events outside anyone's control. The detail is what matters. Maintenance should happen in agreed windows with an agreed notice period, not whenever the provider announces it. Unsupported versions should be listed, with a plan to move off them, so the exclusion does not quietly cover half your estate.

Watch for exclusions of third-party platforms the provider operates on your behalf. If the provider runs your workloads on a public cloud, an outage of that cloud is outside its control. How it is detected, communicated and worked around is not, and the agreement should still say what the provider does during one.

Questions to ask before you sign

What exactly counts as a response, and who performs it? Which clock applies to each severity, in which time zone? When may the resolution clock pause, how is each pause recorded, and can we see it? Who sets severity, and how is a disagreement resolved? Is there a resolution target for every severity, and what does resolution mean? When do we receive a post-incident review? How is attainment reported, and can we see the per-incident data behind it? What happens, step by step, in the first hour of a P1?

A provider that answers these in writing, before you sign, will usually run your incidents the same way.

How our client portal shows it

Every SynapseTel Cloud client works in a portal where each incident carries its severity, its response and resolution due times, and a conversation with the engineer on it. When an incident is waiting on you, the portal pauses the resolution clock and extends the due time by exactly the time it waited. Your support agreement, with its severity definitions, targets and coverage hours, sits in the same place, and each month's service review reports attainment against it. Targets currently run in calendar time, and your own targets are the ones set in your agreement.