A “1-hour response” sounds fast until you realize it says nothing about how long the actual fix takes. Here's how to read an SLA properly — realistic benchmarks by severity, the red flags that signal vague language, and what's standard versus negotiable.
Comparing managed IT providers on price alone misses the part of the contract that determines what actually happens when something breaks. Two providers can quote nearly identical monthly rates and mean completely different things by “fast response.” One difference: whether their SLA is a specific, measurable commitment or a marketing phrase with no teeth.
A service level agreement (SLA) is the section of a managed IT contract that defines measurable performance commitments — typically response time, resolution time, and uptime — along with how severity is classified and what happens when a target is missed.
“What would break first if you doubled your headcount tomorrow? That’s the question worth answering before it’s urgent.”
— Jeffrey Bowles, Partner & Director of IT Services, ACT360
This isn’t about memorizing industry jargon. It’s about knowing which numbers in a proposal are commitments and which are just confidence.
Why “Fast Response” Isn’t a Real Commitment

Response time and resolution time measure two different things, and a lot of sales conversations only mention the more flattering one. Response time is how long it takes someone to acknowledge a ticket. Resolution time is how long it takes to actually fix the problem. A provider can hit a 15-minute response target on every single ticket while still taking three days to resolve a server issue — technically compliant, practically useless if you’re the business waiting on that server.
The industry-standard way to structure this is the priority tier model used across IT service management generally: incidents get classified by severity (how bad the problem is) and urgency (how quickly it needs fixing), and each combination gets its own response and resolution targets. Government of Canada departments are held to a similar discipline under the Treasury Board’s Directive on Service and Digital, which requires published, measurable service standards with performance results reported publicly — the same underlying principle of “define it, measure it, publish it” that a good commercial SLA should follow. Shared Services Canada, for example, publicly tracks metrics like the percentage of time critical incidents are restored within an established service level standard, rather than reporting a single blended average.
What Realistic SLA Benchmarks Look Like by Severity
There’s no single universal number, but the following ranges reflect what’s typically achievable and commonly seen across the managed IT industry for small and mid-sized business support:
| Severity | Example | Typical Response | Typical Resolution Approach |
|---|---|---|---|
| Critical | Company-wide outage, server down, suspected security incident | 15-30 minutes | Continuous effort until restored; hourly updates |
| High | A major system down affecting a department or key function | 1-2 hours | Same-business-day resolution target |
| Medium | Single-user issue with a workaround available | Same business day | 1-2 business days |
| Low | Routine request, minor change, no urgency | 1 business day | Scheduled, non-urgent |
A few things worth noticing in this structure. First, critical and high severity get an explicit resolution approach, not just a response time — because that’s where the business impact actually lives. Second, “continuous effort until restored” is a more honest commitment for a critical outage than a hard resolution deadline, since some root causes (a failed ISP circuit, a hardware vendor’s turnaround time) are outside any provider’s direct control. A trustworthy SLA says so explicitly rather than promising a resolution time it can’t guarantee.
Red Flags in SLA Language
A few patterns show up consistently in SLAs that look reassuring on paper but don’t hold up in practice:
One blended response time for everything. If a proposal quotes a single number — “1-hour response” — without breaking it down by severity, that number is doing more marketing work than contractual work. A single-user printer issue and a company-wide outage shouldn’t carry the same commitment.
No definition of what counts as each severity level. If “critical” isn’t defined, a provider can classify a genuine outage as “high” and still technically meet their SLA, just more slowly than the situation actually calls for.
Resolution time with no exceptions ever mentioned. A provider who guarantees resolution on every issue, with no acknowledgment that some causes are outside their control, is either overpromising or hasn’t thought the SLA through carefully.
No stated consequence for a missed target. An SLA without any defined remedy — a service credit, an escalation trigger, something — is a description of intentions, not an enforceable commitment.
Uptime with no measurement window specified. “99.9% uptime” means something very different measured over a rolling 30 days versus measured once a year with no follow-up reporting.
What’s Standard vs. What’s Negotiable

Some SLA terms are close to industry-standard and worth expecting as a baseline. Others vary more and are reasonable to negotiate depending on your business’s risk tolerance and budget.
Generally standard: Severity-based response tiers, a defined escalation path when a ticket isn’t progressing, and a named point of contact for account-level issues rather than a purely anonymous ticket queue.
Reasonable to negotiate: After-hours response commitments (some providers offer faster after-hours SLAs at a premium), on-site response time versus remote-only, and reporting frequency on SLA performance — monthly reporting is common, but businesses in regulated industries may want it more often.
Worth asking about directly, since it varies a lot by provider: What happens to your SLA during a mass-incident event (a regional outage affecting many clients at once), and whether the SLA applies equally to every named user or scales differently for a larger organization.
Why This Matters More for Some Industries Than Others
An SLA gap that’s an inconvenience for one business can be a genuine liability for another. A law firm with a missed court filing deadline, a healthcare practice where a slow EMR delays patient care, or a manufacturer where a down production line costs real revenue per hour all have a lower tolerance for vague response commitments than a business where a slow ticket is just an annoyance. If your business operates in a regulated or deadline-driven environment, it’s worth treating the SLA section of a proposal with the same scrutiny as the pricing section — because for those businesses, it often matters more.
What This Looks Like at ACT360

Every ACT360 managed IT client gets a named contact — Adam or Jeffrey, not a rotating helpdesk — specifically so that account-level issues have someone accountable, not just a ticket number. Severity is defined in the agreement before anything is signed, not decided on the fly when an incident happens, and our vCIO-led quarterly business reviews include a look at actual SLA performance, not just a count of closed tickets.
We also don’t guarantee a resolution time we can’t control. If a root cause sits with an ISP or a hardware vendor, we say so and manage the process, rather than promising a number designed to sound good in a sales conversation. That’s consistent with why every ACT360 managed IT engagement includes a 90-day exit clause: a provider confident in how it performs against its own SLA shouldn’t need a long-term lock-in to prove it. For a broader look at what else should be named specifically in a managed IT agreement, see our breakdown of what managed IT actually includes.
Final Thought
An SLA is only as good as its specificity. Vague language (“fast,” “priority,” “proactive”) costs nothing to put in a proposal and means nothing when something actually breaks. Specific language — defined severity tiers, separate response and resolution targets, a real escalation path — costs a provider something to commit to, which is exactly why it’s worth checking for before you sign.
T: 705-739-2281 E: [email protected]