Response and resolution targets in a managed services agreement

Two different promises

Define response as a qualified engineer reviewing the impact and giving you a first update. Define resolution separately: restoring service through a fix or an agreed workaround. Agree the target for each.

Check how the agreement defines a response, including the required engineering review and first update. An automated receipt alone does not establish that an engineer has started work. If the agreement includes a response target without a resolution target, confirm what ongoing investigation, communication and escalation it covers.

Severity decides everything, so define it in writing

Define severity by business impact. P1: production service down or a major outage affecting most users, without a workaround. P2: major degradation or a key function unavailable, with a limited workaround. P3: partial or non-critical impact with a workaround. P4: a minor issue, question or cosmetic defect.

Agree who sets severity, how to record a reclassification and who resolves disputes. Raise severity when the business impact grows. Record the time of that change so escalation and target calculations follow the agreed rules.

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.

For each severity, agree the applicable clock, time zone and holiday rules. Work through an example in writing, such as a P2 reported at 22:00 on a Saturday, to confirm when response and resolution would fall due.

When the clock may pause, and when it may not

Agree when waiting for your access, information or decision may pause the resolution clock. Require a specific request, a visible pause record and a restart when you reply.

Set explicit limits for supplier delays and maintenance windows. Avoid an unrestricted pause for third-party input: it can leave a resolution target without a meaningful deadline.

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 and recurring P2 incidents, agree a written post-incident review deadline. Request the timeline, known root cause and corrective actions with owners and dates. Follow up on those actions in your monthly review.

Measure per incident, report per month

Measure each incident against its targets and report results by severity each month. Include missed targets alongside percentages and averages so you can identify the incidents that need follow-up.

Request due times, acknowledgment and resolution timestamps, and recorded pauses. Use those records to check the monthly report.

Service credits compensate; they do not restore

Review service-credit amounts, eligibility and caps. Assess those terms alongside incident handling and escalation; credits alone do not restore service or establish the value of the support.

Agree a named escalation contact, a communication cadence during major incidents and who can declare a major incident. Define these operational responsibilities alongside any service-credit terms.

Exclusions worth reading twice

List exclusions explicitly, including scheduled maintenance, unsupported versions and events outside the agreed responsibility. Agree maintenance windows and notice periods. Identify unsupported releases and plan their treatment.

For third-party outages, agree who detects the issue, communicates updates, coordinates escalation and evaluates a workaround. Record these responsibilities even when the underlying failure is outside the service provider’s control.

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?

Record the answers in your agreement so your teams can refer to the same definitions during an incident.

How our client portal shows it

In your client portal, each incident shows its severity, response and resolution due times, and a conversation with our engineers. When we are waiting for your input, the portal pauses the resolution clock and extends the due time by the recorded waiting period. Your support agreement includes severity definitions, targets and coverage hours, and monthly service reviews report attainment against it. Portal targets currently run in calendar time; your applicable targets are set in your agreement.