Response time and resolution time are not the same promise

Support agreements normally commit to a response time. Customers normally read that as how long until the problem is fixed. The gap between those two readings is where most dissatisfaction with support contracts comes from, and it is entirely avoidable by being specific.

What each term means

Response time is how long until someone acknowledges the ticket. At its weakest it is an automated email, which is a commitment about a mail server rather than about support.

Resolution time is how long until the problem is fixed. It is the number customers care about and the one providers are reluctant to commit to, for a legitimate reason: resolution depends on things outside the provider’s control — a manufacturer’s part, a third-party vendor, access to a site, a decision from the customer.

Both objections are real. Neither justifies a contract that commits only to acknowledgement.

The commitment worth asking for

Between the two sits the useful one: time to a qualified person actively working on it. Not an acknowledgement, not a promise of a fix — an engineer with the right skills engaged on the problem.

It is within the provider’s control, which makes it a fair thing to commit to, and it is what the customer actually wants from the first hour. A contract with an acknowledgement time, an engagement time, and a target (rather than a guarantee) for resolution is honest in all three lines.

Severity has to be defined by impact

Every agreement tiers its response by severity, and every dispute about response is really a dispute about severity. Define the tiers by business impact, in terms both sides can check:

• CriticalA business process has stopped. Not “a server is down”, because a server can be down with nothing affected.
• HighSignificantly degraded, or a group of users unable to work.
• MediumOne user affected, or a workaround exists.
• LowRequests and minor faults.

Then settle two mechanics in advance: who sets the severity, and how it is disputed. The customer setting it initially with the provider able to challenge, resolved by a named person, prevents the argument that otherwise happens during the incident itself.

The clauses that decide the real number

• Business hours or around the clock?A four-hour response at 5pm on a Friday is Monday morning under a business-hours definition.
• When does the clock start?At the report, or when the ticket is triaged and assigned? The second can absorb hours invisibly.
• Does it pause?Waiting for the customer, for a part, for a vendor — all legitimate pauses, all of which can make an unmet commitment appear met. Agree what pauses the clock and make the pauses visible in the ticket.
• What happens when it is missed?Most agreements have no answer, which makes the commitment aspirational. A credit is common; a defined escalation to a named person is often more useful.

What to measure once it is running

The contractual figures are a floor, not a picture. Three things tell you more:

• The distribution of resolution times, not the average.A fortnight where most tickets close in an hour and three take five days averages fine and is not fine.
• Reopened tickets.These are resolutions that were not.
• Time by severity, over time.If critical response is steady while medium drifts, capacity is being consumed by escalations.

Write down what the service does not cover

The other half of the argument is scope. Which systems, which sites, which hours, which categories of request. An agreement that specifies response times precisely and coverage vaguely will produce a dispute about whether a particular thing was ever in scope — and that dispute arrives during an outage.

Our infrastructure managed services are written with severity defined by business impact, an engagement commitment rather than only an acknowledgement, and the pause conditions stated. If your current agreement commits only to a response time, it is worth reading again with these questions beside it.