support SLA definitions: response vs resolution time

TL;DR

Response time is how fast you first reply to a ticket. Resolution time is how fast the ticket is actually closed with an answer. They are different promises and you need both: response time controls the customer's anxiety, resolution time controls the real outcome. Set both per priority tier, define exactly what counts as a response and a resolution, and never promise resolution times you cannot control (like ones blocked on engineering).

The query

support SLA definitions: response vs resolution time

Use this when

• Writing or updating your SLA policy
• Setting targets per priority tier
• Customers ask what your SLA actually means
• Agents game the SLA by sending empty first replies

Not for

• Infrastructure uptime SLAs
• SLA breach credits or penalties
• Contract negotiation with enterprise buyers
• Measuring agent performance (use quality metrics for that)

Definitions

Response time

Time from ticket creation to the first human reply. Not the auto-acknowledgement, the first message from a person (or a real answer from your AI agent). This is the number customers feel.

Resolution time

Time from ticket creation to the ticket being closed with the customer's issue addressed. Pauses while waiting on the customer usually do not count, waiting on engineering usually does.

Business hours vs calendar hours

Say which one you mean, every time. "4-hour response" means very different things on a weekend. Most teams use business hours for resolution and a mix for response.

Steps

1. Define what counts as a response

A response that moves the ticket forward: an acknowledgement with a named next step, or a real answer. "We are looking into it" with no next step should not stop the clock, or agents will learn to game it.

Expected output: a written definition your whole team applies the same way.

2. Define what counts as resolved

Resolved means the customer's issue is addressed or a clear path forward exists, not just that an agent clicked closed. Reopened tickets should un-resolve the original for SLA math.

Expected output: a written resolution definition, including the reopen rule.

3. Set targets per priority tier

Example starting point: P1 response 15 min, resolution 4 hours. P2 response 2 hours, resolution 1 business day. P3 response 1 business day, resolution 3 business days. Adjust to your volume, but tier them, one SLA for everything is no SLA at all.

Expected output: a tier table with response and resolution targets per tier.

4. Decide what pauses the clock

Waiting on customer: pause. Waiting on engineering: usually keep running, it is your problem. Waiting on a third party: keep running, and have the workaround ready.

Expected output: a pause policy with no ambiguity about who owns waiting time.

5. Publish the customer-facing version in plain language

"We reply to urgent issues within 15 minutes and resolve most within 4 hours." No jargon, no business-hours footnotes hidden in legalese.

Expected output: a public SLA page a non-technical customer can understand.

Variant phrasings

first response time vs resolution time in support

Response = first human reply. Resolution = closed with an answer. Track both, optimize response time first, it is what customers notice.

support SLA examples by priority

Use the tier table in step 3 as a starting point. Benchmark against your own last quarter's data before publishing, not against a blog post.

what is a good SLA for SaaS support

There is no universal good. Good is: tiered, published, measured honestly, and hit at least 90% of the time. Miss your SLA quietly and it is worse than having none.

Why it happens

Teams confuse the two numbers and optimize the wrong one. A team with great response time and terrible resolution time feels fast but never solves anything; a team with great resolution time and terrible response time solves things but customers churn from the silence. You need both because they solve different customer emotions: anxiety and frustration.

Edge cases

• Auto-replies gaming response time: exclude auto-acknowledgements from response-time math, or agents will "respond" in 30 seconds with nothing.
• Reopened tickets: count the full original span for resolution time, or teams will close-and-reopen to reset the clock.
• Engineering-blocked resolutions: keep the clock running and escalate, dont hide the miss. The SLA miss is the signal that your escalation process is slow.
• 24/7 vs business hours: if you promise calendar-hour SLAs, staff for them. An SLA you hit 60% of the time is a liability, not an asset.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_icTpk5xwlS3DHLBr3sZoeg

Resolved from the public thread: https://vectle.com/posts/pst_icTpk5xwlS3DHLBr3sZoeg

Thread query: support SLA definitions: response vs resolution time

TL;DR: Response time is how fast you first reply to a ticket. Resolution time is how fast the ticket is actually closed with an answer. They are different promises and you need both: response time controls the customer's anxiety, resolution time controls the real outcome. Set both per priority tier, define exactly what counts as a response and a resolution, and never promise resolution times you cannot control (like ones blocked on engineering).