OLAs and Underpinning Contracts: The Internal Promises That Make Your SLAs Achievable

Most SLA breaches are not support failing to reply. They are support waiting — on an engineer to confirm a fix, on infrastructure to restore a node, on a vendor to answer a ticket of its own. The customer-facing clock is running the whole time, and when it expires the breach lands on support even though the delay happened three teams away. This is the gap that SLA policies alone cannot close: a promise to the customer is only as reliable as the chain of internal and external promises it quietly depends on. ITSM has a name for closing that gap — OLAs (Operational Level Agreements) for internal teams, and underpinning contracts for outside vendors. They are the unglamorous plumbing that turns an SLA from a hopeful number into a commitment the whole organization is actually wired to keep.

SLA vs OLA vs underpinning contract

The three sit in a chain, and the distinction is simply who promises whom.

• SLA — the external promise. Between you and the customer. "We will respond to a high-priority ticket within one business hour and resolve it within eight." It is the only one the customer sees, and the only one they hold you to.
• OLA — the internal promise. Between support and another internal team. "When support escalates a confirmed bug as high-priority, engineering will acknowledge within thirty minutes and provide a status within two hours." The customer never sees it, but it is what makes the SLA's resolution target physically possible.
• Underpinning contract — the vendor promise. Between you and an external supplier — your hosting provider, your payments processor, a hardware vendor. "Our infrastructure provider guarantees a four-hour replacement on failed hardware." You do not control it, you negotiate it, and your SLA must never promise the customer something faster than your underpinning contract can deliver.

The rule that ties them together is arithmetic: an SLA can only be as fast as the slowest link in the chain it depends on. If your SLA promises an eight-hour resolution but the bug fix depends on a vendor whose underpinning contract allows them twenty-four hours to respond, you have promised something you cannot keep. The whole point of mapping OLAs and underpinning contracts is to surface exactly these mismatches before a customer discovers them.

Map the dependency chain for each SLA target

You cannot write OLAs in the abstract. Start from a real SLA target and trace what it actually depends on. Take "resolve a high-priority bug within eight business hours" and walk the path a ticket takes: support diagnoses and reproduces it, escalates it to engineering, engineering confirms and fixes, the fix ships, support verifies and closes. Every handoff in that path is a place the clock can stall — and every stall point needs an internal promise attached to it, or the SLA is fiction.

For each dependency, ask three questions. Who owns this step? (the team or vendor on the hook). How long can they take? (the OLA or contract target). Do those targets, added up, fit inside the SLA? If support gets two hours to diagnose, engineering gets four to fix, and support gets one to verify and close, that is seven against an eight-hour SLA — tight, but it holds. If engineering's realistic OLA is eight hours on its own, the SLA was never achievable and no amount of support heroics will save it. This is also where a CMDB earns its keep: knowing which service a ticket touches tells you instantly which OLAs and which vendor contracts are in play.

Write OLAs support can actually hold the other team to

A good OLA reads like a small, testable SLA, because that is exactly what it is. Vague mutual goodwill ("engineering will help support promptly") is worthless the first time a deadline is missed. Make each one concrete:

• A trigger. What event starts the clock — a high-priority escalation, a specific ticket type, a priority-matrix level. No ambiguity about when the OLA applies.
• A target. Acknowledge within X, status update every Y, resolution-input within Z. Measurable, in the same time units as the SLA it supports.
• An owner. A team and an on-call path, not a person who might be on holiday. The OLA should plug into the other team's own on-call rotation so there is always someone accountable.
• A path when it slips. What support does when an OLA is about to breach — re-escalate, page a manager, invoke a priority override. An OLA with no enforcement is a suggestion.

Crucially, OLAs are a two-way agreement, negotiated, not imposed. Support cannot simply declare that engineering owes it a thirty-minute response; engineering has to agree the target is realistic given its own load, and that agreement is what makes the OLA hold up when it matters.

Measure breaches at the link, not just the end

The payoff of formalizing the chain is diagnostic. When an SLA breaches, SLA-compliance reporting tells you that you missed; OLA tracking tells you where. If high-priority resolutions keep breaching and the data shows the support steps finished on time but the engineering-OLA leg consistently overran, you have a precise, defensible answer to "why are we breaching?" — and a specific OLA to renegotiate or a specific team to resource, rather than a vague sense that support is too slow.

This reframes the SLA conversation from blame to systems. Instead of "support breached again," the weekly report to leadership can say "we breached the eight-hour resolution SLA four times; in all four the engineering OLA overran, which means either the OLA target is wrong or engineering is under-resourced for escalations." That is a problem the business can actually fix, and it gets support out of carrying the blame for delays it never controlled — which is also how support stops absorbing churn risk it cannot prevent.

The honest test

Your OLAs and underpinning contracts are working when an SLA breach is rare and, when it happens, instantly explainable: you can point to the exact link in the chain that slipped, and you already have the agreement and the data to fix it. The deeper test is whether your SLA targets are ones the whole dependency chain has signed up to deliver, not numbers support promised and now privately dreads. If instead breaches arrive as a surprise, the post-mortem is a finger-pointing exercise, and nobody can say whether the SLA was even achievable in the first place, you have an SLA resting on hope rather than on promises that hold. Hitt Hosting Desk lets you encode SLA targets and escalation paths per priority and ticket type, and surfaces breach attribution in reporting so you can see which leg of the chain is costing you the breach — and fix the link instead of blaming the queue.