A Managed Service SLA is only as strong as what’s actually written into it. The whole value of the model is accountability to defined outcomes, not just headcount showing up. If the SLA is vague, that accountability disappears, and what’s left is a retainer that pays for effort without guaranteeing results.
Most SLA friction is predictable and preventable. Here’s what actually needs to be in the contract, with enough specificity to be enforceable, and the questions worth asking if a proposed SLA leaves any of these out.
Response Time and Resolution Time in a Managed Service SLA: Two Different Things
One of the most common SLA gaps: conflating response time with resolution time. They’re not the same, and treating them as one produces exactly the wrong incentive.
Response time is how long before the right person is engaged with the issue. It’s a communication commitment.
Resolution time is how long before the issue is actually fixed. It’s a delivery commitment.
An SLA that only specifies response time creates a situation where a vendor can technically meet every SLA target while an issue sits unresolved for days, as long as someone replied to the ticket promptly. Both need to be in the contract, with separate targets, tiered by severity.
A practical severity structure to consider:
- P1 (critical, system down or data at risk): response within 1 hour, resolution target within 4 hours
- P2 (significant degradation, core functionality affected): response within 4 hours, resolution target within 24 hours
- P3 (minor issue, workaround available): response within 1 business day, resolution target within 5 business days
- P4 (low impact, cosmetic or non-urgent): acknowledged within 2 business days, resolved in next scheduled maintenance window
Adjust these based on the actual criticality of the system being supported. A customer-facing payment flow has different tolerance levels than an internal reporting dashboard.
This distinction is a recognized part of standard ITIL service level management practice, not something specific to any one vendor’s contract template. Response and resolution times are listed as separate, distinct metrics precisely because conflating them lets a provider look compliant while an issue actually sits unresolved.
Uptime Targets: What They Actually Mean
“99.9% uptime” sounds specific but needs context to be enforceable.
Uptime should be defined as: the percentage of time the system is available and performing within defined parameters, measured over a rolling 30-day window, excluding pre-approved maintenance windows.
Without the exclusion clause, every scheduled maintenance window is technically a breach. Without the performance parameters, a system that’s “up” but running at 10% normal speed technically meets the target.
Worth defining explicitly:
- What counts as “available” (not just running, but performing within response-time thresholds)
- How downtime is calculated (when does the clock start and stop)
- What happens to the uptime calculation during planned maintenance
- Who measures it, and from where
Escalation Paths: Named, Not Generic
An SLA that says “escalate to senior management if unresolved” is not an escalation path. A real escalation path names:
- The specific person or role the client contacts at each escalation tier
- The trigger condition for each tier (time elapsed, severity threshold, or both)
- The expected response from each tier
If a P1 issue isn’t resolved in 4 hours, who does the client call? What’s the name, the direct line, and the expected response time from that person? If the SLA can’t answer that specifically, the escalation process only exists in theory.
Remedies for Missed Targets
An SLA without a remedy clause is a best-effort commitment with formal language around it. The remedy section is what makes it a real accountability mechanism.
Common structures:
- Service credits: a percentage of the monthly retainer refunded for each hour of downtime beyond the SLA target. Typically structured as a small percentage per hour, capped at a maximum monthly credit.
- Root cause analysis: mandatory written explanation of what caused an SLA breach and what process change prevents recurrence. Often more valuable than a credit, since it forces the issue to be genuinely addressed.
- Termination rights: at what point does a pattern of missed SLA targets give the client the right to exit the contract without penalty? This should be defined in advance, not negotiated after a relationship has already deteriorated.
Exclusions: What the SLA Doesn’t Cover
Every SLA needs an exclusions section, and it’s worth reading carefully rather than skimming. Common legitimate exclusions include third-party outages outside the vendor’s control, issues caused by the client’s own infrastructure, and force majeure events.
Where exclusions become a red flag: when they’re written broadly enough to cover almost any failure mode. “Issues caused by client systems” is a legitimate exclusion. “Issues caused by factors outside our direct control” is broad enough to potentially cover almost anything, and should prompt a direct conversation about what that actually means before signing.
Reporting and Visibility
The SLA should specify how and when performance against the targets gets reported. Monthly reports are standard; more frequent reporting for high-criticality systems is worth requesting.
The report should include at minimum: uptime percentage for the period, a log of all incidents with severity classification and resolution times, any SLA breaches and the associated remedy applied, and any recurring patterns worth flagging before they become incidents.
The Honest Conversation Before Signing
The most useful pre-signature question isn’t whether the SLA targets look reasonable. It’s: what actually happens when a target is missed, step by step, and can we walk through a hypothetical together?
A partner confident in their delivery will walk through that scenario without hesitation. The answer tells you more about how a missed target will actually be handled than any language in the contract.
Frequently Asked Questions
What’s the difference between response time and resolution time in an SLA? Response time measures how quickly the right person engages with an issue. Resolution time measures how long until it’s actually fixed. An SLA that only specifies response time can technically be met while an issue sits unresolved for days.
What should an SLA remedy clause include? A defined consequence for missed targets, typically service credits, mandatory root cause analysis, or termination rights after a pattern of misses. An SLA without a remedy clause is a best-effort commitment dressed up as a guarantee.
How should uptime actually be defined in an SLA? As the percentage of time a system is available and performing within defined parameters, measured over a rolling window, with maintenance windows explicitly excluded. Without that context, “99.9% uptime” is not enforceable.
What’s a red flag in an SLA’s exclusions section? Exclusions written broadly enough to cover almost any failure mode, such as “issues outside our direct control.” Legitimate exclusions are specific; vague ones are worth a direct conversation before signing.
Related Reading
- ODC, Managed Service, Project-Based, and BOT: How to Choose the Right Engagement Model
- Vendor Evaluation Checklist: Questions to Ask Before Signing an SOW
- How Much Does an ODC Engagement Cost?
If you’re putting together a Managed Service SLA and want a second opinion on whether the terms are actually enforceable, that’s a good thing to bring to a scoping call before anything is signed.
