Operational level agreement: the internal promises an SLA depends on

An operational level agreement is an internal agreement between the teams inside one organisation that together deliver a service: what each will do, how quickly, during which hours, and what happens when they cannot. It has no customer in it. Its entire purpose is to make the commitments in the customer-facing service level agreement achievable.

The arithmetic is what makes the concept worth taking seriously. If support promises a four-hour resolution, and the change that fixes the problem has to pass an approval board that meets on Tuesdays, the SLA is not a target — it is a fiction that will be missed, reliably, in a way nobody in support can prevent.

What an operational level agreement defines

• The parties: which internal teams, named by function rather than by person.
• The services each provides to the other, in the terms the receiving team uses.
• Response and completion targets, with hours of cover — including whether that is business hours or around the clock.
• Priority definitions, matched to the ones used in the customer SLA.
• Escalation: who is called, after how long, and who can override a priority.
• Dependencies on third parties, and what happens when the delay is theirs.
• How performance is measured and reviewed, and by whom.

Priority definitions are the item most often skipped and most often the cause of failure. Where support calls something a P1 and infrastructure treats it as a normal request, the two teams are not disagreeing about urgency — they are using different scales, and no amount of escalation fixes a definition mismatch.

SLA, OLA and underpinning contracts

1. The SLA is the external promise to the customer.
2. The OLA is the internal chain of promises that make it deliverable.
3. Underpinning contracts are the external suppliers your delivery depends on — hosting, connectivity, a maintenance provider.
4. Work backwards: take each SLA target, decompose it into the steps that must happen, and check every step has a committed time from whoever performs it.
5. Where the arithmetic does not close, either the SLA changes or the internal commitment does. Publishing it anyway is a decision to fail on a schedule.

The most common gap is a supplier whose contracted response is slower than the promise you made to your own customer. That is not an operational problem to be managed with effort — it is a commercial mismatch, and it has to be fixed in one of the two contracts.

Keeping an OLA alive

OLAs go stale faster than SLAs because reorganisations change who owns what without anyone reopening the document. Tie the review to structural change rather than to the calendar: a new team, a moved responsibility, a changed supplier, a new product with different hours all invalidate parts of it.

And measure both sides. An OLA where only the customer-facing team is reported on becomes a stick rather than an agreement, and the teams behind it stop treating the numbers as theirs.

Because an OLA is an agreement between teams rather than a policy handed down, it needs to name responsibilities the way the organisation is actually structured. Ettex Teams holds the team structure and its responsibilities, so the agreement references roles that exist rather than a chart from two reorganisations ago. Whether the promised times are achievable is a management judgement — the document only makes the promise explicit enough to test.