# Interruption cost: what the task timer does not see > Timing only the execution of an ad hoc request understates its cost. In a 27-person study, resuming work took 11 to 17 minutes. The fix is at the entry point. - Author: Marlon Trettin - Published: 2026-10-29 ยท Updated: 2026-10-29 - Language: en - Canonical: https://yowpi.com/en/blog/interruption-cost-what-the-task-timer-does-not-see --- An ad hoc request costs more than the time it takes to do it. In a study of 27 employees, getting back to the interrupted work took 11 to 17 minutes on average, depending on the channel. Timing only the execution understates the cost. The fix is architectural: change where the request comes in. ## TL;DR - An ad hoc request has two parts: doing what was asked and getting back to what the person was doing. The second tends to stay out of the time sheet. - In a field study of 27 employees, the resumption phase averaged 11 to 17 minutes, with huge variation. In 27% of suspensions, more than two hours. - In an experiment with 48 participants interrupted every two minutes, tasks finished sooner and stress rose from 6.9 to between 9.1 and 9.5 on a 1 to 20 scale. The stopwatch showed a gain. The cost showed up somewhere else. - Our reading, which the studies do not test: before automating the repetitive task, change how the request enters, from interruption to registered queue, and measure arrival and start. ## Why does timing only the execution understate the cost? Because an ad hoc request has two parts, and the stopwatch usually catches one. The first is doing what was asked. The second is getting back to what the person was doing, and that tends to stay out of the time sheet. In a [field study presented at CHI 2007](https://www.erichorvitz.com/CHI_2007_Iqbal_Horvitz.pdf), Shamsi Iqbal and Eric Horvitz followed 27 Microsoft Research employees for two weeks, with 2,267 hours of activity logged. They measured the resumption phase: the interval between the signal that the person wants to go back to the task and the return to the state they were in before leaving it. After an email answered right away, resumption averaged 16 minutes 33 seconds. After an instant message answered right away, 10 minutes 58 seconds. For delayed responses, it was 15 minutes 50 seconds and 12 minutes 2 seconds. The spread matters as much as the average. The standard deviation of resumption after a delayed email was 25 minutes, which points to short cases next to very long ones. According to the authors, 27% of task suspensions took more than two hours to resume. The study measures the interval and does not claim that all of it is idle time. The mechanism has a name. Sophie Leroy, at the University of Washington Bothell, describes attention residue on [her page](https://www.uwb.edu/faculty/sophie-leroy/): when people switch tasks, part of their attention stays with the previous one, and this happens easily when a task was left unfinished or interrupted. In her words, performance on the next task is likely to suffer, especially if it is cognitively demanding. ## What changes when the cost does not show up in time? The time metric can improve while the cost rises somewhere else. In an [experiment presented at CHI 2008](https://www.interruptions.net/literature/Mark-CHI08.pdf), Gloria Mark, Daniela Gudith and Ulrich Klocke compared 48 participants who played an HR manager at a simulated company and answered emails, with and without interruptions every two minutes. Interrupted participants finished sooner: 22.77 minutes without interruption, against 20.31 with a same-topic interruption and 20.60 with a different-topic one, not counting the time of the interruption itself. The price appeared in what participants reported. Stress went from 6.92 to 9.46 and 9.13 on a 1 to 20 scale. Effort went from 9.50 to 11.04 and 11.52. Frustration and time pressure rose too. The authors read this as people compensating by working faster and writing less, at the cost of stress and effort. For an operation, the hypothesis to test is this: time per task can improve in a week when the team is worse off. ## What do these studies not prove? They show the order of magnitude of the problem, not its size in your company. Some limits matter for whoever decides. Neither measures an SME operation. The Iqbal and Horvitz study comes from a single research organization, and the authors acknowledge they cannot prove the alert caused the task switch: they linked the two with a 15-second rule. Mark's is a lab study, with 81% German university students and about 20 minutes of work. The authors say they do not know whether people would adapt over time, and they treat the explanation for the speed-up as an interpretation, not a tested mechanism. Also, an email alert is not an operations request. Whoever receives "send me the invoice copy" executes and records, and that is a different task. This is why your own measurement comes before any calculation. ## How does this show up in an SME operation? As a number that tends to go unrecorded. The example below is an illustrative hypothesis, not a measurement. Picture the back office of a distributor with six people. Requests for invoice copies, delivery status and record corrections arrive by direct message to whoever is closest. Suppose one operator gets 24 requests a day and takes 4 minutes to execute each. That is 96 minutes, 20% of an 8-hour day. It is what the time sheet shows. Now suppose, with no measurement at all, that each interruption costs 6 minutes of resumption. That is 144 extra minutes, and the total reaches 240 minutes, half the day. If resumption cost 2 minutes, it would be 48 extra and 144 in total, 30%. Under this hypothesis, the range runs from 30% to 50% of the day. What decides where the operation falls in it is a figure that tends to stay out of the spreadsheet: how long the operator takes to get back to what they were doing. Requests like these often land on the list of repetitive tasks to automate. If automation comes before changing how the request enters, it inherits the design of the interruption. We covered the order of choice in [repetitive tasks: what to eliminate first](/en/blog/repetitive-tasks-what-to-eliminate-first). ## What should you do before automating the ad hoc request? This part is our reading, not a result of the studies: the problem here is rarely the tool that will execute the request, but rather the design of how it arrives. Four steps, in this order. First, give the request a single door, with a record: a short form or a queue with type, requester, owner and due date. The request stops being a message that interrupts and becomes an item that waits. The form cannot ask for more than the message already carried, or the team goes back to the shortcut. Second, separate urgent from routine with a written rule. Urgent interrupts, and the rule says what is urgent. Routine is handled in agreed windows, for example two a day. Third, measure for two weeks, with four data points per request: type, arrival time, start time and execution time. The gap between arrival and start is the wait, the same measurement described in [approval bottlenecks: where the process stops](/en/blog/approval-bottlenecks-where-process-stops). Add one question to the operator at the end of the day: on which requests did you lose the thread of what you were doing? Fourth, only then automate, starting with the type that repeats most. For status requests, an automation that tends to work is letting the requester check the state without having to ask. The opposite of the request-by-message path shows up in the [Reatop case](/en/cases/reatop): collectors record weighings and compliance in the app itself, even without signal, and the data syncs later. The record is born where the work happens. ## Frequently asked questions **My team will not accept changing how they ask. Won't the queue just become more bureaucracy?** It can, if it asks for more than the message did. Start with a single request type, with few fields, and show the requester the status of the request, which is what they gain. If the queue is slower than asking someone, the team will work around it, and that workaround is information about the design. **How do I measure the result without a finished system?** With a two-week spreadsheet and the four data points from the third step. It does not prove a productivity gain, but it shows the volume by type and which requests break someone's work. That is enough to decide what to change first, and it gives a baseline to compare against later. **What if the queue just moves the bottleneck?** It can. Track the wait between arrival and start: if it grows, the service window is too long or the request type should be urgent. The adjustment is to the queue rule, not a return to interruption. ## The next step If ad hoc requests are consuming your operation and you do not know how much, the Operational Architecture Diagnostic, a 30-minute conversation, is the place to map where they come in: [talk to Yowpi](/en/contact).