An SLA is the promise you make to whoever raised the ticket. OLAs and Underpinning Contracts are the supporting commitments underneath it — a third, distinct agreement type alongside SLA Policies and the Vendor SLAs on your Customers & Vendors page, each answering a different question:
- SLA Policy — the customer-facing promise on an incident (already covered under SLA & On-Call).
- Vendor SLA — a general contractual metric you track by hand on a vendor record, like an uptime guarantee (already covered under Customers & Vendors).
- OLA (Operational Level Agreement) — an internal support group's own commitment, like "L2 Network resolves Critical in 4 hours," with automatic breach detection.
- UC (Underpinning Contract) — the same idea as an OLA but for a specific external vendor tied to individual incidents, also with automatic breach detection.
Setting one up
From OLAs & Underpinning Contracts, click + New OLA or + New Contract. An OLA needs a name, the support group it applies to, which priority (or all of them), response and resolution time targets, and whether it only counts business hours. A UC needs a contract name, vendor name, contract reference, response/resolution targets, support hours, and an escalation contact.
Automatic breach tracking
Unlike a Vendor SLA, both of these are checked automatically against open incidents, and a breach posts to your configured Slack channel if one's set up. Breach activity shows up on the Governance dashboard's incident view alongside your regular SLA breach stats.
Example
A customer-facing SLA promises 4-hour resolution on critical incidents. Underneath it, an OLA commits the internal network team to a 2-hour piece of that, and a UC commits an external circuit provider to a 1-hour piece — if the network team's OLA breaches on its own, that surfaces well before the customer-facing SLA itself is actually at risk, giving a manager time to intervene.