An SLA is the external promise you make to a customer. An OLA is the internal promise your teams make to each other so that external promise can actually be kept. Get that distinction wrong and accountability collapses: SLAs expose risk to the customer, while OLAs assign responsibility internally, and confusing the two is how breaches happen without anyone noticing until the invoice dispute lands. ITIL's service design guidance treats both as formal artefacts, measured through SLOs and SLIs, not vague intentions. A platform like Oakandnine exists precisely to keep those internal ownership lines visible before they become customer-facing problems.
Key Takeaways
An SLA sets the external, measurable promise to a customer, while an OLA defines the internal handoffs and ownership that make delivering on that promise possible.
| Point | Details |
|---|---|
| SLA faces outward | It sets customer-facing targets like uptime, response time, and resolution time, backed by remedies. |
| OLA faces inward | It assigns named owners and handoff windows between internal teams supporting the SLA. |
| Layer in underpinning contracts | UCs cover vendor commitments and must fit inside OLA and SLA timing windows. |
| Validate before publishing | Test SLO and OLA targets against historical ticket data, not estimates. |
| Map dependencies to reduce risk | Oakandnine gives teams a live view of ownership and timing gaps before they cause SLA breaches. |
Table of Contents
- What is a service level agreement (SLA)?
- What is an operational level agreement (OLA)?
- Key differences: SLA vs OLA side by side
- Common SLA types and when to use each
- How to write an OLA: a practical step-by-step guide
- How SLAs, OLAs and underpinning contracts fit together
- Measuring SLAs and OLAs: SLIs, SLOs and reporting
- Best practices and common pitfalls
- Quick SLA and OLA template and checklist
- Author's perspective: removing silos before they cause breaches
- How a connected platform helps you align SLAs and OLAs
- Frequently asked questions
- Sources
What is a service level agreement (SLA)?
A service level agreement is a formal, external document between a provider and a customer that sets measurable expectations for a service, typically covering availability, response time, and resolution time. It is the contract your customer reads when they want to know what happens if something breaks.
A well-drafted SLA usually includes:
- Scope and service description — exactly what is covered and, just as importantly, what is not.
- Service hours — when support is available, including time zones and exceptions for holidays.
- SLOs and SLIs — the measurable targets (service level objectives) and the metrics used to track them (service level indicators).
- Escalation paths — who gets notified, and when, if a target is missed.
- Penalties or remedies — service credits, refunds, or contract review triggers.
- Reporting cadence and signatories — how often performance is reported and who signs off on the agreement.
Here is a typical customer-facing clause covering response time and escalation:
The best SLAs are negotiated, not imposed. They should reflect what your teams can genuinely deliver, not what sounds impressive in a sales pitch, and every target should map to a customer outcome rather than an internal technical task the customer never sees.
What is an operational level agreement (OLA)?
An operational level agreement documents how internal teams or departments will coordinate, hand off work, and hit the timings needed to meet an SLA commitment. Where an SLA faces the customer, an OLA faces inward, defining who does what, by when, so the outward promise holds up.
Typical OLA elements include:
- Named owners for each activity or handoff, not just a team name.
- Handoff windows — the maximum time allowed between one team finishing its part and the next starting.
- Internal escalation chains distinct from the customer-facing one in the SLA.
- Dependencies on third parties that the OLA needs to account for even though it cannot control them directly.
- Monitoring points where progress is checked against the agreed timing.
A short internal clause might read:
Unlike an SLA, an OLA is rarely a legally binding contract. It is an operational document, revised through internal governance rather than legal negotiation, and it should change whenever the underlying service or team structure does.
Key differences: SLA vs OLA side by side
The clearest way to see how these agreements diverge is to line them up across the dimensions that actually cause disputes: who they bind, what they measure, and how visible the reporting is.
| Dimension | SLA | OLA |
|---|---|---|
| Scope/audience | External, customer-facing | Internal, team-facing |
| Who signs/owns | Provider and customer, often legal or account teams | Team leads or service owners across departments |
| Typical metrics | SLOs/KPIs: uptime %, response time, resolution time | SLIs: handoff time, acknowledgement time, queue ageing |
| Enforcement/escalation | Contractual remedies, service credits, formal review | Internal escalation chain, managerial follow-up |
| Reporting visibility | Shared with the customer, often via a portal or report | Internal dashboards, rarely seen outside operations |
| Example use case | "99.9% uptime guaranteed" | "Database team hands off diagnostics within 20 minutes" |
A few distinctions matter more than the rest:
- The SLA is the promise; the OLA is the machinery that keeps the promise honest.
- A breached OLA does not always breach the SLA immediately, but it usually explains why one eventually will.
- Customers rarely see an OLA, yet its quality determines whether the SLA they did see means anything.
Mismatched timings between the two layers are the single most common cause of SLA breaches. If your SLA promises a 4-hour resolution but the OLAs stacked underneath it total 5 hours of internal handoffs, you have built a target you cannot hit. This is where a live organisational model earns its keep, because it makes those stacked timings visible before a customer finds the gap for you.
Common SLA types and when to use each
Not every customer relationship needs the same kind of SLA. Three types dominate ITSM practice, and choosing the wrong one creates either unnecessary overhead or dangerous ambiguity.
- Customer-based SLAs cover all services used by a single customer under one agreement, suitable for highly customised relationships.
- Service-based SLAs apply the same terms to every customer using a given service, typically used for standardised offerings.
- Multi-level SLAs split commitments across multiple tiers within one framework, used by organisations with varied service portfolios.
If your customer base is small and each account is bespoke, start with customer-based agreements. If you are selling a standardised product to many accounts, service-based SLAs cut drafting time significantly. Multi-level agreements suit organisations already large enough that a single flat SLA structure would obscure more than it clarifies.
How to write an OLA: a practical step-by-step guide
Drafting an OLA well means starting from the SLA and working backwards, not the other way round.
- Identify the SLA dependencies. List every internal step required to meet each customer-facing target.
- Map teams and owners. Assign a named owner to each step, not a department.
- Define handoff windows and SLIs. Set the maximum time allowed at each stage and the metric that will prove it happened.
- Set internal escalations. Decide who is notified, and how fast, when a handoff window is missed.
- Agree reporting and review cadence. Fix how often the OLA is checked and by whom.
A sample internal handoff clause worth adapting:
Governance matters as much as drafting. Get buy-in from team leads before publishing, since an OLA imposed without their input tends to get quietly ignored the first time it's inconvenient. Version control the document, and set a review cycle, ideally quarterly, tied to actual service changes rather than a calendar default.
Pro Tip: Before finalising any OLA timing, pull three months of historical ticket data and check whether your proposed handoff windows have ever actually been met. A target nobody has hit in the past quarter is not a target, it's a wish.
How SLAs, OLAs and underpinning contracts fit together
Most service delivery chains have a third layer that rarely gets discussed alongside SLAs and OLAs: the underpinning contract, or UC. A UC is an external agreement with a third-party vendor that supports your ability to deliver the OLA, which in turn supports the SLA. UCs carry the legal weight of a vendor contract, generally stronger than an internal OLA but structured similarly to an SLA in reverse, since you are now the customer.
The layered model runs like this:
- SLA — what you promise the customer.
- OLA — what your teams promise each other to deliver that SLA.
- UC — what your vendors promise you to support the OLA.
Organisations typically need all three layers working in concert; treating any one in isolation is how gaps appear. Picture them stacked on a single timeline: if your SLA promises a 4-hour fix, your OLA windows and your vendor's UC response time must together fit inside that 4 hours, with margin, not exactly at the edge of it.
Before signing off on any SLA renewal, check that OLA and UC timings genuinely aggregate within the SLA window, that vendor SLAs referenced in a UC haven't quietly changed, and that nobody has added a new dependency without updating the chain above it.
Measuring SLAs and OLAs: SLIs, SLOs and reporting
An SLI, or service level indicator, is the metric you actually measure. An SLO is the target value set for that metric. Together they give the SLA and OLA their teeth; without them, both documents are just aspirational prose.
Useful SLA-side metrics include availability percentage, mean time to respond, and customer satisfaction scores. OLA-side metrics look different because the audience is internal: handoff time between teams, queue ageing on unresolved tickets, and internal acknowledgement time all matter more than anything customer-facing.
Reporting should split cleanly by audience. Customer reports need to show SLA performance against agreed targets, usually monthly or quarterly. Internal dashboards should track OLA performance in near real time, since that is where problems get caught before they become customer-visible breaches. Escalation triggers need defining in both directions: what counts as "at risk" for an SLI, and who gets alerted automatically when a threshold is crossed.
Validate OLA timings against real ticketing or monitoring data before you commit to them externally. A connected system integration approach that pulls data from across ticketing tools, monitoring platforms, and team calendars gives a far more honest picture than asking each team lead to estimate their own performance.
Best practices and common pitfalls
Getting SLAs and OLAs to work together in practice comes down to a handful of disciplines, most of which get skipped under deadline pressure.
What works:
- Start from actual team capability, not aspiration, when setting SLOs.
- Map every dependency an OLA relies on, including third-party UCs, before publishing it.
- Schedule reviews on a fixed cadence rather than waiting for a breach to trigger one.
- Assign a single named owner per OLA activity, never a shared department inbox.
What causes breaches:
- Timings that don't align across the SLA, OLA and UC layers.
- Ownership left vague enough that nobody feels accountable when something slips.
- Sales or account teams over-promising SLA terms without checking OLA feasibility first.
- OLAs that were accurate a year ago but never updated after a team restructure or tooling change.
Pro Tip: Run a stress test using your worst month of ticket data, not your average month, before publishing new OLA targets. Averages hide the exact failure patterns that will eventually breach the customer SLA.
Pro Tip: Treat OLA review as a standing agenda item in operational leadership meetings, not an annual audit exercise. Services change faster than annual reviews can track.
Quick SLA and OLA template and checklist
A minimal SLA template should cover: service description, scope, SLOs, reporting cadence, escalation paths, remedies, and signatories. Keep it tight enough that a customer can read it in one sitting.
An OLA template needs: named activity owners, handoff windows, internal SLIs, escalation chain, and review cadence. Skip anything that reads like legal boilerplate; this is an operational document, not a contract.
Before signing off on either, run this checklist:
- Has every SLI been validated against at least three months of historical data?
- Have all stakeholders across affected teams signed off, not just their managers?
- Do OLA and UC timings genuinely fit inside the SLA window with margin to spare?
- Is there a documented review date already on the calendar?
Author's perspective: removing silos before they cause breaches
The pattern I keep seeing in ITSM teams is not bad intentions, it's invisible dependencies. An OLA gets written, a UC gets renewed, and nobody notices they've drifted out of alignment until a customer escalation forces the conversation. Mapping responsibilities into a live organisational model changes that dynamic, because dependencies stop living in someone's head or an outdated spreadsheet and start showing up as data.
Real-time visibility across teams and vendors means you can see exactly where an SLA target and an OLA window no longer agree, before a customer does. That's the real value of connecting people, process, and system data: not automation for its own sake, but the ability to catch a misalignment while it's still an internal problem rather than a breach notice.
How a connected platform helps you align SLAs and OLAs
If you have read this far, you already know the hard part of SLA and OLA management isn't the drafting, it's keeping every layer honest as teams, vendors, and workloads shift underneath the paperwork. Oakandnine maps those dependencies in one live model, so a change to a team's capacity or a vendor's contract shows up as a visible risk to an SLA target, not a surprise three months later.
Rather than tracking OLA handoffs across separate spreadsheets and ticketing exports, Oakandnine gives operations managers and IT leaders a single view of who owns what, how long each handoff actually takes, and where a UC dependency might be quietly stretching an SLA window past breaking point. It pairs the platform with consulting support for teams that want help translating existing SLAs into workable OLA structures rather than starting from a blank template. If your current OLAs were last reviewed before your last reorganisation, that's worth fixing before your next SLA renewal. Visit Oakandnine to see how a pilot mapping of your organisation could work.
Frequently asked questions
Is an OLA legally binding like an SLA? Usually not. An OLA is typically an internal operational document revised through governance processes, while an SLA is a formal contract with the customer, often carrying financial remedies.
Can a single SLA rely on multiple OLAs? Yes, and most complex services do. A single SLA commitment often depends on OLAs from several teams, such as network operations, application support, and vendor management, each covering a different segment of the delivery chain.
What happens when an OLA is breached but the SLA isn't? It's a warning sign. The SLA may survive this time because of built-in buffer, but a pattern of OLA breaches usually predicts an eventual SLA failure unless the underlying timing or ownership issue gets fixed.
How often should OLAs be reviewed? Quarterly is a reasonable default, but any significant team restructure, tooling change, or vendor contract renewal should trigger an immediate review rather than waiting for the scheduled one.
Do underpinning contracts need to match SLA language exactly? Not exactly, but their timings must aggregate correctly. A UC's response time commitment needs to leave enough margin, once combined with internal OLA handoffs, to still meet the SLA target the customer sees.
Sources
For deeper reading and sample clause structures, the ITIL v3 service design appendix offers a template-style breakdown of SLA and OLA sections worth borrowing from. ManageEngine's comparison guide covers practical drafting tips for both agreement types. For quick definitions, TechTarget's entries on the SLA and the OLA are concise primers. For the full three-layer picture including vendor contracts, this breakdown of SLA, OLA and UC is a useful vendor guide.