What to Promise and What Never to Promise

"Resolution within two hours, all priorities." It was the third line of the SLA and it was in bold. And it had been written by someone who had never waited on hold with a hardware supplier. The desk it described had two technicians and one spare laptop. It had a supplier whose idea of next day was more of a mood than a date. The SLA lasted six weeks. The breach report lasted longer, because nobody could bring themselves to stop sending it.

An SLA, a service level agreement, is a written promise about how quickly and how well the desk responds, measured and reported. The word doing the work in that sentence is promise. A promise you can keep builds trust every time you keep it. And a promise you cannot keep spends trust every time it is measured, which is daily. This article is part of our SLA Design series. It is about choosing the promises. Which ones can a desk keep on its own? Which ones depend on somebody else? How do you write the second kind without lying?

It covers the promises you control and the ones that depend on vendors, users and the courier. Then comes how to split a promise at the point where you lose control of it. Next are the clock exclusions worth writing down, and the fact that not every tool's clock pauses when you think it does. The words that keep an SLA honest, the one promise never to make, and the exceptions section follow. There is a promise checklist near the end.

A Promise Is Only Worth What You Control

The test for every line in an SLA is one question: can the desk keep this promise with nobody else's help? If the answer is yes, write it down as a target. If the answer is "yes, unless the vendor" or "yes, if the user replies", the line is not a promise yet. It is a promise plus a hope, and the hope is the part that breaches.

A breach is a target missed, as the tool measures it. The tool does not know why. It does not know that the part was on a truck or that the user was on leave. It knows the clock ran out, and it reports the breach in the same shade of red as a ticket somebody forgot. So the only breaches worth having are the ones that tell you something about the desk. A breach caused by a courier tells you about couriers. You knew about couriers.

This is why what to promise matters more than how fast. A slow promise kept is an SLA. A fast promise broken is a weather report. Users learn within a month which kind they have been given.

The Promises You Can Keep

Five promises are entirely inside the desk's control, and they are the spine of every honest SLA. The first is response: a human reply within a stated time, set by priority. That is the rank the desk gives a ticket from how many people are affected and how soon it hurts. The response is not an auto-acknowledgment. The auto-acknowledgment is a receipt, and nobody has ever felt reassured by a receipt.

The second is the update interval: how often the user hears from you while the ticket is open, whether or not there is news. "No news yet, still waiting on the supplier, next update Thursday by noon" is an update. It costs forty seconds and it is the cheapest thing a desk can do to be trusted.

The third is honesty about misses. "We will tell you before we miss a target, not after" is a promise a desk can always keep. It depends only on looking at the queue. It also changes what a breach means to the user. A breach they were warned about is a delay; a breach they discover is a betrayal. Same clock, different relationship.

The fourth is escalation on request. If a user thinks their ticket is wrongly prioritized or stuck, they can ask for it to be reviewed by a named person within a stated time. The promise is that the request will be heard, not that the answer will be yes.

The fifth is the resolution target, how soon the problem is fixed or the request fulfilled, for the things you control end to end. Password resets. Access to a shared folder. A printer that needs a driver and not a part. For these, promise a resolution time and mean it. The difference between the two numbers, and realistic ranges for each, is the subject of Response Targets vs Resolution Targets. This article is about which rows get a resolution number at all.

The Promises That Depend on Others

Four kinds of ticket have somebody else's hands on the clock, and each one needs a different sentence. Vendors are the first. The desk can open a support case fast and chase it daily, and it cannot make the vendor move. Promise the opening and the chasing. "We will log the case with the supplier within four business hours and chase it every business day; the supplier's own response time applies after that."

Users who do not reply are the second. A ticket that needs a screenshot or a yes to a reboot stops when the user does. It is nobody's fault; they have a job too. Promise what you will do when they go quiet. "If we need something from you and have not heard back in three business days, we will remind you once, then close the ticket; replying reopens it."

Hardware in transit is the third, and it is the vendor problem again. Promise the order. "Replacement ordered within one business day of diagnosis; delivery depends on stock and the supplier." The word ordered is doing a lot of work there, and it is the only word you control.

Third-party services are the fourth: the cloud mail platform, the payroll provider's portal, the application hosted somewhere you cannot log in to. When those are down, the desk is a messenger. Promise to be a good one. "We will confirm the outage with the provider within one business hour and keep you updated every two hours until it is restored." Nobody will blame you for the outage. They will blame you for the silence.

The pattern across all four is the same. Find the moment in the ticket where the desk's control ends, and put the promise on that moment. Everything before it is a target. Everything after it is a dependency, named in plain words, with an update interval attached so the user is never waiting in the dark.

Splitting a Promise at the Point You Lose Control

Here is the technique on one ticket, with a clock. At 08:50 on a Tuesday, Lena on the loading dock at Meridian Parts e-mails the desk. The label printer that prints every outbound shipment is dead, no lights, and the first truck leaves at 14:00. Marcus picks up ticket 7314 at 09:04, inside the one-hour P2 response target, and replies that he is on his way down. By 09:40 he has confirmed that the power supply has failed and that an old spare printer is in a box somewhere. He has also confirmed that the part is a supplier item.

The two-hour SLA would already be counting toward a breach at 10:50 that nothing in the building could prevent. The honest SLA has two promises on this ticket, and Marcus keeps both. The first is the P2 target for the desk's own work: a diagnosis and a workaround within two business hours. He finds the spare at 10:15, sets it up on the dock at 10:35, and the labels print. The second is the ordering promise: replacement part ordered within one business day of diagnosis. He places the order at 11:40 and notes the supplier's quoted delivery, which is Thursday.

The ticket stays open in a waiting-on-vendor status, with an update to Lena at 16:00 on Wednesday ("no change, still due Thursday"). And the part arrives at 10:20 on Thursday. Marcus fits it by 11:15 and asks Lena to confirm. From the desk's point of view, every promise was kept, to the minute. From Lena's point of view, the printer was away for two days. She knew why and she knew when it was coming back. The trucks left on time all three days. Under the two-hour promise the same ticket would have been a breach by lunchtime on Tuesday, and Lena's experience would have been identical. The only thing the old SLA added was the breach.

The Clock Exclusions Worth Writing Down

An SLA needs a clock. The clock needs a short list of when it is not running, written down where the user can see it. Business hours are the hours the clock runs; outside them it stops. A ticket opened at 17:55 on Friday with a four-hour response target is due around noon on Monday, not at 21:55 on Friday. Say which hours and which holidays. The clock that runs through the weekend is one of the great breach generators in the trade, and it has never once made anyone work a Saturday.

Three exclusions are worth stating in so many words. The first is waiting on the user, between the desk asking a question and the user answering it. The second is waiting on a vendor, between a case being logged and the supplier responding. The third is outside business hours and published holidays. Each is a sentence in the document, and each one prevents a category of breach that teaches nothing.

Now the awkward part. Writing "the clock pauses while waiting on the user" into the SLA does not make your tool do it. Some SLA engines pause the clock when a ticket goes on hold; some do not; some pause on one status and not another. QuerySolv is one of the ones that does not pause. Its documented limit is that the SLA clock does not pause on hold, and only non-working hours and holidays are excluded. A known behavior is a design input. A design input you did not read is a surprise with a deadline.

If your clock does not pause, design for it rather than around it. Keep the resolution target on the rows the desk controls end to end, where there is no hold to pause for. Put dependent work in the split form above. In that form, the measured promise completes before the waiting begins and the waiting is reported through the update interval. The document should describe the clock you have, not the clock you wish you had bought.

The Words That Keep an SLA Honest

Three phrases do most of the honesty in an SLA, and three others do most of the damage. Use "target", never "guarantee". A target is a number you aim at and report on; a guarantee is a number with a consequence attached. And an internal desk has no consequence to offer except its own embarrassment. "Our target for a P2 response is one business hour" tells the truth. "We guarantee a one-hour response" is a sentence that will, at some point, be read aloud in a meeting.

Use "business hours" every time a duration appears, and define them once at the top. "Four hours" and "four business hours" are different promises by a factor of about four on a Friday afternoon. The user will remember whichever one suits them. Use "we will tell you" wherever you would otherwise be silent: if we will miss a target; what we are waiting on; when to expect the next update.

The phrases to delete are "best endeavors", "as soon as possible", and "where feasible". "Best endeavors" means "we will try", which is not a target, a promise, or a time; it is a shrug in a tie. "As soon as possible" names a time that cannot be measured, and so cannot be kept or broken, and so does not belong in an SLA. "Where feasible" means the same thing and should go with it. Strike every line that cannot be missed; if it has no clock and no condition, it is decoration, and users can tell.

The One Promise Never to Make

Never promise a fix time for a problem you have not diagnosed. It is the most common line in a failed SLA. And it is written with the best of intentions: "all incidents resolved within eight business hours". The person writing it is imagining a password reset. The ticket that arrives is "the finance system is slow sometimes". And the eight hours start at 09:00 whether the cause is a full disk, a network loop, a vendor's database, or the weather.

Diagnosis comes before an estimate, in support as in medicine, and an honest SLA respects the order. Promise the diagnosis, then promise an estimate. "For a P2 incident, we will give you a diagnosis or a workaround, and an estimated fix time, within four business hours." After that, the estimate is a promise with a named reason attached, and the user can hold you to it. If the estimate changes, say so and say why. That is the only kind of promise an unknown problem can bear.

I wrote the eight-hour line once, early, on a desk with three technicians and a building full of equipment older than two of them. We breached it on day two, with a ticket that turned out to be a failing switch in a closet nobody had a key to. The target was not wrong by a little. It was the wrong kind of sentence.

The Exceptions Section

Every SLA needs a short section titled "What this does not cover", and the operative word is short. Major incidents have their own clock. In a major incident, many people are affected at once and the desk switches from tickets to a single incident channel. For those incidents, say that the normal targets are suspended and that updates will come hourly. Equipment and software outside the supported list, which belongs to the scope pages, gets best-effort help and no target. Bulk requests, such as forty new accounts for a new branch, are projects with a date, not tickets with a target.

Then stop. Each exception you add is a promise you are taking back, and users count them. An exceptions section longer than the promises section is a confession. A document with twenty exclusion cells and four promise rows is the SLA matrix everyone has met and nobody has read past. If you find yourself adding a fifth exception, the better fix is usually to split a promise. That names the dependent part inside the promise instead of exempting it from the promise.

One thing that looks like an exception is not. "The technician was on leave" does not belong in the section; the SLA promises what the desk does, and the desk is more than one person. If the desk cannot meet its targets with one person out, that is a staffing fact, and the targets should be larger. The user does not care who is on leave. They care when they will hear from you.

A Short War Story: Forty Breaches at Acme

Acme's SLA promised next-business-day laptop replacement, and for a year it was kept. Dana on the desk kept four spares in a locked closet and the supplier delivered in two days. Then the supplier's stock ran dry for six weeks. The closet emptied in the first two of them. Every laptop ticket after that breached on day two and stayed red until the hardware arrived. The breach report showed forty breaches for the quarter, all on one row. Dana was asked in a meeting what had gone wrong with the desk. Nothing had. She rewrote the line: "replacement ordered within one business day of diagnosis; delivery depends on stock, and we will tell you the expected date when we order". The breaches stopped the following month. The users got exactly the same laptops on exactly the same days, and they were no less informed. They were, if anything, told more.

The point of the story is not that the SLA got easier. It is that the old line had been measuring the supplier and reporting the result as the desk.

The Promise Checklist

Use the table below when writing or reviewing an SLA, one row per promise. The middle column is the only hard question: can the desk keep this with nobody else's help? Where the answer is no, the right-hand column shows the split form. In that form, the measured part is on the desk's own work and the dependency is named in plain words. Add your own rows at the bottom.

When the table is full, it becomes the "what we promise" and "what we do not promise" sections of the SLA almost word for word. How those sections sit on the page is the subject of Writing the SLA Document People Will Read. And when a promise from the "Yes" column breaches anyway, the breach is finally telling you something about the desk. That is what SLA Breaches and What They Teach is for.

Back to the two-hour line in bold. It was not a lie, exactly. It was a promise made by a desk on behalf of a supplier, a courier, and every user who would ever go on leave with a ticket open. None of them had been consulted. Promise what you control, name what you do not, and tell people when they will hear from you. The desk will keep that SLA on its worst week. And a kept promise on a bad week is the whole reason to have one.

Frequently Asked Questions