SLA Breaches and What They Teach

Forty-one breaches last month. The number sits at the top of a report that was generated at 00:05 on the first of the month. A schedule attached it to an e-mail. Tomas filed it in a folder called SLA Reports, next to eleven others. Nobody opened it. Nobody opened the previous eleven either. The desk is not hiding anything; it is just that forty-one is a number, and a number on its own has nothing to say.

A breach is a target missed: the desk promised a reply or a fix inside a stated time, and the clock ran out first. The breach report is the list of those misses, and it is the most useful document the desk produces. That is roughly the way a smoke detector is the most useful appliance in the kitchen. It is useful only if somebody responds to it. This article is part of our SLA Design series. It is about the response.

It starts with why a breach is information rather than a verdict. Then it covers the order to read the report in, and why the technician column comes last. Next come the test that separates a bad week from a bad target and the five usual causes and what to change for each. It then covers renegotiating a target with evidence and the three-sentence conversation with a user whose ticket breached. Catching the breach before it happens comes next, followed by the fifteen minutes a month that make it routine. The breach review sheet near the end is built to be copied.

A Breach Is Information, Not a Verdict

A breach tells you that a promise and a queue disagreed, and nothing else. It does not say who was at fault, because the clock does not know. It does not say the target was wrong, because the clock does not know that either. It says: here, at this hour, on this kind of ticket, the time ran out. That is a measurement, and a measurement is the start of a question.

Desks get this wrong in two opposite directions. The first treats every breach as a verdict on a technician. That produces a desk where people reply "looking into it" at minute fifty-nine and mark tickets on hold to stop the clock. The count falls and nothing else improves. The second treats the report as weather: it arrives, it is red, it is filed. Both desks learn nothing, and the second one at least saves the postage.

The useful stance is in between. A breach is a data point about the fit between what the desk promised and what the desk can do. The only two things that can be adjusted are the promise and the desk. Every breach is a vote for adjusting one of them. The report is the ballot box.

One rule follows, and it belongs at the top of the first page. The target breached; the technician did not. The desk sets targets, staffs hours, and chooses how the form asks for priority, and a breach is the sum of those decisions arriving on one ticket. A technician cannot be coached into a different Monday.

Reading the Report in the Right Order

Read the breach report four ways, in a fixed order: by priority, by category, by hour of day, and by technician, last. Each cut explains some of the breaches, and what is left over is what the next cut has to explain. Read it backward and the first thing you see is a name, and a name explains everything, badly.

By priority first, because the targets hang off priority and the first question is whether the ladder is sane. Priority is the rank that sets the targets, decided from how many people are affected and how soon it hurts. If a third of all breaches are P1, either the building is on fire a third of the time or the definition of P1 is too easy to reach. (It is the second one.) The fix is in Priority Tiers That Are Realistic. The test here is whether breaches cluster at one priority out of proportion to its share of tickets.

By category second, because a category that breaches on its own has a problem that has nothing to do with the desk's speed. Software requests that need a purchase. Hardware that needs a part. Anything with the word "project" hiding in the description. Twelve breaches in one category is not twelve problems; it is one problem that happened twelve times.

By hour of day third, and by day of week with it. Breaches may cluster at 09:00 on Monday, or at 13:00 every day, or on the first working day of the month. Those clusters tell you where the shape of the queue and the shape of the staffing do not match. This is the cut that most often finds the real cause, and the one most desks never make, because the report comes sorted by ticket number.

By technician last, and only for what is left. After the ladder, the category and the hour have each taken their share, the remainder is small. Only then is it fair to ask whether one person's remainder is bigger than another's. Even then the question is "what was different about those tickets", not "what is different about Sam". Usually the answer is that Sam had the Monday shift.

A Bad Week or a Bad Target

Before changing anything, separate a bad week from a bad target, because the fix for one is nothing and the fix for the other is a new number. A bad week is a cluster of breaches with a cause that has already gone away. It might be an outage, two people out with the same cold, or a mass e-mail that produced ninety tickets by 10:00. A bad target is a steady leak with no story. The report looks the same for both; only time tells them apart.

The pattern test is three months, same category, same hour. Pull the breaches for the last three months and look for the cut that repeats. It might be the same category breaching every month, or the same hour of the week lighting up three months running. If a pattern survives three months it is not weather. It is a property of the target, the clock, the staffing, or the category, and it will survive a fourth month unless something is changed. If it appears once and vanishes, write a sentence about what happened and move on.

The Usual Causes

Five causes account for most steady breaches on a small desk, and each one leaves a recognizable shape in the report. The first is a target set without a queue in mind. The number came from a template, a previous employer, or a hallway conversation, and nobody checked it against last quarter's actual times before promising it. It breaches evenly, across categories and hours, at a rate that looks like a fixed percentage. That is because it is one.

The second is a clock that runs through hours nobody works. The business-hours schedule is wrong, or the holidays were never entered, and tickets logged on Friday afternoon are breaching at 03:00 on Saturday with nobody in the building. These are the easiest breaches to fix and the most embarrassing to find, because the fix is a settings page.

The third is a vendor dependency inside a target. A resolution target is wrapped around work that includes a supplier, a courier, or a provider, and the target measures their speed and reports it as the desk's. Splitting the promise at the point where the desk's control ends is covered in What to Promise and What Never to Promise. It is the fix here, not a longer target.

The fourth is one category that is really a project. "New starter setup" that is six tasks across three teams. "Software request" that needs a budget holder and a purchase order. A ticket with a target cannot hold a project, and the project breaches every time, patiently, until somebody gives it a date instead of a clock.

The fifth is understaffed hours. The desk has two people at 11:00 and nobody between 08:00 and 09:00, when a third of the tickets arrive; or Monday morning holds the whole weekend's tickets and one technician. No target can fix these, because the target is not the thing that is wrong.

What to Change for Each

The table pairs each cause with its shape in the report and the change that fits it. Read the shape column first; the shape is what you will see, and the cause is what you will infer. The changes are specific, because "improve processes" has never once reduced a breach count.

Change one thing at a time, and give it a month. If you fix the clock, split two promises and move a shift start in the same week, the next report will be better and you will not know why. One change, one month, one comparison. It is the only speed at which you learn anything.

Renegotiating a Target with Evidence

When the pattern test says the target is wrong, the target gets changed, and the way it gets changed is a one-page case, not an apology. The case has three parts: breaches by cause for the last quarter; the proposed target or split; and what the proposed version would have done to last quarter's numbers. The third part persuades, because it replaces a prediction with a replay.

Here is the case Priya wrote for the Northgate Retail desk, four technicians, after a quarter with forty-one breaches. Eighteen were P3 resolution breaches in the software-request category, where every ticket waited on a budget holder. Eleven were P2 response breaches timed between 08:00 and 09:30 on Mondays. Seven were hardware tickets waiting on a supplier. Five were scattered with no shape. She proposed three changes. Software requests leave the SLA and become a request form with an agreed date. Hardware replacement becomes "ordered within one business day" with delivery named as a dependency. Monday triage starts at 08:00 with two people instead of at 09:00 with one.

Then she replayed the quarter. With software requests out of the SLA, the eighteen are not breaches, because they are not targets. They become dates met or missed, and the form would have shown fourteen met. With the hardware promise split, four of the seven become kept promises (ordered the same day). Three would have breached the new one-day ordering target, which is a real finding about the desk. With the Monday triage moved, she estimated that eight of the eleven would have been met, based on what the same technicians achieved on Tuesdays. Forty-one became about nine. None of the targets got longer, and the five scattered breaches stayed exactly where they were, as a reminder that some weeks are just weeks.

The case went to the IT manager on one page and took a four-minute conversation. Nobody argued with it, because the numbers were last quarter's and the proposal was arithmetic. A renegotiation built on evidence does not feel like a renegotiation. It feels like reading.

The Breach Conversation with a User

When a user's ticket breaches, they hear from the desk before they hear from the report. They hear three things: what happened, what we are doing, and when they will hear next. "Your ticket was due a reply by 11:00 and we missed that; I have it now, I am checking the mail server logs, and I will update you by 14:00 either way." Three sentences, no adjectives, no apology longer than the explanation. The user did not know the target existed until the desk missed it, and now the only thing that matters is the next time.

Resist two instincts. The first is the explanation that turns into a defense: the vendor, the staffing, the three other P1s that morning. The user does not care, and they are right not to. The second is the silent catch-up, where the technician sees the breach, works the ticket, and hopes to resolve it before the user notices. They noticed. They have been noticing since 11:01. Better still is the warning before the miss, at 10:40, which turns a broken promise into a delay.

Catching the Breach Before It Happens

Most breaches are visible an hour before they occur, to anyone looking at the right thing. A response target due at 11:00 is a ticket with no reply at 10:00. A desk that looks at "due within the hour" at 10:00 will reply, warn the user, or reassign. Any of those beats a breach. A queue sorted by age shows the oldest ticket, and the oldest ticket is almost never the one about to breach.

Two tool features do this work for you. The first is a live countdown on each ticket in the queue. The one with forty minutes left is distinguishable from the one with four hours without opening either. The second is an alert to the assignee when a target is close or missed, so the breach reaches a person and not just a report. QuerySolv's SLA engine provides both, and its dashboard counts the tickets that are response overdue and due within an hour, which is the list to work first.

The third feature is the trend, and it belongs in the reports rather than the queue. A first-response compliance figure is the share of tickets whose first reply met the target. Read over a week, a month and a quarter, it shows whether the desk is drifting before the monthly report says so. QuerySolv's reports include that figure over seven, thirty or ninety days. Whatever tool you use, find that number and look at it on Fridays. A figure that falls three Fridays running is a breach report given early, and early is cheaper.

The Monthly Fifteen Minutes

The whole of this article fits into fifteen minutes a month, protected on the calendar, with the report open and the review sheet beside it. Minutes one to three: total breaches and the compliance figure, against the previous two months. Four to eight: the four cuts, in order. Nine to eleven: the pattern test against the last three sheets. Twelve to fourteen: one change, with a date and the number you expect it to move. Fifteen: file the sheet.

The output is one change, and one is the right number. Two changes and the next review cannot tell which one worked; zero changes and the fifteen minutes were a reading. If the report shows nothing but weather, the change is "none, see note". That is worth writing down, because three "nones" in a row mean the targets are right. A desk whose targets are right should say so somewhere.

I ran that review for two years on a desk of three, and the thing I remember is how boring it became by month six. The breaches had causes, the causes had fixes, and by the second half of the year the sheet mostly said "weather". Boring is the goal.

A Short War Story: Mondays at Bluewater Bank

Bluewater Bank's branch desk, three technicians supporting fourteen branches, breached about a third of its P2 resolution targets for two quarters. The first instinct was to lengthen the target from four business hours to eight. Before doing that, Lena ran the hour-of-day cut on three months of breaches, and the shape was unmistakable. Nearly all of them were tickets logged over the weekend by branch staff. They aged as a block from 09:00 on Monday when the clock started. The one technician on the early shift worked through them in order. From Tuesday to Friday the desk met the target nine times in ten. The change was a Monday 08:00 triage, one hour earlier, with two people instead of one. They sorted the weekend's tickets by priority before the clock started on any of them. P2 breaches fell by two thirds the following month, the target did not move, and the desk had its first boring breach review.

The fix was an hour of the week. It would have been very easy to buy eight business hours instead and learn nothing.

The Breach Review Sheet

The sheet below is the fifteen minutes on one page. Fill it in from the report, in order, and keep the completed sheets together; the pattern test on month four is "read the last three sheets". It is plain text so that it can live in the knowledge base, in a shared folder, or on the wall beside the desk, where it will be read most.

BREACH REVIEW — ONE PAGE
Desk: __________________  Month: ______________  Reviewer: ____________

HEADLINE
  Breaches this month: ____   Last month: ____   Month before: ____
  First-response compliance: ____%   (last month ____%,  before ____%)
  Tickets logged this month: ____    Breach rate: ____%

THE FOUR CUTS (in this order)
  1. By priority     P1 ____  P2 ____  P3 ____  P4 ____
     Out of proportion to that priority's share of tickets?  [ ] no  [ ] yes: ____
  2. By category     Top three:  __________ ____   __________ ____   __________ ____
     One category with over a third of breaches?  [ ] no  [ ] yes: __________
  3. By hour / day   Peak hour: ______   Peak day: ______
     Night, weekend or holiday breaches (clock problem): ____
  4. By technician   (remainder only) Unexplained by shifts?  [ ] no  [ ] yes: ______

PATTERN TEST (against the previous three sheets)
  Same category breaching three months running?    [ ] no  [ ] yes: __________
  Same hour or day three months running?           [ ] no  [ ] yes: __________
  Verdict:  [ ] bad week (note why)   [ ] bad target or clock   [ ] staffing shape
  Note: ________________________________________________________________

THE ONE CHANGE
  What: _________________________________________________________________
  Expected effect on next month's number: from ____ to about ____
  Owner: __________   Done by: __________   Review on next sheet: [ ]

USERS CONTACTED ABOUT A BREACH
  Every breached ticket got the three-sentence message before the user
  chased?   [ ] yes   [ ] no: ____ missed

The sheet changes a little with the desk. A one-person desk can strike the technician cut; the remainder is always the same person. A desk with departments that run their own targets fills in one sheet per department, because the Monday shape in one is not the Monday shape in another. The monthly sheets also feed the annual check described in Writing the SLA Document People Will Read, and are the record it draws on.

Forty-one breaches last month. That report is still in the folder, and it still has nothing to say on its own. Read four ways, against three months of sheets, it has exactly one thing to say. It will keep saying it every month until somebody changes one thing and reads it again. The breach report is the most patient document on the desk. It can afford to be.

Frequently Asked Questions