SLAs in Plain Words

"We need an SLA." The sentence arrives from a manager on a Tuesday, usually after a meeting, usually without a second sentence. Dana, who runs the three-person desk, nods and goes back to her chair. She writes on a sticky note: "Reply to every ticket within four hours. Fix the bad ones the same day." She puts it on the monitor where the whole desk can see it. By Thursday everyone on the desk is working to it. Two people from accounts have stopped by to ask what the yellow square says.

That sticky note is a service level agreement. It is short, it is missing a report, and it is held on by adhesive. But it is a written promise about how quickly the desk responds. That is the whole definition. This article is the first in our SLA Design series. It is for the administrator who has been asked for "an SLA" and suspects the question is bigger than the sticky note. It is also for the administrator who has one already that is breached daily and believed by nobody.

It covers what an SLA is and what it is not, and the two numbers at the heart of every one. It covers the rank that decides which numbers apply. It explains the clock the numbers run on, and why its behavior matters more than the numbers. It also covers the promise underneath them, who the document is for, and the smallest SLA that works. It ends with a one-page starter you can type up this afternoon. The sticky note, typed and dated, is most of the way there.

What an SLA Is

A service level agreement, or SLA, is a written promise about how quickly and how well the desk responds, measured and reported. Each word carries weight. Written, so it exists outside anyone's head. Promise, so it binds the desk and not the user. Measured, so there is a number at month end rather than a feeling. Reported, so someone other than the desk sees the number.

Every SLA has three parts, and a document missing one of them is a different kind of document. The promise is what the desk commits to: a reply within so long, a fix within so long, a warning when things slip. The clock is the rule for how that time is counted: which hours, which days, what stops it. The report is the regular statement of whether the promise was kept. A promise without a clock is a slogan. A promise without a report is a hope.

An SLA for an internal help desk is almost always short. That is because the people it binds and the people it serves share a building and a coffee machine. The one-page version at the end of this article is a complete SLA. The forty-page version with a glossary is also an SLA, in the way a cathedral is also a shelter from the rain.

What an SLA Is Not

An SLA is not a guarantee that a problem will be fixed in a given time. A help desk can promise when a human will look and when a human will report back, because those are under its control. It cannot promise when a failed drive's replacement will arrive, when a vendor will answer, or when the user will be free to test. A document that promises fix times for unknown problems is a document that will be wrong by Monday. The phrase "best endeavors" is what such a document says where a number should be, and it promises a mood.

An SLA for an internal desk is not a contract with penalties. Service credits and penalty clauses belong to the relationship between a customer and an outside provider. The Internal vs Outsourced Support series covers that world. Inside one organization, a penalty against the IT department moves money from one pocket to another and schedules a meeting about it. I have never seen one change a single Monday.

An SLA is not a stick. It is tempting to use the numbers to prove a technician slow or a user unreasonable. Both uses kill the document. The technician learns to close tickets early. The user learns to mark everything urgent. And the report stops describing anything real. The targets are a promise the desk makes to its users. When one is missed, the target itself is the first suspect. The rest of this series is largely about choosing targets that do not set anyone up.

The Two Numbers

Every SLA rests on two numbers, and they measure different things. The response target is how soon a human replies: not the auto-acknowledgment, a person, saying they have the ticket and what happens next. The resolution target is how soon the problem is fixed or the request fulfilled, with the user agreeing it is done. The first is about attention. The second is about outcome.

Users feel the response target far more than the resolution target, which surprises most administrators the first time they read the ratings. A ticket answered in ten minutes and fixed in a week rates better than a ticket fixed in an hour with no word until then. Silence is what people rate. The sibling article Response Targets vs Resolution Targets takes both numbers apart. It also covers the two further targets most desks forget: the update interval while a ticket waits, and the reply to each later message.

Set the response target first, and set it much tighter than the resolution target. The response target is the one you fully control. So it is the one you can keep every time. Keeping it buys patience on the other. Miss it, and the user starts the ticket already doubting you, which no fix time repairs.

The Rank That Picks the Numbers

Priority is the rank that decides which targets apply to a ticket. It is set from two questions: how many people are affected, and how soon it hurts. A fault that stops a department before a deadline gets the tightest targets. A question about a nicer font gets the loosest. Priority is the only reason an SLA has more than one row.

Four tiers are enough for a small desk, and five is the most it can tell apart. Each tier needs a written test the triager can apply in ten seconds, plus two examples. The desk assigns it after a human look rather than letting the form decide. The sibling article Priority Tiers That Are Realistic builds the ladder. This article only needs you to know that the ladder exists and that it is short.

I once wrote an SLA with five priorities and four targets each, a grid of twenty cells, laminated. Nobody on the desk could recite three of them. Neither could I, and I had chosen the font.

The Clock

Business hours are the hours the SLA clock runs. Every target is counted in them unless the document says otherwise. A four-hour response target with business hours of 08:00 to 17:30 has a particular consequence. A ticket opened at 17:00 on Friday is due an answer by 11:30 on Monday, not by 21:00 on Friday. Write the hours into the document, with the holidays, because every argument about a breach begins with two people counting hours differently.

Two things stop the clock in any sane design: time outside business hours and public holidays. A third thing may or may not stop it, depending on the tool. That is time the ticket spends on hold, waiting for the user to answer or for a part to arrive. Some SLA engines pause the clock when a ticket is placed on hold. Some do not. A clock that never pauses will record a breach on a ticket that waited five days for the user to return from leave. The breach will be real in the report and unfair in every other sense.

Know how your tool's clock behaves before you set a single number. That is because the numbers must suit the clock you have. QuerySolv's documented limit, for example, is that its SLA clock does not pause on hold. Only non-working hours and holidays are excluded. On a clock like that, a resolution target has to leave room for the waiting. Or the waiting has to be handled by a stated rule such as closing after a fixed period of silence. On a clock that pauses, the target can be tighter. On that clock, the hold status has to be used honestly or it becomes a place to hide. Either way, the document should say which kind of clock it runs on.

The clock that runs through the weekend is the oldest SLA failure there is. A target set in calendar hours by someone who never met the queue breaches at 02:00 on Sunday, when nobody has done anything wrong except go home.

The Promise Behind the Numbers

The numbers are the visible part of the SLA, but the promise underneath them is what users actually receive. To the user, the SLA says: you will hear from a person by a known time, you will be told what happens next, and you will be told if that changes. That is everything a user wants from a help desk on the day the laptop dies. The fix matters, but the fix was always coming. The knowing is what the SLA adds.

To the desk, the SLA says what order to work in. Without one, the queue sorts by age, by volume, or by whoever walked over. Without an SLA, a technician with eleven open tickets picks the interesting one. With targets attached to priorities, the next ticket to touch is the one nearest its deadline. Nobody has to defend the choice. That is a relief, not a constraint. The desk gets to stop arguing with itself.

The third promise is the one that turns a target into a relationship: we will tell you if we are going to miss it. A target missed with warning is a delay. A target missed in silence is a breach, discovered by a user who went to check. The warning costs one sentence, and it is the most valuable line in the document. Meridian Parts found that out, and the war story later in this article is about it.

Who the SLA Is For

The SLA is for the user first. That is why it should be written in the second person and fit on a page. The user reads it once, probably from a link in the acknowledgment e-mail. They need to come away with one fact: when they will hear from someone. If the document cannot deliver that fact in its first three lines, it was written for somebody else.

The desk is second. The desk reads the SLA weekly, mostly as a table of priorities and targets on the wall or in the tool. The desk uses it to decide what to pick up next and when an update is due. For the desk the document is an operating instruction. The test is whether a new technician could work the queue correctly from it on their second day.

Management is third, and management reads the report rather than the SLA. The monthly numbers answer the question that produced "we need an SLA" in the first place, which was almost never about the document. It was about whether the desk is coping, whether it needs people, and whether anyone is checking. A one-page SLA with a monthly report answers that better than a long SLA with none. The long SLA without a report gets filed, and filing is where documents go to be believed by nobody.

The Smallest SLA That Works

The smallest SLA that works is one page with four rows. It beats most longer ones because people can hold it in their heads. It has a promise paragraph, a clock paragraph, and a targets table with one row per priority. It also has a line on how to escalate, a line on how the desk reports, and a line on when it is reviewed. Everything else is detail that belongs in the desk's runbook.

Here is how it runs on one ticket. Acme has a three-person desk, business hours of 08:00 to 17:30, and the starter SLA printed below. At 14:10 on a Thursday, Tomas in sales e-mails: the quoting tool will not open, and he has a quote due on Monday. The ticket is number 4471. Dana triages it at 14:35 as Normal. That is because one person is slowed and a workaround exists (a colleague can run the quote). Normal carries a four-hour response target and a three-business-day resolution target. Four business hours from 14:10 runs to 08:40 on Friday, because the clock stops at 17:30. Dana replies at 14:40: "I have this. You will have an answer from me by the end of tomorrow at the latest." Response target met, with thirty minutes used.

On Friday at 10:20 Dana finds a corrupt settings file, replaces it, and Tomas confirms the tool opens at 10:45. The resolution target was 14:10 the following Tuesday, three business days out. So the ticket resolved with most of its allowance unused. At month end the Acme report reads: 212 tickets, response target met on 203, resolution target met on 188, and three tickets where the desk warned of a miss before missing. Those four numbers are the SLA, kept.

Four rows is not a limitation. It is the number of distinctions a small desk can make at 08:50 with a cold. Anything the four rows cannot express belongs in the priority definitions, not in a fifth row.

A Short War Story: Meridian Parts

Meridian Parts' first SLA was the sticky note, typed up. The operations manager asked for an SLA. Priya, who ran the desk, put the note's two lines into a one-page document with the business hours and a four-row table. She made one addition of her own: "If we are going to miss a target, we will tell you before we miss it, and say when you will hear from us next." Not one target changed. The desk began sending that warning on the eight or nine tickets a month that were going to slip, one sentence each, usually at the halfway point. Within a month the average satisfaction rating had moved from a little under seven to a little over eight. The comments had changed from "took too long" to "kept me informed". The report numbers were the same as the month before. What had changed was that nobody waited in silence.

I have copied that sentence into every SLA I have written since. It is the only part of the document users ever quote back.

The One-Page Starter SLA

The starter below is complete enough to publish and short enough to read in the time it takes the acknowledgment e-mail to arrive. Fill in the blanks. Check the targets against a month of your own tickets before you promise them. Change nothing else until the first review. Choosing the words for each section, and the version for an external customer, are the subject of Writing the SLA Document People Will Read.

STARTER SLA: ____________________ IT HELP DESK
Owner: ______________    Published: ____________    Next review: ____________

WHAT WE PROMISE
A person will reply to every ticket within the response target below,
during business hours. We work tickets in priority order. If we are
going to miss a target, we will tell you before we miss it, and say
when you will hear from us next.

THE CLOCK
Business hours: Monday to Friday, 08:00 to 17:30, excluding public
holidays. Targets are counted in business hours only. A ticket opened at
17:00 on Friday with a four-hour response target is due by 11:30 on
Monday. Time waiting for your reply [does / does not] stop the clock.

THE TARGETS
Priority   Test                                    Respond within    Resolve within
---------  --------------------------------------  ----------------  ------------------
Critical   Many people cannot work                 thirty minutes    four business hours
High       One person cannot work, or a deadline   two hours         one business day
Normal     Work is slowed; a workaround exists     four hours        three business days
Low        A request, a question, a nice-to-have   one business day  ten business days

HOW TO ESCALATE
Reply to the ticket with the word ESCALATE, or call ______________.
A senior technician will look within one business hour.

HOW WE REPORT
Monthly: tickets opened, response targets met, resolution targets met,
both by priority, and what we changed. Sent to ______________ and
posted at ______________.

WHEN WE REVIEW
Every ______ months, or sooner if any target is missed more than one
time in ten.

Publish it where the user will meet it: linked from the acknowledgment e-mail and from the portal, and pinned beside the queue. Then run it for a month before you believe it. That is because the first month shows you which of the four rows was set by someone who had never met the queue. Usually it is the resolution column. Change that one row, say so in the report, and leave the rest alone.

The sticky note was right. It needed a clock, a report, and one sentence about missing. That is the whole upgrade, and it still fits on one page. That is roughly four sticky notes if you write small.

Frequently Asked Questions