SLA vs OLA: The Accountability Guide for Managed IT Buyers

Why this distinction matters

Enterprise buyers evaluating a managed IT partner almost always ask about the SLA — the response times, uptime targets, and penalties they will get in writing. Very few ask about the OLA, the internal agreement that decides whether the SLA is actually deliverable. At Prime Fixel we treat both as one accountability system: the SLA is the promise to you, the OLA is the plumbing that keeps that promise honest.

SLA vs OLA at a glance

| Dimension | SLA (Service Level Agreement) | OLA (Operational Level Agreement) | |---|---|---| | Between whom | MSP and the customer | Teams inside the MSP (helpdesk, NOC, field, vendor management) | | Visible to customer | Yes — contractual | No — internal | | Measures | Response, resolution, uptime, CSAT | Handoff time, escalation SLA, patch windows, on-call rotation | | Enforcement | Service credits, penalties | Internal KPIs, team scorecards | | Purpose | Sets the customer promise | Makes the customer promise achievable |

An SLA without a matching OLA is a marketing line. An OLA without an SLA is engineering discipline nobody is paying for.

A concrete example

Suppose your SLA says P1 incidents are resolved in 4 hours, 24×7. For that to be real, the underlying OLAs have to say things like:

• Helpdesk acknowledges P1 in ≤ 5 minutes and escalates to Tier 2 in ≤ 15 minutes.
• NOC on-call engineer joins the bridge within ≤ 10 minutes of escalation.
• Vendor management engages the OEM (firewall, ISP, hypervisor) inside ≤ 30 minutes when the fault is upstream.
• Change advisory board pre-approves emergency change templates so remediation is not blocked by governance.

Break any one of those internal timings and the customer-facing 4-hour SLA silently becomes fiction — even if nobody has technically breached a clause.

Where SLAs quietly fail

Most SLA disputes we inherit from other providers trace back to the same OLA gaps:

1. Single point of escalation. One senior engineer owns every P1. When they are on leave the OLA breaks, and only the customer notices.
2. No handoff SLA between shifts. APAC-hours ticket is "in progress" at 20:00 and picked up fresh at 09:00 the next day. The customer sees 13 hours of silence.
3. Vendor dependencies not timed. The MSP is waiting on the ISP; the ISP is waiting on the MSP. Nobody owns the clock.
4. Patch and change freezes not published internally. Field team promises a fix Friday; change board blocks it until Monday.
5. CSAT counted, root cause ignored. SLA is "met" because the ticket closed in time, but the same incident recurs monthly.

How Prime Fixel wires SLA and OLA together

Accountability is the theme, so we make the mapping explicit for every customer:

• Every SLA clause maps to at least one OLA. If we cannot name the internal team, the timing, and the escalation path behind a promise, that promise does not go into the contract.
• Shared dashboards. Response, resolution, and uptime are visible to the customer. The OLA metrics (escalation timings, handoff quality, vendor response) are visible to our delivery managers — reviewed weekly, reported to you monthly.
• On-call is a rota, not a person. Every tier has a primary and a secondary on every shift, with automatic escalation if the primary does not acknowledge inside the OLA window.
• Post-incident reviews. Any P1 or repeated P2 triggers an RCA that checks both the SLA outcome and which OLA held or failed. Fixes go into the runbook, not into a promise.
• Governance changes are pre-approved. Emergency change templates for common failure modes (failover, rollback, DNS switch, password reset at scale) sit ready so the OLA is not blocked by paperwork.

What to ask a prospective MSP

If you are evaluating providers, do not stop at the SLA table. Ask:

1. "Show me the OLA that sits behind your P1 resolution SLA — who does what, in what order, in what time?"
2. "Who is on the escalation rota tonight, and who is the backup?"
3. "How do you time vendor dependencies inside your SLA clock?"
4. "What percentage of your SLAs were met last quarter without internal OLA breaches?" (The gap between those two numbers is where you will get hurt.)
5. "How is your change advisory board structured to not block emergency remediation?"

A confident MSP will answer all five without hedging. A provider that only wants to talk about the customer-facing SLA is asking you to trust promises they have not engineered to keep.

FAQ

Is an OLA the same as an underpinning contract (UC)?

No. An OLA is between internal teams of the same provider. An underpinning contract is with an external vendor — an ISP, an OEM, a cloud provider — that the MSP depends on to hit the SLA. Mature providers document all three layers (SLA → OLA → UC) so the accountability chain is unbroken.

Do OLAs have penalties?

Usually not financial penalties like an SLA. OLA breaches show up as internal KPIs, team scorecards, and RCA action items. The point is not to punish teams — it is to catch a breaking promise before the customer feels it.

Can I ask my MSP to share their OLAs?

You can ask for the structure and timings, and a good provider will share them. The full internal document is rarely handed over verbatim, but the escalation ladder, on-call rotation, and internal SLAs for each handoff should be transparent.

What is a reasonable OLA gap tolerance?

A well-run MSP keeps internal OLA timings tighter than the customer SLA by at least 25–40%. If your SLA is 4 hours end-to-end, the sum of internal OLA windows should fit inside roughly 2.5–3 hours — the remaining buffer absorbs vendor waits and edge cases.

How often should SLA and OLA be reviewed?

At Prime Fixel we review SLA outcomes monthly with the customer and OLA outcomes weekly internally. Both are refreshed formally at every quarterly business review, and immediately after any major incident.

Bottom line

An SLA tells you what your MSP has promised. An OLA tells you whether they have organised themselves to keep that promise. When you are choosing a managed IT partner, insist on seeing both — accountability lives in the space between them.