Every mature service relationship eventually needs a written answer to an awkward question: exactly how good will this service be? "We'll do our best" satisfies nobody — the business can't plan around it and IT can't be fairly judged by it. Service level management is the practice of making promises properly: explicit, measurable, and — the hard part — actually keepable.
The three-letter family
- SLA — Service Level Agreement. The promise between IT and its customers: "priority-1 incidents responded to within 15 minutes, resolved within 4 hours; service available 99.9% of business hours." Targets, measurements, and what happens when they're missed.
- OLA — Operational Level Agreement. The internal promises that make the SLA possible: the network team commits to the service desk, the server team to the application team. Invisible to customers, load-bearing all the same.
- Underpinning contracts. The same promises from external suppliers — the ISP, the cloud provider, the hardware vendor with the 4-hour parts contract.
Here's the discipline the family enforces, and where beginners' eyes should narrow: an SLA is only as strong as what underpins it. Promise customers 4-hour resolution while your hardware vendor's contract says next-business-day parts, and you've signed a promise arithmetic already broke. Mapping every SLA to its supporting OLAs and contracts is the unglamorous audit that separates promises from wishes — and it's the four-dimensions model (dimension three: partners and suppliers) earning its keep.
Vocabulary that prevents real arguments
Response time is when a human meaningfully engages with the ticket; resolution time is when service is restored. Users routinely hear the first number and expect the second — a 15-minute response promise is not a 15-minute fix promise, and every service desk veteran has had that conversation. Availability percentages deserve equal suspicion: 99.9% sounds like perfection and permits roughly 8.7 hours of downtime a year (or ~43 minutes monthly). Whether that's measured across all hours or business hours changes the promise enormously. Precision here isn't pedantry; it's the difference between an agreement and a future dispute.
The trap with the memorable name: the watermelon SLA — green on the outside, red on the inside. Every metric on the dashboard is met, yet customers are furious: tickets closed within target but reopened three times; responses on time but useless; availability technically achieved while the service crawled. It happens because metrics measure what's countable, not what's valuable — and people optimise what's measured. ITIL 4's correction is watermelon-proofing: pair the operational numbers with experience measures (satisfaction, outcome achieved) so the dashboard can't be green while the humans are red. When you hear "XLAs" — experience level agreements — this is the idea being sold.
The craft, distilled: promise slightly less than you can deliver, measure what customers actually feel, and check the promises underneath your promises. Organisations that do this look boring and reliable. That's the compliment.