# Passagem de bastão entre áreas: onde o pedido se perde > O pedido se perde na entrega entre áreas porque o contexto fica com quem entrega. Veja como estruturar a passagem com registro único e aceite de quem recebe. - Autor: Marlon Trettin - Publicado: 2026-10-27 · Atualizado: 2026-10-27 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/passagem-de-bastao-entre-areas-onde-o-pedido-se-perde --- O pedido se perde no momento em que uma área entrega a outra, porque o contexto fica na cabeça de quem entregou e quem recebe só tem a mensagem. O problema é de arquitetura, não de atenção das pessoas. A saída é um registro único que viaja com o pedido, campos obrigatórios e um aceite explícito de quem recebe. ## TL;DR - A passagem entre áreas é um dos pontos mais frágeis de um processo. Num levantamento reportado pela AHRQ, 43% de 60 ações por erro cirúrgico ligadas a falha de comunicação envolviam passagem mal feita. - Num estudo publicado no *New England Journal of Medicine* com 10.740 internações, a taxa de erros médicos por internação caiu 23% e a de eventos adversos evitáveis caiu 30% depois de um programa de passagem estruturada, comparando seis meses antes e seis meses depois. - Em experimento da NASA com 50 participantes, reforçar o texto escrito com conversa, vídeo ou áudio reduziu os erros de tarefa. - O caminho é desenhar a passagem no sistema: registro único, campos obrigatórios, aceite do receptor e conferência depois. ## Onde o pedido se perde entre duas áreas? Na entrega, e quase nunca no trabalho de cada área. Quem entrega conhece o contexto: o que o cliente pediu fora do formulário, o que já foi combinado, o que está pendente. Quem recebe vê o que chegou. Essa diferença é a passagem de bastão, ou *handoff*, e é onde a informação some sem que ninguém tenha errado. A medicina estudou isso de perto, porque o custo de errar é alto e o registro é bom. O caso "Empty Handoff", publicado em 2012 pela AHRQ, agência federal de pesquisa e qualidade em saúde dos Estados Unidos, relata um paciente que chegou à cirurgia sem que a equipe soubesse da sensibilidade dele à insulina. A enfermeira pediu a um auxiliar que avisasse, o aviso não foi passado e o aparelho de glicemia não estava encaixado, então a leitura baixa nunca chegou ao prontuário. O comentário cita um levantamento de 60 ações de responsabilidade por erro cirúrgico ligadas a falha de comunicação: 43% envolviam passagem mal feita. Hospital não é a sua empresa. O mecanismo se parece: a informação depende de uma pessoa lembrar de repassá-la, por um canal que não obriga ninguém a confirmar. Os autores do caso concluem que confiar em indivíduos para cobrir a lacuna é pouco confiável, mesmo com profissionais cuidadosos. ## O que muda quando a passagem tem estrutura? Os erros caem de forma mensurável. Starmer e colegas testaram o programa I-PASS em nove hospitais pediátricos, com 10.740 internações, em três fases de seis meses: observação, treinamento com uso obrigatório e acompanhamento. Os erros médicos passaram de 24,5 para 18,8 por 100 internações, uma queda de 23%. Os eventos adversos evitáveis caíram de 4,7 para 3,3 por 100, queda de 30%. O resultado saiu no *New England Journal of Medicine* em 2014. O I-PASS não é só um roteiro de fala. Reúne treinamento, uma conversa verbal em cinco partes (gravidade do caso, resumo, lista de ações, consciência da situação com plano de contingência e síntese feita pelo receptor), ferramentas digitais que seguem a mesma estrutura, supervisão e uma campanha interna. O desenho é antes versus depois, sem grupo de controle simultâneo, então o número mostra associação, não prova isolada de causa. A parte que importa para a sua operação é a última letra: quem recebe resume de volta o que entendeu. A passagem só termina quando o receptor confirma. ## Mensagem escrita basta como passagem? Não, quando ela é o único canal. Parke, Hobbs e Kanki, da NASA, fizeram um experimento com 50 participantes numa tarefa que imitava passagens de turno em ambientes industriais. Reforçar o registro escrito com conversa presencial, vídeo ou áudio reduziu os erros de tarefa de forma significativa, e o texto sozinho foi a modalidade menos preferida. O resumo do estudo não traz as taxas de erro. A leitura que fazemos para uma empresa é esta: o que reduz o erro é a chance de o receptor perguntar e o entregador corrigir. Num sistema, o equivalente é um aceite com devolução, e não uma notificação que o receptor só marca como lida. Essa leitura é nossa, não do estudo. ## Um exemplo prático: a proposta aprovada que vira apólice errada O cenário a seguir é hipotético, sem números medidos. Uma corretora de seguros tem o comercial de um lado e a emissão de outro. O corretor fecha uma proposta empresarial e, por telefone, o cliente pede uma cobertura adicional para um galpão. O corretor anota no chat da equipe: "aprovado, pode emitir". A emissão recebe a mensagem, abre o formulário padrão e emite a apólice sem o adicional. Ninguém trabalhou mal, e isso diz onde está o problema: não é de atenção, é de arquitetura. O corretor passou a informação que julgou central, e a emissão fez exatamente o que a mensagem pedia. O erro aparece meses depois, num sinistro, ou numa renovação em que o cliente estranha o valor. A informação do pedido existia, só não viajou. Uma passagem estruturada teria três mudanças. A proposta aprovada seguiria como um registro único, com o histórico do que foi combinado, e não como mensagem solta. Um campo obrigatório de "condições fora do padrão" não deixaria o pedido sair vazio. E a emissão só aceitaria o pedido depois de devolver um resumo do que vai emitir, para o corretor conferir. ## Como desenhar a passagem no sistema? Com quatro elementos, que são a nossa tradução do I-PASS para uma operação de empresa, e não uma receita dos autores. O primeiro é o registro único: o pedido segue como o mesmo objeto de uma área para a outra, com o histórico junto. Quando cada etapa abre um registro novo e copia dados à mão, a passagem vira digitação, e o contexto fica para trás. O segundo são os campos obrigatórios, escolhidos pela pergunta "o que o receptor precisa saber e não consegue deduzir": prazo e prioridade, o que foi combinado fora do formulário, o que ainda falta e o que pode dar errado. O terceiro é o aceite do receptor. Quem recebe confirma o que entendeu, e o sistema só move o pedido de etapa depois disso. O quarto é a conferência posterior. O comentário publicado pela AHRQ recomenda verificar, depois da passagem, se expectativa, situação e documentação batem, porque a maioria dos erros de passagem não causa dano na hora e pode ficar escondida por muito tempo. Em sistema, isso vira uma checagem simples: o que foi emitido corresponde ao que foi aprovado? Dois artigos do blog tratam de vizinhos desse problema. [Exceção no processo: o caminho que ninguém registra](/blog/excecao-no-processo-caminho-sem-registro) trata do que a equipe faz quando o sistema não cobre o caso, e a passagem informal por mensagem é um desses caminhos. Já [Gargalo de aprovação: onde o processo realmente para](/blog/gargalo-de-aprovacao-onde-o-processo-para) mostra a outra metade: a espera entre uma área e a próxima. O [case da SuperVida](/cases/super-vida) mostra o registro único aplicado à operação inteira: contratos, beneficiários, vendedores e parceiros passaram a ser administrados em um só lugar quando a gestão da rede de cartão de benefícios saiu do Airtable para um ERP sob medida, entregue em 2023. ## Perguntas frequentes **Minha equipe está acostumada a passar o pedido por mensagem. Ela vai aceitar um formulário?** Depende de quanto ele custa a quem entrega. Se o campo obrigatório é preenchido em segundos e evita a pergunta de volta, a equipe tende a adotá-lo. Comece por um único tipo de pedido, o que mais gera retrabalho, e deixe a mensagem como complemento, não como canal. **A integração com o que já uso vai ser complicada?** Nem sempre exige integrar tudo. O ponto crítico é uma só passagem, entre duas áreas, e o registro pode nascer no sistema que já existe ou num módulo novo, desde que os dados da etapa anterior cheguem junto. Mapear qual dado cruza a fronteira é o primeiro passo, antes de escolher qualquer ferramenta. **Não sei se isso tem retorno financeiro. Como medir?** Meça antes de mudar: quantos pedidos voltam para a área anterior, quanto tempo levam parados esperando esclarecimento e quantos erros chegam ao cliente. Os estudos citados são da saúde e da NASA, então não servem de meta para a sua operação. A sua linha de base é o que vale. ## O próximo passo Se hoje os pedidos mudam de área por mensagem e ninguém confirma o que entendeu, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, é um convite para mapear onde essas passagens acontecem e o que cada uma precisa levar: [fale com a Yowpi](/contato).