An SLA Is a Promise, Not a Wish
A service level agreement earns its name from the first word: agreement. It is a promise the service organization makes to the business about speed and quality, and like every promise it has exactly two failure modes, overpromising and underpromising. Overpromise and the desk lives in breach reports, morale dies, and the business learns to ignore the numbers. Underpromise and the desk looks great while quietly taxing every process that waits on it. The craft of setting SLA targets lives in the narrow, honest band between ambition and physics.
The starting posture matters more than any single number. A target is not a wish sent to the universe, it is a capacity commitment with a measurement system attached, which means every target you publish must be derivable from three things: what the business actually needs, what the roster can actually deliver, and what the tools can actually measure. Get those three in one room before drafting a single number, and the rest of this playbook is arithmetic.
Start From the Business Clock, Not the IT Clock
The most common SLA design error is working from the service desk outward: 'we can respond in four hours, so priority 2 response is four hours'. The correct direction is inward from business impact: payroll fails on the 28th, so an issue that blocks payroll on the 27th carries a clock measured in minutes, regardless of what the queue looks like. Sit with each business function, list their critical processes, and attach a cost to an hour of downtime. The numbers do not need to be precise; they need to be agreed, because agreed costs turn SLA negotiations from opinion fights into arithmetic.
That impact conversation produces the priority matrix, the load-bearing table of every SLA. Impact (how many people, how critical the process) crossed with urgency (does the business clock care today) yields the priority tiers, and each tier inherits its targets from the business clocks you just collected. The table below shows the canonical shape. Publish it with the SLA, because the matrix is what stops the Monday-morning argument about why a single-user printer issue is not a priority 1.
| Priority | Definition | Typical response | Typical restoration |
|---|---|---|---|
| P1 Critical | Business process stopped, many users or money path blocked | 15-30 min | 2-4 hours |
| P2 High | Major function degraded, workaround painful or absent | 1-2 hours | 8 business hours |
| P3 Medium | Single user or minor function blocked, workaround exists | 4-8 business hours | 2-3 business days |
| P4 Low | Requests, questions, scheduled changes | 1-2 business days | 5-10 business days |
Source: Common ITIL-aligned patterns; set final numbers from your own business-impact interviews.
Set Targets You Can Staff
Every target has a payroll signature, and this is where SLA design becomes honest or dies. Response targets are coverage math: to respond to P1s within 30 minutes across a 12-hour business day, someone with the authority and access to triage must be within reach of the queue every one of those minutes, which means shifts, not heroics. Resolution targets are capacity math: a desk closing an average of 6 tickets per engineer-day cannot promise same-day restoration on a volume that arrives faster than that, no matter what the matrix says.
Run the arithmetic before publishing: expected P1/P2 volume per week, average handling time by tier, roster hours by coverage window, and the resulting feasibility line for each target. Where the business wants a target the staffing cannot meet, the conversation is a price tag, not a refusal: this response time costs 1.5 more heads or an automation investment, choose. Desks that skip this step learn the hard way that an SLA the roster cannot meet trains the whole organization to stop believing numbers, which is a cost no budget line captures.
- Response targets are coverage math: someone triage-capable, every minute of the promised window
- Resolution targets are capacity math: close-rate times roster versus arrival rate
- Publish the feasibility line with each target so negotiations have a price tag
- Renegotiate after every major volume or tooling change, in writing
Underpromise by Design: Attainment, Buffers, and Error Budgets
Targets and attainment are different numbers, and confusing them is the second classic error. If P1 response is 30 minutes, the attainment target is not 100%, it is typically 90 to 95%, because real operations carry variance: the outage that coincides with the outage, the engineer who is mid-escalation, the holiday roster. Publishing '95% of P1s acknowledged within 30 minutes' is more honest and more useful than 'all P1s acknowledged within 30 minutes', and it gives the review meeting a threshold with meaning instead of a breach lottery.
Borrow the error budget concept from site reliability engineering: the gap between attainment target and 100% is a budget you get to spend, deliberately, on maintenance, experiments, and bad luck. A desk at 94% against a 95% target has spent its budget on something; the review asks what, and whether the spend was worth it. This reframes misses from moral failures into information, which is precisely what keeps the SLA system alive after its first bad month.
The Numbers Worth Memorizing
Four numbers anchor target-setting conversations. Coverage: a 30-minute P1 response across a 12-hour day needs triage-capable presence roughly every one of those minutes, which is a shift roster, not an intention. The priority spread: the canonical matrix above, 15-30 minutes for P1 response against 1-2 days for P4, keeps the tiers meaningfully different. Attainment targets of 90 to 95% leave honest room for variance. And the monitoring lead: thresholds that fire when 70% of a ticket's clock is consumed convert breaches into saves, which is the difference between reporting misses and preventing them.
Instrument accordingly: our walkthrough of building an SLA thermometer gives the early-warning build, and the IT service desk statistics roundup provides external benchmarks to sanity-check the targets against peers. Remember the direction of the argument in every review: the targets exist to protect the business's time, and the numbers that prove it are response, restoration, and attainment, reported together or not at all.
Sources: ITIL-aligned practice benchmarks · Service management practice · SLA early-warning practice
From Document to Operating System
The SLA document is finished in week one; the SLA operating system is built over a quarter. Weekly: one page per service, response, restoration, attainment, and the near-miss list from the thermometer, reviewed with the same seriousness as financial numbers. Monthly: the exception log (what the exclusions caught, whether any exclusion is becoming a pattern) and the error-budget conversation. Quarterly: attainment trends by tier and a candid check of whether the business clocks have moved. Annually: the formal renegotiation, targets and exclusions together.
Two habits keep the system honest. First, never let an exclusion grow quietly: every exclusion is a place the promise does not reach, and it needs the same visibility as the promise. Second, celebrate saves as loudly as results: a P1 answered at minute 22 because the thermometer fired at hour one is the system working, and the desk that hears about its saves believes in the numbers. For the complete skills arc, the fifteen-day IT Service & Support Excellence program trains SLA design alongside demand analysis and incident command with daily missions on your own desk.
Frequently asked questions
▸What are SLA targets, in plain terms?
Published promises about service speed and quality: how fast you will acknowledge an issue, how fast you will restore it, and how often you will hit those marks. A usable SLA has three parts, the targets, the measurement method, and the exclusions, and a missing third part is how every dispute starts.
▸How do you choose response and resolution times?
Work backwards from business impact, not forwards from IT convenience: ask what an hour of downtime costs each business process and let the money set the clock. Then sanity-check against staffing math, because a promise the roster cannot physically meet is a lie with a document number. Our priority matrix section walks the derivation step by step.
▸What is the difference between response and resolution targets?
Response targets measure acknowledgement: a human looked, triaged, and the clock started honestly. Resolution targets measure restoration: the user can work again. Confusing the two is the most common SLA design error, because desks that only publish response targets can look green all year while users wait days for fixes.
▸Should SLA targets be 100%?
No, and demanding it guarantees either failure or fraud. Real operations carry variance: vacations, vendor outages, holidays, bad luck. Set attainment targets that leave room for reality, commonly 90 to 95% per priority tier, and manage the exceptions explicitly through the error budget concept described below rather than pretending variance away.
▸How often should SLA targets be reviewed?
Formally once a year with the business, informally every quarter against data: attainment trends, volume shifts, and any process changes that moved the achievable frontier. An SLA nobody renegotiated in three years is either impressively stable or quietly fictional, and the attainment data will tell you which.
▸How do you monitor SLAs without drowning in dashboards?
Instrument thresholds, not just outcomes: an SLA thermometer that warns while a ticket still has 30% of its clock left converts breaches from surprises into saved saves. One page per service, reviewed weekly, beats a dashboard farm nobody opens.