# Custo da interrupção: o que o cronômetro da tarefa não vê > Medir só o tempo de executar o pedido avulso subestima o custo. Em estudo com 27 pessoas, retomar o trabalho levou 11 a 17 minutos. O ajuste está na entrada. - Autor: Marlon Trettin - Publicado: 2026-10-28 · Atualizado: 2026-10-28 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/custo-da-interrupcao-o-que-o-cronometro-nao-ve --- O pedido avulso custa mais do que o tempo de executá-lo. Num estudo com 27 funcionários, voltar ao trabalho interrompido levou, em média, de 11 a 17 minutos, conforme o canal. Quem cronometra só a execução subestima o custo. O ajuste é de arquitetura: mudar por onde o pedido entra. ## TL;DR - Um pedido avulso tem duas partes: fazer o que foi pedido e voltar ao que a pessoa fazia. A segunda costuma ficar fora da planilha de tempo. - Num estudo de campo com 27 funcionários, a fase de retomada levou em média de 11 a 17 minutos, com variação enorme. Em 27% das suspensões, mais de duas horas. - Num experimento com 48 participantes interrompidos a cada dois minutos, as tarefas terminaram mais cedo e o estresse subiu de 6,9 para algo entre 9,1 e 9,5, numa escala de 1 a 20. O cronômetro mostrou ganho. O custo apareceu em outro lugar. - Nossa leitura, que os estudos não testam: antes de automatizar a tarefa repetitiva, mude a entrada do pedido, de interrupção para fila registrada, e meça chegada e início. ## Por que cronometrar só a execução subestima o custo? Porque o pedido avulso tem duas partes, e o cronômetro costuma pegar uma. A primeira é fazer o que foi pedido. A segunda é voltar ao que a pessoa estava fazendo, e essa costuma ficar fora da planilha de tempo. Shamsi Iqbal e Eric Horvitz acompanharam, num [estudo de campo apresentado na CHI 2007](https://www.erichorvitz.com/CHI_2007_Iqbal_Horvitz.pdf), 27 funcionários do Microsoft Research por duas semanas, com 2.267 horas de atividade registradas. Eles mediram a fase de retomada: o intervalo entre o sinal de que a pessoa quer voltar à tarefa e o retorno ao estado em que ela estava antes de sair. Depois de um e-mail respondido na hora, a retomada levou em média 16 minutos e 33 segundos. Depois de uma mensagem instantânea respondida na hora, 10 minutos e 58 segundos. Para respostas adiadas, foram 15 minutos e 50 segundos e 12 minutos e 2 segundos. A dispersão pesa tanto quanto a média. O desvio-padrão da retomada após e-mail adiado foi de 25 minutos, o que indica casos curtos ao lado de casos muito longos. Segundo os autores, 27% das suspensões de tarefa levaram mais de duas horas até a retomada. O estudo mede o intervalo e não afirma que ele inteiro é tempo parado. O mecanismo tem nome. Sophie Leroy, da University of Washington Bothell, descreve em [sua página](https://www.uwb.edu/faculty/sophie-leroy/) o resíduo de atenção: ao trocar de tarefa, parte da atenção fica com a anterior, e isso acontece com facilidade quando a tarefa foi deixada inacabada ou interrompida. Segundo ela, o desempenho na tarefa seguinte tende a piorar, sobretudo se ela for exigente. ## O que muda quando o custo não aparece no tempo? O indicador de tempo pode melhorar enquanto o custo sobe em outro lugar. Gloria Mark, Daniela Gudith e Ulrich Klocke compararam, num [experimento apresentado na CHI 2008](https://www.interruptions.net/literature/Mark-CHI08.pdf), 48 participantes que, no papel de gestor de RH de uma empresa simulada, respondiam e-mails, com e sem interrupções a cada dois minutos. Quem foi interrompido terminou antes: 22,77 minutos sem interrupção, contra 20,31 com interrupção do mesmo assunto e 20,60 com assunto diferente, sem contar o tempo da interrupção em si. O preço apareceu nas respostas dos participantes. O estresse subiu de 6,92 para 9,46 e 9,13, numa escala de 1 a 20. O esforço foi de 9,50 para 11,04 e 11,52. Frustração e pressão de tempo também subiram. A leitura dos autores é que as pessoas compensam trabalhando mais rápido e escrevendo menos, ao custo de estresse e esforço. Para uma operação, a hipótese a testar é esta: o tempo por tarefa pode melhorar numa semana em que a equipe está pior. ## O que esses estudos não provam? Eles mostram a ordem de grandeza do problema, não o tamanho dele na sua empresa. Alguns limites importam para quem decide. Nenhum dos dois mede uma operação de PME. O estudo de Iqbal e Horvitz vem de uma única organização de pesquisa, e os autores reconhecem que não conseguem provar que o alerta causou a troca de tarefa: eles ligaram os dois por uma regra de 15 segundos. O de Mark é de laboratório, com 81% de estudantes universitários alemães e cerca de 20 minutos de trabalho. Os autores dizem não saber se as pessoas se adaptariam com o tempo e tratam a explicação da aceleração como interpretação, não como mecanismo testado. Além disso, alerta de e-mail não é pedido de operação. Quem recebe "manda a segunda via da nota" executa e registra, e isso é outra tarefa. Por isso a medição própria vem antes de qualquer conta. ## Como isso aparece numa operação de PME? Como um número que costuma ficar sem registro. O exemplo a seguir é uma hipótese ilustrativa, não uma medição. Imagine o backoffice de uma distribuidora com seis pessoas. Pedidos de segunda via de nota, status de entrega e correção de cadastro chegam por mensagem direta a quem estiver à mão. Suponha que um operador receba 24 pedidos por dia e leve 4 minutos para executar cada um. São 96 minutos, 20% de um dia de 8 horas. É o que a planilha de tempo mostra. Agora suponha, sem medição nenhuma, que cada interrupção custe 6 minutos de retomada. São 144 minutos a mais, e o total chega a 240 minutos, metade do dia. Se a retomada custasse 2 minutos, seriam 48 a mais e 144 no total, 30%. Nessa hipótese, a faixa vai de 30% a 50% do dia. O que decide onde a operação cai nela é um dado que costuma ficar fora da planilha: quanto o operador demora para voltar ao que fazia. Pedidos assim entram com frequência na lista de tarefas repetitivas a automatizar. Se a automação vier antes de mudar como o pedido entra, ela herda o desenho da interrupção. Já tratamos da ordem de escolha em [tarefas repetitivas: o que eliminar primeiro](/blog/tarefas-repetitivas-o-que-eliminar-primeiro). ## O que fazer antes de automatizar o pedido avulso? Esta parte é leitura nossa, não resultado dos estudos: o problema aqui raramente é a ferramenta que vai executar o pedido, e sim o desenho de como ele chega. Quatro passos, nesta ordem. Primeiro, dê ao pedido uma porta única, com registro: um formulário curto ou uma fila com tipo, solicitante, dono e prazo. O pedido deixa de ser uma mensagem que interrompe e passa a ser um item que espera. O formulário não pode pedir mais do que a mensagem já informava, senão a equipe volta para o atalho. Segundo, separe o urgente do rotineiro por uma regra escrita. O urgente interrompe, e a regra diz o que é urgente. O rotineiro é atendido em janelas combinadas, por exemplo duas por dia. Terceiro, meça por duas semanas, com quatro dados por pedido: tipo, hora de chegada, hora de início e tempo de execução. A diferença entre chegada e início é a espera, a mesma medição descrita em [gargalo de aprovação: onde o processo para](/blog/gargalo-de-aprovacao-onde-o-processo-para). Some uma pergunta ao operador no fim do dia: em quais pedidos você perdeu o fio do que estava fazendo? Quarto, só então automatize, começando pelo tipo que mais se repete. Para pedidos de status, uma automação que costuma funcionar é deixar o solicitante consultar o estado sem precisar pedir. O caminho oposto ao pedido por mensagem aparece no [case Reatop](/cases/reatop): os coletores registram pesagens e conformidade no próprio aplicativo, mesmo sem sinal, e o dado sincroniza depois. O registro nasce onde o trabalho acontece. ## Perguntas frequentes **Minha equipe não aceita mudar o jeito de pedir. A fila não vira só mais burocracia?** Pode virar, se pedir mais do que a mensagem pedia. Comece por um único tipo de pedido, com poucos campos, e mostre ao solicitante o estado do pedido, que é o que ele ganha. Se a fila for mais lenta do que perguntar a alguém, a equipe vai contorná-la, e esse contorno é informação sobre o desenho. **Como medir o resultado sem um sistema pronto?** Com uma planilha de duas semanas e os quatro dados do terceiro passo. Não prova ganho de produtividade, mas mostra o volume por tipo e quais pedidos quebram o trabalho de alguém. Isso basta para decidir o que mudar primeiro e dá uma linha de base para comparar depois. **E se a fila só mover o gargalo?** Pode mover. Acompanhe a espera entre chegada e início: se ela crescer, a janela de atendimento está longa demais ou o tipo de pedido deveria ser urgente. O ajuste é na regra da fila, não na volta à interrupção. ## O próximo passo Se os pedidos avulsos consomem a operação e você não sabe quanto, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, é o lugar para mapear por onde eles entram: [fale com a Yowpi](/contato).