Three agreements, three different pairs of parties, one chain. Most IT organisations have all three and have never checked whether they add up — which is how a team ends up contractually unable to deliver what it has promised.
An SLA is between you and your customer. An OLA is between you and another team inside your own organisation. An underpinning contract is between you and an external supplier. The SLA is the promise; the OLA and the UC are what make it deliverable. If the internal and supplier commitments do not fit inside the customer promise, the SLA is fiction before anything goes wrong.
The Three Agreements
| Parties | What it commits to | Enforceable by | |
|---|---|---|---|
| SLA | Service provider and its customer — external, or another business unit | Response and resolution targets for the service as the customer experiences it | The customer, often with credits or penalties |
| OLA | Two teams inside the same organisation | What each internal team will do, and how fast, so the SLA can be met | Management. No contract, no money — which is the weakness |
| Underpinning contract | The service provider and an external supplier | Supplier response, repair and availability commitments | Commercial contract, with real remedies |
Wikipedia’s definition of the OLA is the clearest one-liner available: an agreement “defining internal support relationships to underpin an SLA”. That word — underpin — is the whole idea. Neither the OLA nor the UC exists for its own sake. Both exist because something was promised upstream.
The Arithmetic Nobody Checks
This is the part the definitions pages leave out, and it is the only part that causes outages to become disputes.
Work an example. You promise the business a four-hour resolution on P1 incidents. That is the SLA. Underneath it:
- Your OLA with the network team says they will pick up an escalation within one hour and hand back within two.
- Your underpinning contract with the circuit provider gives them an eight-hour response window on a line fault.
Now a P1 is caused by the circuit. You are contractually unable to meet your own SLA, and no amount of effort from your team changes that. The failure was written into the paperwork months earlier, by different people, in different meetings.
The rule is simple and almost never applied: every chain of OLA and UC commitments that can sit beneath an SLA must sum to less than the SLA target, with slack for the handoffs between them. If it does not, you have not set a target, you have set a trap.
Why the Gap Appears
Because three different functions own the three documents, and they do not meet.
The SLA is usually written by service management, negotiating with the business. The underpinning contract is negotiated by procurement, where the objective is commercial terms and unit price. The OLA is, in most organisations, written by nobody at all — it exists as an assumption that the other team will help when asked.
Nobody in that sequence is responsible for checking that the supplier’s eight hours fits inside the customer’s four. It is discovered during a major incident, at the worst possible moment, in front of the people who agreed the SLA.
Auditing the Chain
The exercise takes an afternoon and is worth doing once a year.
- Start at the customer promise. Take your tightest SLA target — usually P1 resolution.
- List every party that can sit on the critical path. Internal teams, suppliers, anyone whose delay stops the clock running down.
- Write each one’s committed time next to it. Not what they usually do — what they have agreed in writing.
- Add the worst realistic path. If the total exceeds the SLA, you have a documented gap.
- Close it one of three ways. Tighten the supplier contract at renewal, change the SLA to something honest, or add an exclusion that names the dependency explicitly.
The third option is the one teams resist and the one that usually fits. An SLA that says “four hours, excluding time awaiting the circuit provider, whose contracted response is eight hours” is less comfortable to present and considerably more honest than one that quietly cannot be met.
Why OLAs Fail in Practice
Underpinning contracts tend to be honoured because money is attached. OLAs frequently are not, for three reasons worth knowing before you write one.
No remedy. When an internal team misses an OLA commitment, nothing happens. The only available escalation is to a shared manager, which most people will not use for a single ticket.
Not measured. Ticketing systems report against SLAs by default. Time spent waiting on a specific internal team is rarely broken out, so OLA breaches are invisible even when everyone can feel them.
Written once. An OLA agreed during a service design exercise and never revisited describes a team structure that may no longer exist.
The fix for the second one is practical: if your ticketing system can record which team a ticket was waiting on and for how long, OLA performance stops being an argument and becomes a number. That is the same measurement problem as separating first response time from resolution time — one clock, reported as a whole, hides where the delay actually sat.
When the Chain Breaks
One thing does not change regardless of which link failed: the customer holds you to the SLA. They have no relationship with your network team and no contract with your circuit provider. “The vendor missed their window” explains the delay; it does not transfer the commitment.
That is why the audit matters more than the paperwork. The breach gets recorded against your service whoever caused it — see what counts as an SLA breach for how that is recorded and reported, and the breach notification templates for the awkward one where a supplier caused it.
Where InfraCue Fits
InfraCue tracks SLA targets — response and resolution, per priority and optionally per category and sub-category — counted in working time against a per-customer schedule, and pauses the clock while a ticket waits on a user, an approval or a vendor. That last state is what makes supplier delay visible rather than absorbed. It does not model formal OLAs or underpinning contracts as separate objects; those remain documents you hold outside the tool. Pricing starts at $39 per month (₹2,999), with a 30-day trial and no credit card.
This guide is maintained by InfraCue, an IT operations platform with ticketing, SLA tracking and device monitoring in one console.