O handoff é o produto: quando o agente deve chamar o humano

Quase todo projeto de atendimento com IA é vendido pela taxa de automação: quantos por cento das conversas o robô resolve sozinho. É a métrica errada para começar. O que decide se o cliente confia no canal não é o que o agente resolve, é o que ele faz quando não deveria resolver. O repasse para o humano, feito na hora certa, com o contexto certo, é o que separa um canal que as pessoas usam de um canal que elas aprendem a contornar digitando “atendente” três vezes.

O que é handoff

Handoff, ou repasse, é a transferência de uma conversa em andamento do agente automático para uma pessoa, junto com todo o contexto necessário para que ela continue sem recomeçar. A palavra importante é junto: transferir a conversa sem transferir o contexto não é repasse, é abandono com aviso.

A razão para tratar isso como produto, e não como exceção, é que o repasse é onde o cliente forma a opinião sobre o canal inteiro. Uma conversa automática que resolveu bem gera indiferença, porque era o esperado. Uma conversa que precisou de gente e foi bem transferida gera confiança. Uma que precisou de gente e foi mal transferida gera a decisão de nunca mais usar aquele canal.

Há um segundo motivo, menos óbvio. O repasse é o mecanismo de segurança do sistema. Ele é o que impede que uma incerteza do modelo vire uma promessa errada ao cliente, um valor errado numa cobrança ou uma orientação errada em assunto que tem consequência. Sem ele, o agente é obrigado a responder sempre, e responder sempre significa inventar quando não sabe.

Um agente que nunca escala não é um agente confiável. É um agente que aprendeu a esconder o que não sabe.

Os quatro gatilhos de repasse

Na prática, quatro famílias de gatilho cobrem quase todos os casos reais. Escrever as quatro antes de desenhar o fluxo evita a armadilha mais comum, que é descobrir as regras depois, uma a uma, a cada reclamação.

Risco da ação. O primeiro e mais objetivo. Certas ações não devem ser executadas por decisão automática, independentemente de quão confiante o modelo esteja: cancelamento, estorno, alteração de dado cadastral sensível, concessão de desconto acima de um limite, qualquer coisa irreversível. Aqui o gatilho não olha para a conversa, olha para a ação pretendida.

Incerteza da resposta. Quando a informação necessária não foi encontrada na base da empresa, o agente não deve completar a lacuna com conhecimento geral. Esse é o gatilho que impede a resposta plausível e errada, que é o pior defeito de um sistema conversacional porque parece certo para quem lê.

Estado da conversa. Repetição da mesma pergunta, sinal de irritação, terceira tentativa sem avanço, menção a problema jurídico ou de saúde. São sinais de que continuar automático piora a situação, mesmo que tecnicamente o agente conseguisse responder.

Pedido explícito. A pessoa pediu para falar com alguém. Este gatilho é inegociável e não deve ter fricção. Todo minuto de resistência aqui é subtraído diretamente da confiança no canal, e o ganho de automação obtido dessa forma é o mais caro que existe.

Regra escrita, não intuição do modelo

Existe uma tentação forte de instruir o modelo com uma frase como “escale quando não tiver certeza” e considerar o problema resolvido. Isso não funciona de forma estável. A noção de certeza de um modelo varia com o texto da pergunta, com o histórico da conversa e com a própria versão do modelo, e o resultado é um comportamento que muda sem que ninguém tenha mudado nada.

A regra que sustenta produção é determinística e mora no fluxo, não no texto da instrução. Ela é avaliada por código, sobre sinais observáveis, e produz sempre o mesmo resultado para a mesma entrada.

Sinal observável	De onde vem	Decisão
Nenhum trecho recuperado da base	Etapa de busca	Repassa, sem tentar responder
Ação na lista de irreversíveis	Catálogo de ações	Repassa ou pede aprovação
Valor acima do limite configurado	Regra de negócio	Repassa
Terceira mensagem sem avanço	Contador da sessão	Repassa
Palavra da lista de urgência	Lista mantida pelo time	Repassa com prioridade
Cliente pediu atendente	Classificação de intenção	Repassa imediatamente
Cadastro não localizado	Consulta ao sistema	Repassa, não adivinha

O modelo continua tendo um papel: classificar intenção, detectar sinal de irritação, resumir a conversa. O que ele não faz é decidir sozinho se aquilo justifica escalar. A classificação é insumo, a decisão é da regra, e essa separação é o que torna o comportamento auditável.

O pacote de contexto

O que chega junto com a conversa transferida determina se o atendente resolve em dois minutos ou em doze. O pacote precisa caber em uma tela, porque um pacote que exige rolagem não é lido quando a fila aperta.

1. Quem é a pessoa. Nome, identificação no sistema e vínculo relevante, já resolvidos. O atendente nunca deve começar perguntando algo que o agente já sabia.
2. O que ela quer, em uma frase. Resumo da intenção, escrito pelo agente e revisável. Não o histórico bruto.
3. O que já foi feito. Consultas realizadas, informações confirmadas e ações executadas até ali, para não repetir nem contradizer.
4. Por que foi repassado. A regra que disparou, com nome. É isso que permite melhorar as regras depois, e é o campo que quase todo mundo esquece.
5. O que o agente sugere. Uma proposta de próximo passo, marcada claramente como sugestão, que o atendente aceita ou descarta.
6. O histórico completo, a um clique. Disponível, mas não em primeiro plano. Quem precisa, abre.

Um detalhe que muda a experiência do cliente: a última mensagem do agente antes de transferir precisa dizer o que vai acontecer, sem prometer prazo que o sistema não controla. “Vou passar para uma pessoa do time, com tudo o que conversamos” é honesto. “Em instantes você será atendido” é uma promessa que a fila costuma quebrar.

O tempo entre o repasse e a pessoa

Existe um intervalo que quase nenhum projeto desenha: o tempo entre o agente dizer que vai transferir e o atendente digitar a primeira mensagem. Em horário comercial pode ser um minuto. Fora dele, pode ser doze horas. Esse intervalo precisa de tratamento explícito, porque é onde o cliente decide se foi atendido ou descartado.

Três decisões resolvem a maior parte dos casos. A primeira é declarar o horário de atendimento humano no momento do repasse, com a informação real: fora do horário, dizer isso e dizer quando alguém retoma. A segunda é oferecer o que ainda pode ser resolvido automaticamente enquanto se espera, sem forçar. A terceira é garantir que a conversa não se perca se o cliente sair e voltar depois.

Vale também definir o que acontece se ninguém assumir. Um pedido de repasse que fica sem dono por um tempo definido precisa escalar de novo, para outro grupo ou para um responsável. Sem esse mecanismo, uma fila esquecida numa sexta-feira vira uma reclamação na segunda.

Handoff em WhatsApp, chat e voz

O mesmo desenho lógico se comporta de forma diferente em cada canal, e ignorar essas diferenças produz frustração previsível. A tabela resume o que muda na prática.

Aspecto	WhatsApp	Chat no site	Voz
Expectativa de resposta	Assíncrona, tolera minutos	Síncrona, tolera segundos	Imediata, não tolera silêncio
Fora do horário	Natural, basta avisar	Exige alternativa clara	Precisa de destino alternativo
Contexto ao transferir	Painel do atendente	Painel do atendente	Tela do operador antes de atender
Risco do repasse malfeito	Cliente some da conversa	Cliente fecha a aba	Cliente desliga e liga de novo
Identificação	Número já identifica	Depende de sessão ou login	Número identifica, com ressalva
Retorno ao agente	Simples, mesma conversa	Simples, mesma sessão	Difícil, quase sempre encerra

Um ponto sobre voz que costuma ser descoberto tarde: a transferência de chamada leva alguns segundos em que ninguém fala, e alguns segundos de silêncio numa ligação são interpretados como queda. Preencher esse intervalo com um aviso curto, gravado, sobre o que está acontecendo, resolve um problema que nenhum ajuste de fluxo resolve depois.

Quando o agente volta a assumir

O caminho de volta é tão importante quanto o de ida e recebe muito menos atenção. Depois que a pessoa resolveu o ponto que exigia julgamento humano, boa parte do que sobra é operacional: confirmar dados, agendar, enviar comprovante, registrar no sistema. Deixar tudo isso com o atendente desperdiça o tempo mais caro do processo.

A regra que funciona é o retorno explícito, nunca automático por tempo. O atendente devolve a conversa quando decide devolver, com um comando claro, e o agente confirma o que assumiu. Devolver automaticamente depois de alguns minutos de silêncio produz o pior resultado possível: o robô voltando a falar no meio de um assunto delicado que a pessoa estava conduzindo.

Também vale registrar o que aconteceu durante o trecho humano. O agente precisa saber o que foi combinado para não contradizer depois, e o registro dessa combinação é o que permite que a conversa seguinte, dali a duas semanas, comece do lugar certo.

Como calibrar a taxa de repasse

A pergunta que sempre aparece é qual a taxa ideal de repasse. Não existe número universal, porque a resposta depende do custo do erro naquele tipo de conversa. Uma dúvida sobre horário de funcionamento tem custo de erro quase zero. Uma orientação sobre medicação, sobre valor de cobrança ou sobre prazo contratual tem custo alto.

O método que funciona é começar conservador e afrouxar com evidência. Nas primeiras semanas, repasse mais do que o necessário e revise as conversas repassadas. Toda vez que uma amostra de repasses mostrar que o agente teria acertado, você tem base para relaxar aquela regra específica. O caminho contrário, começar solto e apertar depois do incidente, é mais rápido no papel e mais caro na prática.

As métricas que importam

Taxa de automação isolada engana, porque sobe quando o canal fica pior. O conjunto abaixo dá uma leitura honesta, e todas as métricas saem do registro que o sistema já produz.

Métrica	O que revela	Sinal de alerta
Taxa de repasse por regra	Qual gatilho está dominando	Uma regra sozinha acima de metade dos casos
Repasse por pedido explícito	Confiança no canal	Subindo mês a mês
Tempo até a primeira resposta humana	Qualidade real da experiência	Muito acima do prometido na mensagem
Retrabalho depois do repasse	Se o pacote de contexto serve	Atendente refazendo pergunta que o agente já fez
Reabertura em 48 horas	Se o problema foi resolvido mesmo	Alta com automação alta, sinal clássico
Conversas encerradas pelo cliente na espera	Abandono na transição	Qualquer valor relevante

A base que sustenta a resposta

Metade dos repasses que parecem problema de regra são, na verdade, problema de conteúdo. O agente escala porque não encontrou nada na base da empresa, e não encontrou porque a informação não está escrita em lugar nenhum, ou está escrita de um jeito que a busca não alcança. Ajustar a regra nesse caso é tratar sintoma.

A base que funciona tem três características. Primeira, ela responde em unidades pequenas e completas: um trecho sobre prazo de entrega precisa conter o prazo, as exceções e a data de atualização, sem depender de outro documento. Segunda, ela usa o vocabulário do cliente, não o interno: quem escreve pergunta sobre “segunda via do boleto” e não sobre “reemissão de título”. Terceira, ela tem dono e data, porque conteúdo desatualizado produz resposta confiante e errada, que é pior do que ausência de resposta.

Há um teste barato para saber se a base está pronta. Pegue as trinta perguntas mais frequentes do atendimento do último mês e procure a resposta de cada uma na base, do jeito que o cliente escreveu. As que você não encontrar em trinta segundos são exatamente as que vão virar repasse por ausência de informação, e a lista delas é a melhor pauta de conteúdo que existe.

Quem mantém as regras

Regra de repasse escrita em código, sem dono declarado, envelhece em silêncio. O limite de valor que fazia sentido em janeiro deixa de fazer em agosto, a lista de palavras de urgência não acompanha o vocabulário novo, e ninguém percebe até a reclamação.

O arranjo que funciona separa dois papéis. Quem responde pelo atendimento é dono do conteúdo das regras: quais ações são sensíveis, qual é o limite de valor, o que caracteriza urgência. Quem responde pela engenharia é dono do mecanismo: como a regra é avaliada, registrada e testada. Confundir os dois papéis produz ou regras que ninguém do negócio entende, ou mudanças de comportamento sem rastro.

Na prática, isso vira uma revisão mensal curta, sobre três números: quais regras dispararam mais, quais quase nunca disparam, e quantos repasses o time considerou desnecessários ao revisar a amostra. Regra que nunca dispara em três meses ou está sobrando ou está escrita errada, e as duas hipóteses merecem cinco minutos de conversa.

Erros comuns

• Tratar repasse como falha. Vira pressão para reduzir o número, e a redução vem por fricção, não por qualidade.
• Transferir sem contexto. O cliente repete tudo e conclui, com razão, que o robô fez ele perder tempo.
• Deixar a decisão de escalar a cargo do modelo. Comportamento diferente a cada semana, impossível de auditar.
• Prometer prazo que a fila não cumpre. Uma promessa quebrada custa mais que um aviso honesto.
• Não registrar qual regra disparou. Sem isso, não há como melhorar as regras, só opinião sobre elas.
• Devolver a conversa ao agente por tempo. O robô voltando a falar no meio de um assunto delicado.
• Ignorar o que acontece fora do horário. É onde acontece boa parte das conversas, e onde quase nenhum projeto desenha o comportamento.

Um desenho de referência

Este é o esqueleto que usamos como ponto de partida em atendimento por WhatsApp. Ele cabe em um fluxo de orquestração e não depende de nenhuma plataforma específica de atendimento.

1. Identificar antes de conversar. Cruzar o número com o cadastro. Sem correspondência, pedir um dado a mais em vez de seguir às cegas.
2. Classificar intenção e urgência. Duas saídas curtas, usadas como insumo pelas regras, nunca como decisão final.
3. Buscar na base da empresa. Se nada relevante voltar, o caminho é repassar, não completar com conhecimento geral.
4. Avaliar as regras de repasse. Em código, na ordem definida, com o nome da regra que disparou registrado.
5. Executar ou propor. Ação de baixo risco é executada e registrada. Ação sensível vira proposta de aprovação.
6. Montar o pacote e transferir. Seis campos, uma tela, com aviso honesto sobre horário e próximo passo.
7. Devolver por comando. O atendente decide quando o agente reassume, e o combinado durante o trecho humano fica registrado.

Perguntas frequentes

Qual é a taxa de repasse ideal?

Não existe número universal. A taxa certa é a que mantém o erro dentro do aceitável para aquele tipo de conversa. Dúvida operacional simples suporta automação alta. Assunto com consequência financeira, jurídica ou de saúde exige repasse frequente, e isso não é defeito do sistema.

O agente deve avisar que é um robô?

Sim, logo na primeira mensagem, de forma clara e sem rodeio. Além de ser a prática correta do ponto de vista de transparência, reduz frustração: a pessoa calibra a expectativa e pede o humano mais cedo quando precisa, o que melhora o atendimento em vez de piorar.

Como impedir que o agente invente uma resposta?

Com duas medidas combinadas: ancorar a resposta na base da empresa, de modo que ele só afirme o que foi recuperado, e transformar ausência de resultado em repasse por regra, não em tentativa de resposta. A segunda medida é a que mais falta nos projetos que apresentam esse problema.

E se não houver ninguém para receber o repasse?

O sistema precisa saber disso e dizer a verdade. Fora do horário, informe quando alguém retoma e registre o pedido numa fila com dono. O que não pode acontecer é transferir para o vazio, deixando a pessoa esperando por alguém que não existe naquele momento.

Dá para o agente aprender com os repasses?

Sim, e é o melhor uso do registro. Cada repasse marcado com a regra que disparou vira uma amostra para revisão. Repasses recorrentes por falta de informação na base indicam conteúdo faltando, e preencher essa lacuna reduz a taxa sem afrouxar nenhuma regra de segurança.

Isso funciona em voz também?

A lógica é a mesma, mas os prazos são muito menores e o silêncio é intolerável. Em voz, o pacote de contexto precisa estar na tela do operador antes de a chamada chegar nele, e a devolução ao agente raramente vale a pena, porque encerrar e registrar costuma ser mais limpo.

Quanto tempo leva para colocar isso no ar?

Com o canal já existente e acesso ao cadastro, um fluxo com as sete regras e o pacote de contexto costuma levar de duas a quatro semanas até o piloto em produção. O que domina o prazo raramente é o desenvolvimento: é definir as regras com quem responde pelo atendimento.

Próximo passo

Antes de desenhar qualquer fluxo, escreva a lista de ações que o seu atendimento nunca deve executar sem uma pessoa. Ela costuma ter menos de dez itens e resolve sozinha a maior parte das decisões de arquitetura que viriam depois.

Continuando pelo blog: Trilha de auditoria de agentes de IA em Postgres mostra como registrar cada repasse e cada aprovação, e Agente ou automação ajuda a decidir se o seu caso precisa mesmo de um agente.