SLA response time promises like “We respond within 1 hour” sound reassuring until you realize response and resolution are two different promises, and the SLA may only cover one of them. Here’s how to decode the language that actually matters in a service agreement.
We touched on SLA language briefly in our August post on reading an IT quote. This one goes deeper into the specific phrasing, because SLA response time language is where a lot of genuine, honest-sounding SLAs still leave a meaningful gap between what a client assumes is promised and what’s actually written down.
SLA Response Time vs Resolution Time: The Distinction, Precisely
| Term | What it actually promises |
|---|---|
| Response time | Time until someone acknowledges the ticket — this can be an automated confirmation, not a technician actively working the issue |
| Resolution time | Time until the issue is actually fixed — the more meaningful metric, and the one many SLAs conspicuously don’t commit to |
| Time to engage | A middle ground some SLAs use — time until a technician actively begins working the issue, distinct from a bare acknowledgment |
A response-time-only SLA can be honest and still leave you exposed
A provider can genuinely respond within their stated one hour — an automated email counts — while the actual fix takes days, and technically nothing in the agreement was violated. This isn’t necessarily bad faith; it’s simply what the specific language commits to. The fix is asking directly whether resolution time is covered at all, and if so, for which severity levels.
How to read severity tiers
- Check whether tiers are actually defined, not just implied: A real SLA specifies what counts as “critical” vs. “standard” with concrete examples vague tier definitions leave room for dispute about which timeline applies to your actual issue.
- Confirm resolution time commitments exist for the tiers that matter to you: If only response time is specified for lower tiers, that’s a meaningful gap for anything beyond the most critical issues.
- Ask what happens if a timeline is missed: A genuine SLA typically includes some consequence or credit for a missed commitment — an agreement with no mechanism for that is closer to a target than an actual guarantee.
A managed IT services agreement should spell all three of these out in plain language.
Questions to ask before signing
Before signing any agreement with SLA language
- Does the SLA commit to resolution time, response time, or both — for each severity tier?
- How are severity tiers specifically defined, with examples?
- What happens — contractually — if a timeline is missed?
- Does “response” mean automated acknowledgment or an actual person engaging with the issue?
Frequently Asked Questions
It can be reasonable depending on the nature of the work — some issues genuinely can’t be bound to a fixed resolution timeline. The key is transparency: knowing that upfront, rather than assuming resolution is covered when it isn’t.
Same-business-day acknowledgment is a common, reasonable baseline for non-critical issues, with much faster commitments (often under an hour) for anything marked critical or business-impacting.
This varies by provider, but it’s often worth asking, especially for a longer-term or larger agreement. Some providers have room to adjust specific severity-tier commitments even if their standard contract has default terms. This is also worth raising if you use co-managed IT, where responsibilities are shared.
Conclusion and Next Steps
None of this requires legal expertise to navigate. An SLA response time commitment only means something when resolution time and severity tiers are defined alongside it, so read the specific words rather than the general impression an SLA creates, and ask directly about the gaps a vague or response-time-only commitment leaves open. Want a second opinion on an agreement you’re reviewing? Talk to our IT team and we’ll walk through it with you.
Ready to fix this for your business?
Table of Contents
