The Interruption Load and Why It Is Different

Tuesday, 10:14, at Harbourview Clinic. Marta sat down at 08:30 to finish the laptop build document, a four-hour job she has been "about to finish" since Thursday. Since then the phone has rung six times and the chat window has pinged nine. A receptionist has walked over twice about the label printer. An e-mail beginning "quick one" has turned out to be a licence renewal that needed a manager's approval and a call to the vendor. She has opened the build document eleven times. By her own count she has done twenty-five minutes of it. Nobody who interrupted her was being unreasonable. Every one of them was sorry to bother her. And that is the whole problem.

Interruption load is the total cost, in time and attention, of every unplanned demand on a technician's day. It counts not just the minutes spent on each one but the minutes lost getting back to whatever it broke into. On a help desk the load is not an occasional nuisance. It is most of the job, and the part of the job that nobody planned, budgeted or wrote on a rota. This article is part of our Helpdesk Burnout series, which treats burnout as an occupational matter. Interruption load is the first mechanical cause the series takes apart. It is the one most desks have never measured.

It covers why a desk's interruptions are different from an office's, then what one interruption costs, as a worked example from a fictional desk. Next come the four sources and the shape of each, and why forty small things weigh more than four large ones. Then it covers how to measure the load from the ticket data you already have, the one-week log, and protecting focus blocks. The queue-duty idea follows: this article introduces it and the next one builds it. Finally, there is a short war story and the one-week interruption log to copy.

Why a Desk's Interruptions Are Different

In most jobs an interruption is a colleague with a question, and the question can wait, and both people know it. On a help desk the interruption is the work. The phone ringing is not a distraction from the job. It is a requester with a problem, which is what the desk exists to receive. That means the technician cannot do what everyone else does with interruptions. That is to close the door, mute the chat, or say "can it wait until three". Some of it can, and the desk rarely knows which until it has already stopped to find out.

The second difference is that the person interrupting cannot see the cost. A requester who calls at 10:14 sees one technician, apparently at a desk, apparently available. They do not see the build document, the six previous calls, or the fact that this is the fourth time the same train of thought has been derailed since nine. Each interrupter believes, correctly, that they are asking for four minutes. The forty of them together are asking for the day. Nobody is at fault, and the day still goes.

The third difference is that each interruption arrives with a person attached, and the person has to be dealt with as a person. A developer interrupted by a build failure can swear at the screen. A technician interrupted by a frightened receptionist has to be calm, kind and competent on arrival. They have been calm, kind and competent on the previous eight arrivals too. That is emotional labour. The first article in this series, What Burnout Actually Looks Like on a Help Desk, named it as one of the four shapes. The interruption load carries the emotional labour in through the same door, forty times a day.

What One Interruption Costs: A Worked Example

Every interruption has three costs. Most desks only count the first. The first is the handling time: the four minutes it takes to reset the password or find out that the label printer is unplugged. The second is the context switch. That means the time it takes to put down what you were doing, hold it somewhere in your head, and deal with the new thing. It also includes picking up the old thing again from where you left it. The third is the error cost: the step you skip, or repeat, because you lost your place. The handling time is in the ticket. The other two are nowhere.

Marta measured hers, for one week, with a notebook. The numbers below are hers, from a fictional desk of three at a fictional clinic. They should be read as an example of the method rather than a figure for anyone else's desk. Her Tuesday had thirty-one interruptions. The handling time came to a little over two hours. Her recovery time was the gap between finishing an interruption and being genuinely back in the build document rather than staring at it. She timed it at between two and four minutes each. That added somewhere between one and two more hours. Her longest clear stretch all day was twenty-six minutes. The table lays it out.

The last two rows are the ones to look at. Between three and a half and four and a half hours were nominally free for planned work, and about an hour's worth got done. That was because the free time came in pieces averaging twelve minutes. A four-hour document cannot be written in twelve-minute pieces by anyone. The arithmetic says a quarter of the day went on interruptions and the shape of the day says more than half of it did. The arithmetic is not wrong. It has simply never tried to write a document.

Scale that to a desk and the number gets uncomfortable. Take three technicians, each losing between one and two hours a day to recovery alone. That is somewhere between fifteen and thirty hours a week that appear in no ticket, no report and no case for a fourth person. A desk lead who adds up handling time from the tickets will find the desk looks busy. A desk lead who adds up recovery time from a log will find out where the rest of the week went. Those are the hours the headcount case in The Headcount Case needs. The ticket system cannot supply them, because nobody opens a ticket for the two minutes spent remembering what they were doing.

The Four Sources and the Shape of Each

The phone is the most expensive source because it is synchronous. It rings now and must be answered now. The caller is waiting while the technician finds the ticket, the account and their composure. The phone also has no queue of its own. Two calls at once is a missed call, and a missed call is a person who tries again in four minutes, or walks over, or e-mails the technician directly. That is three further interruptions from one. Whether a desk needs a phone at all is a channel question, in Phone Support in a Ticket World. Here the point is only that each call costs more than its minutes.

The chat window is the cheapest per interruption and the most frequent, which makes it the most expensive per day. A ping is small. A ping every eleven minutes, all day, from four different people who each believe they are the only one, is a day with no clear stretch in it at all. Chat also carries a false urgency. The message appears instantly, so the sender expects the reply instantly. The technician who does not answer for twenty minutes gets a second message asking whether they saw the first. The design of chat as a support channel, and how to make it feed the queue instead of bypassing it, is in Direct Messages and Chat as a Support Channel.

The walk-up is the one with a face. A person standing at the desk cannot be put on hold, minimised or answered later, and the technician's own social reflexes do the rest. Walk-ups are also the interruptions most likely never to become a ticket. That means they are the ones the desk is least able to count, plan for or staff against. The whole subject has its own series, starting with Why Walk-Ups Happen and What They Cost. This article leans on it rather than repeating it. The thing to know here is that the walk-up is the source most often described as "no trouble" by the people causing it.

The fourth source is the "quick one": the e-mail or direct message to a named technician, outside the queue, usually from someone who knows them. It arrives with a reassuring subject line and an open-ended body. The cost is in the opening, because a technician who reads it has to decide whether it is actually quick. The only way to decide is to start. Marta's licence renewal was a quick one. It took fifty minutes, across three sittings, and it was never a ticket until she made it one at half past four. If you run QuerySolv, or any tool that takes e-mail and direct messages into the same queue as the web form, forward the quick one into the queue before reading it properly. That is the fix: it is at least a ticket by the time it turns out not to be quick.

Why Forty Small Things Weigh More Than Four Large Ones

A technician who closes forty tickets in a day has done forty pieces of work and forty pieces of recovery. They have finished nothing that felt like finishing. A colleague who spent the same day on four tickets has had four clear stretches, four moments of completion, and a day they can describe at dinner. The ticket count says the first technician did ten times the work. The first technician's evening says otherwise. Both are right, and the second is the one that predicts who is still on the desk next year.

The weight comes from three things. Switching is tiring in itself, separately from the work being switched between. A day of forty switches is harder than a day of forty tasks done in a row would be, even with the same handling time. Each small thing carries a person, so forty small things is forty conversations, forty tones to match, forty "no trouble at all"s. And nothing completes. The build document is still open at five, exactly as it was at nine, with twenty-five more minutes in it. The technician goes home with the feeling of having worked flat out and done nothing. That is accurate on both counts.

That is why the interruption load is a burnout cause and not just a productivity complaint. A heavy day with completion in it is tiring. A heavy day with no completion in it, repeated, is the queue that never reaches zero in miniature, every day, with a person attached to each piece. Technicians do not burn out from the hard tickets. They burn out from the four hundred easy ones in a row.

Measuring the Load From the Ticket Data

The ticket data already holds most of what you need, provided the desk logs its interruptions as tickets. That is the one habit that makes everything else in this article measurable. Start with the source field: tickets by channel per hour of the day, for a month. Phone and chat and walk-up tickets are interruptions by definition, since each arrived in real time and stopped someone. A desk that sees eleven of those an hour between nine and eleven has found its heaviest interruption block without keeping a single log.

Then look at touches against closes. A touch is any event on a ticket, a reply, a note, a status change, a reassignment. Most tools record every one with a time and a name. Count the tickets each technician touched in a day against the tickets they closed. A technician who touched forty tickets and closed nine spent the day in fragments. A technician who touched twelve and closed ten had a day with shape to it. Neither number is a performance figure. Reading them as one is the mistake the last article in this series, Measuring Load Without Surveillance, exists to prevent. They are a picture of what the day was made of.

Then look at the gaps. Where the tool keeps a full event history, the timestamps on one technician's events across a day show how long their longest stretch without a ticket event was. If that stretch is never longer than twenty minutes, the day had no room for anything that takes thirty. The counting discipline, and the traps in counting tickets at all, are in Counting Tickets Properly. Use its rules and do not invent new ones for this. What the ticket data cannot give you is the recovery time, the interruptions that never became tickets, and the number of times the same train of thought was derailed. For those you need the log.

The One-Week Log

The one-week interruption log is a notebook, kept for five working days by one technician, with a line for every interruption. The line records when it came, where it came from, what it was, and how long it took. It also records roughly how long it took to get back to what they were doing, whether it became a ticket, and whether it could have waited. It takes about twenty seconds per entry. It is the only instrument I know that measures the part of the day the ticket system cannot see. A desk that has never kept one is guessing about where its week goes.

Keep it honestly and keep it briefly. A log that asks for too much per entry gets abandoned on Tuesday, and a log kept on an app gets interrupted by the app. Paper, or a plain text file that stays open, is enough. Write the entry when the interruption ends, not when it starts, because you will not remember the recovery time otherwise. Where you forget an entry, leave it out rather than reconstruct it. A log with gaps is honest and a log with guesses is fiction. (Marta's Wednesday has a gap from 14:00 to 15:30 labelled "outage, did not log". That gap is itself data.)

At the end of the week, read it three ways. By source, to see which door most of it came through, which is where the cheapest fix usually lives. By hour, to see where the heavy block is, which is what the focus block and queue-duty ideas below are built around. And read it by the "could it have waited" column. On most desks, that column says yes for well over half the entries. That is the fact that makes the next two sections possible. The log is not a complaint. It is a map of the day, drawn by the only person who was there for all of it.

Protecting Focus Blocks

A focus block is a stretch of the day, two hours or so, during which one technician takes no interruptions at all. The phone is diverted, chat is set to away, walk-ups are redirected to a colleague, and e-mail is closed. The focus block is the only cure for the twelve-minute-pieces problem, because planned work needs stretches and the day does not naturally contain any. The block has to be real, which means the rest of the desk has to be covering. It also has to be visible. That means the desk has agreed when it is and the requesters know who to ask instead. A focus block that is only in the technician's head lasts until the first ping.

Three rules keep a focus block alive. It is short: two hours is enough for most planned work and is a length a small desk can cover; a whole afternoon is not. It is scheduled, not claimed on the day. A block that moves according to the queue is a block that never happens. And it is honoured by the technician as much as by everyone else. That is the hard part, because a technician who has spent years answering on the first ring will answer on the first ring during their own block, out of reflex. Then they wonder why the block did not work.

The block is interrupted for exactly one thing, and the desk agrees in advance what it is. A genuine outage, meaning many people unable to work, is the usual answer. The test for what counts as one is in What Makes an Incident Major. Everything else waits for the end of the block, and "the director is asking" is not an outage, however much it feels like one at the time. A desk that cannot say that sentence out loud does not have focus blocks. It has a hope.

A three-person desk can give each person one block a day. A two-person desk can give each person one block on alternate days. Even a solo technician can take one by diverting the phone to voicemail with a message that says when they will be back. A desk that cannot cover a two-hour block for one person three times a week is understaffed. That is a different problem with a different article. It is still worth knowing that it is the problem, rather than believing that technicians simply cannot concentrate.

The Queue-Duty Idea

Queue duty turns the focus block inside out. Instead of one person being protected while everyone else absorbs the interruptions, one person takes all the interruptions, for a block or a day. That way, everyone else is protected. The person on queue duty answers the phone, watches the chat, takes the walk-ups and triages the new tickets. They plan nothing else. The rest of the desk does planned work. The only thing that reaches them is a ticket the queue-duty person has decided needs them. That is a very different thing from a ping.

The effect on the load is not that it goes away. The same thirty-one interruptions arrive. The difference is that they land on a person who expected them, planned nothing else and is not losing a build document to each one. So the recovery cost drops to nearly nothing, and the two people not on duty get a day with a shape. Tomorrow a different person takes the duty and the first one gets their shape back. Over a week the load is the same and the damage is a fraction of what it was. That is the whole mechanism, and it is simple enough that most desks assume it cannot be the answer.

Queue duty is the backbone of the next article in this series, Sustainable Pacing: Designing the Day Around Recovery. That article has the roster, the rotation rules, and what to do when the person on duty is drowning. This article only introduces the idea. The one-week log is what tells you whether you need it. Most desks that keep the log find that they do.

A Short War Story: The Four-Day Afternoon at Meridian Parts

At Meridian Parts, a technician called Jonah was given the job of rebuilding the warehouse's barcode scanner configuration, estimated at an afternoon. He did it at his desk, in the open, with his phone connected and his chat window up. That was how the desk had always worked. The afternoon took four working days, during which Jonah logged, at his manager's suggestion, every interruption. The log showed a hundred and twelve of them, of which ninety-one, by his own column, could have waited an hour. On the third day he applied a configuration step twice, having lost his place after a walk-up. The warehouse's scanners stopped reading for forty minutes during the afternoon dispatch. That cost the firm a missed carrier pickup and a manager's visit to the desk that nobody enjoyed. The rebuild was finished on the fourth day in a meeting room with the phone diverted, in two hours and ten minutes. The desk adopted a queue-duty rotation the following week. The manager's note on the log read that the afternoon had never been the problem; the hundred and twelve people who had each wanted four minutes of it were.

The One-Week Interruption Log

Copy the sheet below onto paper or into a plain text file and keep it for five working days, one technician at a time. Start with whoever has the most planned work and the least of it done. Fill the entry when the interruption ends. Leave the recovery column blank rather than guess it when you were not back at planned work anyway. The weekly summary at the bottom is the part to bring to the desk's next meeting. The "could it have waited" count is the number that justifies a focus block or a queue-duty rotation better than any argument.

ONE-WEEK INTERRUPTION LOG — ONE TECHNICIAN, FIVE DAYS
Name: ______________   Week beginning: ________   Planned work this week: ______________________

DAILY ENTRIES (one line per interruption; fill it when the interruption ends)
Time   Source               What it was              Handled  Back in   Ticket?  Could it
       (phone/chat/walk-up/                           (min)    (min)     (Y/N)    have waited?
        e-mail/DM/colleague)                                                      (Y/N/outage)
_____  ___________________  _______________________  _______  ________  _______  ___________
_____  ___________________  _______________________  _______  ________  _______  ___________
_____  ___________________  _______________________  _______  ________  _______  ___________
_____  ___________________  _______________________  _______  ________  _______  ___________
_____  ___________________  _______________________  _______  ________  _______  ___________
Gaps (times logging stopped, and why): ______________________________________

DAY SUMMARY (end of each day)
  Interruptions: ____   Handling minutes: ____   Recovery minutes: ____
  Longest clear stretch: ____ min   Planned work done: ____ min of ____ planned
  Not logged as a ticket: ____   Could have waited: ____

WEEK SUMMARY
  Total interruptions: ____   By source: phone ____ chat ____ walk-up ____ e-mail ____ DM ____ colleague ____
  Heaviest hour of the day: ________   Quietest hour: ________
  Average recovery per interruption: ____ min   Total recovery for the week: ____ h
  Could have waited: ____ of ____   Never became a ticket: ____ of ____
  Planned work finished this week: ____ of ____ hours planned
  One change to try next week (focus block / queue duty / divert a source): ______________________

Marta's week summary said a hundred and thirty-eight interruptions. Eighty-four of them could have waited; forty-one never became tickets. The heaviest hour was from ten to eleven every single morning. The desk gave her a focus block from eleven to one, twice a week, with Priya on queue duty. The build document was finished the following Tuesday. It had been an afternoon's work all along. It had just never been given an afternoon.

Frequently Asked Questions