Quando o agente de IA deve transferir para um humano

O agente de IA deve transferir o atendimento quando o cliente pede uma pessoa, quando a tarefa sai do escopo autorizado ou quando continuar pode aumentar um erro. Mas reconhecer o momento é apenas o começo. A transferência precisa chegar a uma fila acompanhada, levar o contexto necessário e definir quem responde a partir dali. Escrever “vou chamar um atendente” sem executar essas etapas deixa o cliente esperando por uma ação que talvez nem tenha acontecido.

Este guia propõe um processo operacional para essa passagem: os gatilhos de encaminhamento, a confirmação do recebimento, a pausa do bot, o resumo para a equipe e a eventual retomada da automação. As regras de processo apresentadas são recomendações editoriais para adaptar à operação. As funções específicas de plataformas são identificadas e acompanhadas de documentação oficial. Os exemplos de conversa são hipotéticos.

Quando transferir e quando fazer uma pergunta

Comece pelo pedido explícito. Se a pessoa escreve “quero falar com alguém da equipe”, o encaminhamento não deveria depender de convencer o bot de que o assunto é difícil. A recomendação é reconhecer o pedido e executar o fluxo disponível. Caso seja necessário identificar o setor, faça apenas a pergunta que realmente muda o destino. Um questionário inteiro antes de permitir o contato humano cria uma barreira desnecessária.

O segundo grupo envolve limites da tarefa. Um agente pode ter autorização para informar características de um produto, mas depender de uma pessoa para avaliar uma condição especial. Nesse caso, a informação que falta não é uma frase melhor no prompt: é uma decisão fora da autonomia do sistema. O limite deve estar descrito na operação, incluindo o que o bot pode explicar enquanto aguarda e o que precisa deixar pendente.

Já uma dúvida simples não exige, por si só, transferência. Se o cliente pergunta sobre “o pedido” e há mais de um registro possível, uma pergunta curta de identificação pode resolver a ambiguidade. A diferença está em saber se existe um próximo passo seguro e útil. Se o agente já pediu o mesmo dado e a conversa continua sem avançar, insistir na mesma pergunta tende a prolongar o problema. Defina um ponto de interrupção e encaminhe com esse histórico.

A documentação de transferência do Microsoft Copilot Studio descreve encaminhamentos por solicitação do usuário e por situações identificadas durante a conversa. Também explica que, em um hub de atendimento conectado, a passagem pode incluir histórico, variáveis e uma mensagem privada para o atendente. Essa possibilidade depende da integração configurada; não representa uma garantia para qualquer chatbot ou canal.

Observe o problema, não apenas uma palavra

Palavras como “atendente” e “pessoa” ajudam a reconhecer um pedido, mas não cobrem todas as situações. “Você já perguntou isso”, “não foi o que eu pedi” e “preciso que alguém resolva” podem indicar uma conversa travada. A regra deve considerar o contexto: uma correção isolada pode ser resolvida normalmente; várias tentativas sem avanço pedem outro tratamento. Evite interpretar qualquer tom direto como motivo automático para encerrar a participação do agente.

Transforme o critério em uma regra que a equipe entende

Uma orientação genérica como “transfira quando necessário” deixa decisões importantes abertas. Escreva os gatilhos com a equipe que recebe as conversas. Para cada um, registre o setor de destino, o motivo que aparece para o atendente, os dados indispensáveis e a resposta esperada quando não houver ninguém disponível. O objetivo é que duas pessoas consigam olhar a mesma conversa e reconhecer a regra aplicada.

A tabela abaixo é um modelo de decisão, não uma configuração pronta de plataforma. Ela precisa ser adaptada aos serviços oferecidos e às responsabilidades da empresa. Preserve os critérios simples o suficiente para serem explicados em treinamento. Se a transferência depende de uma condição que ninguém consegue conferir, será difícil investigar por que uma conversa chegou ao destino errado.

Use essa definição como parte do briefing da implementação. Ela precisa existir tanto para quem escreve as instruções do agente quanto para quem configura o sistema de atendimento. O artigo sobre briefing e instruções de trabalho com agentes ajuda a organizar responsabilidades e critérios antes da execução. Aqui, o ponto central é transformar uma preferência de atendimento em comportamento observável.

Pedido enviado, fila recebida e pessoa responsável

Uma transferência tem etapas diferentes. O agente identifica o motivo e solicita o encaminhamento. O sistema de atendimento recebe essa solicitação e a coloca no destino. Depois, alguém assume a conversa. Recomendamos registrar essas etapas separadamente porque cada uma sustenta uma mensagem diferente ao cliente. Um pedido de encaminhamento não comprova que há um atendente lendo a conversa.

Essa distinção aparece na documentação de fulfillment do Dialogflow CX: o sinal liveAgentHandoff informa o encaminhamento à integração chamadora; ele não altera, sozinho, o estado da sessão. A integração precisa executar as ações correspondentes. Portanto, a presença de uma intenção ou de um evento chamado “transferir” não basta para demonstrar que a passagem foi concluída.

Peça uma prova do recebimento

Na demonstração do fornecedor, acompanhe uma conversa de teste nos dois lados. Faça o pedido pelo canal do cliente e confirme que ele apareceu no painel correto. Verifique se existe um identificador de conversa ou protocolo que permita relacionar o pedido ao registro recebido. Depois, peça a uma pessoa da equipe que assuma esse atendimento. Essa sequência separa uma mensagem bem escrita de uma integração que funciona.

Se houver atraso ou falha de resposta da integração, trate o resultado como pendente até conseguir verificá-lo. Repetir a solicitação imediatamente pode criar duas entradas para o mesmo problema. A implementação deve prever uma forma de reconhecer que uma tentativa pertence à mesma transferência. Para entender essa preocupação em integrações, veja o tutorial de webhook, confirmação e idempotência. A solução depende do sistema usado; o requisito de atendimento é não perder nem duplicar a solicitação.

Separe os estados da conversa para evitar respostas simultâneas

Depois do encaminhamento, quem pode responder? Essa pergunta merece uma regra explícita. Como modelo operacional, separe a conversa em atendimento pelo bot, transferência pendente, espera na fila, atendimento humano e encerramento. Os nomes podem mudar conforme a plataforma. O que precisa permanecer claro é a condição que autoriza uma resposta automática em cada etapa.

Em atendimento humano, a recomendação é suspender as respostas livres do bot naquela conversa. A equipe pode usar recursos internos de apoio, se isso fizer parte do projeto, mas a mensagem ao cliente deve ter um responsável definido. Sem essa coordenação, o bot pode responder a uma pergunta enquanto o atendente está explicando outra coisa. O cliente recebe duas orientações e não sabe qual delas vale.

Na transferência pendente, a automação ainda pode precisar informar um erro de encaminhamento. Na fila, pode existir uma mensagem de acompanhamento prevista pela operação. Essas mensagens devem ser limitadas e coerentes com o estado real. “Bot pausado” não precisa significar abandonar o cliente sem qualquer informação; significa impedir que o agente continue tocando o assunto como se ainda fosse o responsável pela solução.

Confira também mensagens que já estavam sendo preparadas

Uma resposta automática pode ter começado a ser gerada antes de a equipe assumir. Por isso, o teste precisa incluir uma mensagem em processamento no momento da transferência. A implementação deve revalidar quem controla a conversa antes de enviar a resposta. Se o atendimento já estiver com uma pessoa, a resposta antiga deve ser descartada ou levada apenas ao apoio interno, conforme a configuração adotada.

Esse cuidado faz parte da arquitetura do atendimento, junto com o canal e as integrações. O guia sobre como criar um chatbot no WhatsApp com arquitetura de atendimento oferece o contexto geral. A passagem para a equipe precisa ser considerada desde esse desenho, e não acrescentada apenas como uma frase no final do prompt.

O resumo que permite continuar sem começar do zero

O atendente precisa saber o que a pessoa quer, o que já aconteceu e qual é a pendência. Um resumo útil pode trazer o motivo da transferência, o pedido do cliente, as informações que ele forneceu, as consultas realizadas e os resultados confirmados. Se alguma ação ficou sem confirmação, registre isso como incerteza. Não transforme uma tentativa de consulta em uma consulta concluída.

Evite copiar toda a conversa para um campo curto e chamar isso de resumo. Se houver acesso ao histórico, mantenha o vínculo com ele e destaque o que permite continuar. Separe o que foi dito pelo cliente do que foi inferido pelo agente. Também não envie informações de outras conversas ou dados que o setor de destino não precisa para resolver aquela demanda.

Exemplo hipotético de resumo para uma loja

Pedido: cliente quer saber se um produto pode ser separado para retirada. Já informado: modelo e preferência de horário. Já consultado: descrição do produto na base; a disponibilidade para separação não foi confirmada. Pendente: equipe verificar disponibilidade e condições da retirada. Motivo: essa confirmação está fora da autonomia do agente.

Nesse exemplo, o resumo não afirma que o produto foi reservado, nem que o cliente já aceitou uma condição que ainda não recebeu. A pessoa responsável consegue identificar a próxima ação sem pedir tudo novamente. Se o cliente corrigir o modelo enquanto aguarda, o resumo ou o histórico destacado precisa refletir a atualização. Um texto correto no momento da criação pode ficar desatualizado durante a espera.

O que dizer ao cliente em cada etapa

A mensagem precisa descrever o que o sistema sabe. Antes de receber a confirmação, uma formulação hipotética seria: “Vou solicitar o encaminhamento para a equipe responsável.” Depois de a fila registrar o pedido, a informação pode ser: “Seu pedido ficou registrado para a equipe. A conversa está aguardando atendimento.” A frase deve ser adaptada ao canal e à operação, sem prometer uma presença que ainda não existe.

Quando houver confirmação de que uma pessoa assumiu, informe a mudança se isso não estiver claro na própria interface. O atendimento humano pode começar recuperando a pendência: “Vi que falta confirmar a possibilidade de retirada.” Isso mostra continuidade de forma concreta. Evite começar pedindo nome, produto e motivo novamente se essas informações já estiverem disponíveis e confiáveis.

O campo de encaminhamento também tem função de acompanhamento. A referência REST de Fulfillment do Dialogflow CX descreve liveAgentHandoff como sinal associado à passagem para atendimento humano e ao seu acompanhamento. O comportamento efetivo depende do chamador. Essa diferença reforça a necessidade de conferir a integração e a conversa recebida, além do evento emitido pelo agente.

Se o encaminhamento falhar, diga que o registro não foi confirmado e apresente apenas a alternativa real disponível. Não substitua a falha por “aguarde só um instante” em um ciclo sem saída. Uma opção pode ser tentar novamente de forma controlada; outra pode ser oferecer um canal operado pela equipe. Qualquer alternativa precisa ter sido definida pela empresa e testada antes de aparecer para o cliente.

Como tratar fila cheia e atendimento fora do horário

Estar conectado ao canal não significa ter alguém disponível para assumir a conversa. Antes de informar um encaminhamento imediato, o fluxo precisa considerar o expediente do setor, as ausências previstas e a capacidade real de atendimento. O agente não deve inventar prazo para tornar a resposta mais confortável. Se a operação não oferece previsão confiável, diga isso de maneira objetiva e informe o próximo passo possível.

Fora do horário, uma alternativa é registrar a solicitação para análise na próxima abertura. Essa frase só faz sentido se o registro realmente existir e houver uma rotina de leitura. Defina quem confere as pendências ao iniciar o expediente e como identifica o que já foi atendido por outro canal. Sem essa responsabilidade, a fila pode crescer silenciosamente enquanto o cliente acredita que alguém vai retornar.

Permita continuar somente o que ainda é seguro

Em algumas operações, a pessoa pode querer consultar uma informação geral enquanto aguarda. Isso pode ser permitido, desde que não retire o pedido da fila nem reabra automaticamente a decisão pendente. Em outras, o melhor é manter o bot pausado. A escolha deve considerar o serviço e a capacidade de separar assuntos, com uma explicação simples para o cliente.

Se a pessoa desiste da espera, registre o cancelamento do encaminhamento de maneira distinta de “demanda resolvida”. Desistir de aguardar não comprova que a necessidade deixou de existir. Também evite reinserir automaticamente na fila uma conversa cancelada apenas porque chegou uma nova mensagem genérica. Primeiro, reconheça o novo pedido e aplique a regra correspondente.

Quando o bot pode voltar à conversa

O retorno da automação precisa de um gatilho tão claro quanto a transferência. Uma mensagem recebida depois de um período de silêncio não deveria, sozinha, devolver a conversa ao agente. O atendente pode estar trabalhando em uma resposta ou esperando uma informação de outro setor. O processo deve prever encerramento, devolução explícita ao bot ou outra condição definida e verificável.

Antes de retomar, confira se há tarefa pendente. Um encerramento pode significar que o atendimento terminou, que foi encaminhado novamente ou apenas que uma tela foi fechada. Esses eventos não são equivalentes. A equipe precisa conhecer o efeito de cada comando do painel para não liberar a automação sem perceber. A documentação deve usar os nomes dos botões que as pessoas realmente encontram na interface.

Preserve o resultado do atendimento humano

Se uma pessoa confirmou uma condição durante a conversa, o bot não pode voltar ignorando esse resultado e repetir a orientação anterior. Recomendamos registrar uma conclusão curta, com a próxima etapa e as restrições aplicáveis. O agente deve receber apenas o contexto autorizado e necessário para a continuidade. Se não houver uma conclusão confiável, é melhor manter a pendência visível do que inventar uma resolução.

Permissões também entram nessa decisão: quem pode devolver a conversa ao bot, mudar o setor ou encerrar uma pendência? O texto sobre permissões e limites de agentes nas empresas ajuda a estruturar essa conversa. O princípio operacional é simples: a retomada precisa corresponder a uma decisão válida e compreensível para a equipe.

Testes de erro antes de colocar o fluxo em produção

Comece pelo caminho completo que deveria funcionar. Em uma conversa de teste identificada, solicite uma pessoa, confirme o recebimento no setor correto, confira o resumo, assuma o atendimento e envie uma nova mensagem pelo lado do cliente. O bot deve respeitar o estado combinado. Depois, encerre ou devolva a conversa pela ação prevista e verifique a retomada com o contexto atualizado.

Em seguida, simule uma falha de encaminhamento em ambiente de teste. A solicitação pode ser recusada ou ficar sem confirmação. Observe a mensagem ao cliente e o registro da pendência. O teste não passa apenas porque o erro apareceu em um log técnico: precisa existir um tratamento que a equipe consiga acompanhar. O cliente também precisa receber uma informação compatível com a situação.

Reenvio do mesmo evento

Repita a entrega do mesmo evento de transferência e confira se o sistema cria uma entrada duplicada. A expectativa é que a implementação reconheça a tentativa já registrada ou concilie o resultado antes de abrir outra. Essa conferência é especialmente útil quando há integrações que repetem uma chamada após atraso. Não confunda duas mensagens legítimas do cliente com a repetição técnica de um mesmo evento.

Pessoa assume enquanto o bot prepara a resposta

Faça o agente começar uma resposta e assuma a conversa antes do envio. Depois, confira o lado do cliente. Se a mensagem automática antiga aparecer, o bloqueio de concorrência precisa ser corrigido. Teste também a chegada de outra mensagem durante a espera na fila, para verificar se ela se mantém associada ao atendimento e se o contexto relevante chega à pessoa responsável.

Expediente encerrado e correção de contexto

Execute o pedido com o setor indisponível e confirme o registro para acompanhamento. Em outro teste, corrija um dado após a transferência, como o modelo de produto do exemplo hipotético. O atendente precisa enxergar a correção. Por fim, simule o cancelamento da espera e a chegada de uma nova pergunta. Esses caminhos revelam falhas que uma demonstração apenas com o roteiro feliz costuma deixar escondidas.

O que acompanhar depois da implantação

Separe pelo menos três acontecimentos no acompanhamento: a transferência foi solicitada, o destino confirmou o recebimento e uma pessoa assumiu. Registre também falhas, cancelamentos e devoluções ao bot. Essa distinção ajuda a localizar o ponto de interrupção. Contar apenas quantas vezes o agente escreveu “vou transferir” não demonstra quantas pessoas receberam atendimento.

Escolha uma amostra de conversas e confira a continuidade. O cliente precisou repetir informações? O resumo mostrou o motivo correto? Houve resposta automática depois da entrada humana? A pendência foi encerrada com um resultado identificável? Essas perguntas aproximam a avaliação da experiência real e ajudam a orientar ajustes no processo, na integração e no treinamento da equipe.

Uma taxa alta de transferência pode ter causas diferentes. Talvez o bot esteja recebendo demandas fora do seu escopo, a base não responda às dúvidas mais frequentes ou a regra de encaminhamento esteja ampla demais. Uma taxa baixa também merece leitura: pode indicar autonomia adequada ou dificuldade para chegar a uma pessoa. Analise o motivo e o desfecho das conversas antes de alterar o gatilho para aumentar ou diminuir um número.

Para liberar o piloto, a empresa precisa conseguir demonstrar o fluxo e explicar as exceções. A evidência esperada é uma conversa de teste acompanhada do registro recebido, da mudança de responsável e do comportamento após o encerramento. Se uma dessas etapas ainda depende de suposição, registre a pendência e corrija antes de ampliar o uso. A finalidade da conferência é dar uma saída concreta ao cliente quando o agente precisa de ajuda.

Perguntas frequentes sobre transferência para atendimento humano

O agente deve tentar resolver antes de aceitar o pedido por uma pessoa?

Quando o pedido é explícito, a recomendação é respeitá-lo. Uma pergunta breve pode ser necessária para identificar o setor, mas não deveria virar uma nova barreira. Se houver uma opção de continuar com o agente enquanto aguarda, apresente-a como escolha e preserve o encaminhamento. A regra precisa refletir o processo de atendimento que a empresa consegue cumprir.

Enviar uma notificação para a equipe já conclui a transferência?

Não necessariamente. Uma notificação emitida comprova apenas aquela etapa, conforme a integração. Confira se a conversa entrou no destino correto e se existe uma forma de alguém assumir e acompanhar a pendência. A mensagem ao cliente deve distinguir solicitação enviada, recebimento na fila e entrada de uma pessoa. Sem essa separação, é fácil anunciar uma conclusão que ainda não ocorreu.

O bot precisa ficar completamente mudo enquanto o cliente espera?

A operação pode prever mensagens limitadas de acompanhamento, desde que elas descrevam o estado real. O essencial é impedir respostas livres que conflitem com o atendimento humano ou com a decisão pendente. Defina quais mensagens são permitidas em cada estado e teste a chegada de novas perguntas durante a fila. A escolha deve ser clara para a equipe e para quem usa o canal.

Qual deve ser o prazo prometido para o atendimento humano?

Use apenas uma previsão que a empresa consiga sustentar e acompanhar. Se não houver previsão confiável, informe a indisponibilidade e o próximo passo real, como o registro para análise no expediente. Não copie um prazo de outra operação nem gere um número para completar a resposta. Confira também quem será responsável por ler e tratar as solicitações pendentes.

Posso ativar a retomada automática depois de alguns minutos sem mensagem?

O silêncio, isoladamente, não confirma que a atuação humana terminou. Prefira uma condição verificável de encerramento ou devolução ao agente, com o resultado do atendimento registrado. Caso a empresa adote uma regra por tempo, ela precisa considerar pendências, aviso à equipe e exceções do processo. Antes de ativar, teste se o bot volta sem contradizer o que a pessoa responsável acabou de orientar.