How to write an SLA your team can actually meet
Most SLAs are missed because of how they were written, not how the team performed. Here is how to set targets you can defend, and the three mistakes that cause almost every dispute.
An SLA is a promise with arithmetic attached. Most of the ones we see fail at the arithmetic long before the team gets a chance to fail at the promise — and once a target is unmeetable by construction, everybody quietly stops believing in the whole thing.
Here is how to write one that survives contact with a real week.
Start with business hours, not with targets
This is the single most common mistake, and it is not close. A team publishes "resolved within 24 hours", means 24 working hours, and never says so. A requester reads it and means 24 hours.
On a Wednesday morning those two readings are nearly the same. On a Friday evening, with a 9:30 to 18:30 week, a 24-business-hour target comes due on Wednesday afternoon — five calendar days later. The desk has met its target. The requester has waited most of a week and thinks you broke your promise. You are now having an argument that neither side can win, about a number you chose.
Fix it by deciding your working hours and holidays first, and by writing which kind of hour you mean everywhere the target is published. Both are five-minute jobs and they prevent most SLA disputes outright.
Four priorities, and no more
Every desk that starts with six priorities ends up using two. People cannot reliably tell P2 from P3 at eight in the morning, so they pick the one nearest the top and the distinction stops meaning anything.
Four works because each one has an obvious sentence attached to it:
| Priority | The sentence that decides it | Response | Resolution |
|---|---|---|---|
| P1 | Nobody can work, or money is actively being lost | 15 minutes | 4 business hours |
| P2 | One team is blocked, or a person cannot do their job at all | 30 minutes | 8 business hours |
| P3 | Something is broken but there is a way round it | 4 business hours | 24 business hours |
| P4 | A request, a question, or something that can wait | 8 business hours | 72 business hours |
Notice that the deciding factor is impact, not who asked. The moment seniority sets priority, your SLA is measuring your organisation chart rather than your service.
Pause the clock, or you will breach tickets you did nothing wrong on
A ticket where you asked a question three hours ago and are still waiting for an answer is not a ticket you are failing. If the clock runs while you wait on the requester, your SLA report becomes a measure of how quickly your colleagues read email, and your team learns to stop asking clarifying questions — which makes the service worse, not better.
Any decent tool pauses the clock on a pending-requester status. Make sure yours does, and make sure the pause is visible on the ticket so nobody has to take it on faith.
Measure first response separately from resolution
These are different promises and they fail for different reasons. A slow first response is usually a triage or staffing problem. A slow resolution is usually a skills, access or dependency problem. Averaging them into one number tells you nothing you can act on.
And be careful what counts as a first response. An automated acknowledgement is not one. If your metric can be satisfied by a robot, it will be, and the number will improve while the service does not.
Set targets from your own data, not from a framework
If you already handle requests somehow — a mailbox, a spreadsheet, a WhatsApp group — you have data. Take a month of it, work out what you actually achieve at the 80th percentile, and set your first target slightly worse than that.
That sounds defeatist. It is not: a target you beat consistently gives you room to tighten it in public, which builds trust. A target you miss from day one teaches everybody that the SLA is decoration.
Publish what happens when you miss
An SLA with no consequence is a wish. The consequence does not have to be a penalty — for an internal desk it usually should not be. It can be: a breach raises the priority, notifies a manager, and appears in a weekly review.
What matters is that the breach does something visible. A breach that only changes a colour on a dashboard will be ignored within a fortnight.
Review it once a quarter, in public
Bring three numbers: percentage met, the worst ten tickets and why, and what you are changing. If a target is being missed consistently for a structural reason — you have one Windows specialist and she takes leave — say so and change the target or the structure. Quietly missing it every month is the worst of both.
A checklist you can use this afternoon
- Write down your working hours per weekday and your holiday list.
- Define four priorities, each with one sentence that decides it.
- Pull a month of real data and find your 80th percentile.
- Set first-response and resolution targets separately, slightly worse than what you already achieve.
- Confirm the clock pauses while you are waiting on the requester.
- Decide what a breach triggers, and make it visible.
- Publish the whole thing where requesters will see it, saying "business hours" in as many words.
- Put a quarterly review in the calendar now, while you still care.
Business hours, Indian holidays, pausing clocks and a panel on every ticket that explains exactly how its deadline was reached. See how SLAs work here