Response Vs Resolution
A support SLA usually contains two timed promises. Response time is the interval between a ticket being logged and a qualified human acknowledging it and starting work. Resolution time is the interval until the problem is fixed, or until the vendor says it is.
The gap between them can be enormous. AWS, for example, publishes initial response targets for a business-critical system down case: under 30 minutes on Business Support+, under 15 minutes on Enterprise Support, and 5 minutes from an incident management engineer on Unified Operations. Lower severities run to 1 hour for a production system down, 4 hours for production impaired, 12 hours for a system impaired, and 24 hours for general guidance. None of those plans commits to a fix time.
That pattern is normal among large infrastructure vendors. They control how fast they answer. They cannot always control how long a root cause takes to find, so they decline to promise it.
Smaller SaaS suppliers and managed service providers often do commit to resolution or restoration targets, and that is where benchmarks help a buyer judge what is reasonable.
Where Contracts Mislead
The first misreading is treating response as progress. An auto-reply with a ticket number meets a loosely worded response clause. Unless the contract says a named engineer must reply with a substantive first assessment, the clock can be stopped by a bot.
Second, “resolution” hides three different outcomes. Restoration means service is back, possibly through a rollback. A workaround means you can operate with a manual step. Permanent fix means the defect is corrected in code. A vendor reporting 98% resolution within target may be counting workarounds, which, frankly, is the number most dashboards show without saying so.
Third, the clock itself. An 8-hour resolution target measured in business hours on a 09:00 to 17:00 calendar behaves nothing like 8 elapsed hours. A ticket opened at 16:30 on Friday is due at 16:30 on Monday, 72 calendar hours later.
These numbers also depend on machinery the customer rarely sees. Ticketing tools such as Zendesk, Jira Service Management, and Freshdesk run SLA timers with configurable pause states. Severity is assigned by a triage rule or an agent. On-call paging through a tool like PagerDuty decides if anyone is awake at 03:00. Change any of those settings and the reported attainment changes with it, while the customer experience stays the same. Or gets worse.
Setting Usable Targets
Define Severity By Impact
Write severity levels around observable business effects, not adjectives. “Sev 1: production unavailable for all users, or data loss in progress” can be verified. “Sev 1: critical issue” invites a dispute at the worst moment. Four levels are standard. State who assigns severity, and give the customer the right to set it at opening, with the vendor able to downgrade only with a written reason.
Split Fix Into Three Clocks
Ask for separate targets for first response, restoration or workaround, and permanent fix. Common contract ranges for B2B software look like this: Sev 1 response in 15 to 60 minutes around the clock, with restoration or workaround in about 4 hours. Sev 2 response in 2 to 4 hours, with resolution in 1 to 2 business days. Permanent fixes are often tied to the next scheduled release instead of a fixed hour count. Add an update cadence for Sev 1, typically every 30 or 60 minutes, because silence during an outage does more damage than a slow fix.
Pin Down The Clock Rules
Three settings decide what a target means. Coverage: 24x7 for Sev 1 and business hours for the rest is a typical split, and the time zone must be named. Pauses: most timers stop while a ticket sits in “pending customer.” Cap that, for instance by restarting the clock the moment the customer replies and logging every pause. Reopens: a ticket closed and reopened within a few days should resume its original timer, not start fresh.
Measure Attainment Honestly
SLAs are commonly written as a percentage of tickets meeting target, often 90% or 95% per month. At 95% on 400 tickets, 20 can miss without a breach. Ask how far those misses can run. A percentile report (the time within which 90% of tickets closed) alongside the worst five cases tells you more than an average. You get the target, the tail, and the vendor has less room to hide a three-week ticket.
Two Contract Scenarios
A payments API customer. A 60-person online retailer reviews a renewal from its payments processor. The draft promises a 1-hour response for Sev 1 and nothing about fix time. The retailer asks for three additions: a named engineer at first response, updates every 30 minutes, and a 4-hour restoration or workaround target with a service credit of 5% of the monthly fee per missed incident, capped at 25%. The vendor accepts the first two and offers the restoration figure as a goal, not a commitment. The retailer signs anyway, with a clearer picture of what it bought.
A managed IT provider. An 80-seat professional services firm sees its provider report 96% resolution attainment while staff complain about week-long waits. An export of ticket history shows roughly 40% of tickets spent more than half their life paused in “awaiting user.” Many pauses followed a one-line question the agent could have answered from the original ticket. The firm renegotiates: pauses need a logged reason, and a monthly report lists elapsed calendar time next to SLA time. Attainment drops to 88% on paper. Nothing else changed.
Benchmarks By Severity
| Severity | Typical Definition | First Response Range | Restoration Or Resolution Range |
|---|---|---|---|
| Sev 1 | Production down for all users, or active data loss | 5 to 60 minutes, 24x7 | Workaround or restoration in about 4 hours where committed; updates every 30 to 60 minutes |
| Sev 2 | Major function impaired, no acceptable workaround | 1 to 4 hours | 1 to 2 business days |
| Sev 3 | Partial loss of a non-core function, workaround exists | 4 to 12 business hours | 5 to 10 business days |
| Sev 4 | Question, cosmetic defect, or feature request | 1 to 2 business days | Next release or best effort |
These ranges combine published cloud vendor response targets with terms commonly seen in B2B software and managed service contracts. They are reference points for negotiation, not a formal industry standard, and resolution columns apply only where a supplier agrees to commit.
Common Mistakes
Buying a faster response tier to fix a slow resolution problem. Moving from a 30-minute to a 15-minute first reply saves 15 minutes. If incidents take nine hours to fix, the money belongs elsewhere, perhaps in architecture review or a named technical contact.
Ignoring the remedy. A target with no service credit, no termination right after repeated breaches, and no reporting duty is a statement of intent. Check the credit cap too. Many sit at 10% to 30% of one month’s fee.
Letting the vendor define “resolved” alone. Require customer confirmation, or automatic closure only after a set number of days without reply.
Copying another company’s numbers. A 15-minute Sev 1 response needs a staffed on-call rotation, and a five-person supplier that signs it will miss it, and it rarely surfaces until the first night-time outage.
Forgetting scheduled maintenance and third-party exclusions. Outages caused by an upstream cloud region are often carved out of the vendor’s obligations.
FAQ
What is a good first response time for support?
For a production outage, 15 to 60 minutes around the clock is common in B2B contracts, with premium cloud tiers at 5 to 15 minutes. For routine questions, one business day is typical.
Do cloud vendors guarantee resolution time?
Generally no. AWS, for instance, publishes response targets by severity and plan but does not commit to a fix time. Resolution commitments appear more often in SaaS and managed service contracts.
What is the difference between an SLA and an SLO?
An SLA is a contractual commitment with remedies. An SLO is an internal target the supplier aims for, usually tighter than the SLA, with no customer remedy attached.
Does pending customer time count toward resolution?
In most ticketing setups the timer pauses while the vendor waits for your reply. The contract should say so and should require the clock to resume as soon as you answer.
How are support SLA credits calculated?
Usually as a percentage of the monthly fee per missed target or per attainment band, capped at a set share of that month’s charges. Credits often must be claimed in writing within 30 days.
Author’s Insight
Published support terms show a consistent split: the larger the vendor, the more precise the response promise and the vaguer the fix promise. That is rational from the supplier’s side, and it shifts the diagnostic risk onto the customer. AWS retiring its legacy plans on January 1, 2027 in favour of tiers built around faster first contact fits the same logic. For a buyer, the practical reading is that response time is a staffing metric and restoration time is an engineering metric, and only the second one tracks what an outage costs. Where a vendor will not commit to restoration, update cadence and escalation paths are the next best things to negotiate.
Key Takeaways
- Response time measures how fast someone starts work. Resolution time measures how fast the problem ends. Contracts often promise only the first.
- Ask which outcome “resolved” means: restoration, workaround, or permanent fix.
- Business-hours clocks and pause states can stretch an 8-hour target across a weekend.
- Reference ranges: Sev 1 response in 5 to 60 minutes with restoration near 4 hours where committed, down to one or two business days for low-priority queries.
- Request percentile reporting and worst-case tickets, not averages or attainment alone.
- A target without credits, reporting, or an exit right is hard to enforce. Vendor plan terms change, so confirm current figures in the supplier’s own documentation before signing.
