Um cliente pede para falar com uma pessoa. O bot diz que alguém está entrando na conversa, mas ninguém aparece. Para corrigir essa experiência, comece decidindo para onde vai o pedido e quem vai respondê-lo.
Este guia distingue uma transferência ao vivo de um ticket de suporte. Usa o comportamento atual de escalada do Agentkit para explicar os limites da configuração e apresenta uma política e verificações de aceitação que você pode adaptar à sua equipe. Os detalhes do produto foram verificados em 6 de outubro de 2026. Os exemplos são ilustrativos e não representam resultados de clientes.
Como devo definir gatilhos de transferência do bot para uma pessoa no suporte?
Defina gatilhos para pedidos explícitos de atendimento humano, respostas repetidamente inúteis e questões fora da autoridade do bot, e teste cada um antes do lançamento. O Agentkit pode criar um registro de suporte em seis sistemas externos de helpdesk ou CRM conectados, mas sua ação genérica Escalate to Human não conecta uma pessoa ao chat.
Escolha um destino, colete os dados de contato necessários e diga ao cliente o que acontece em seguida. A criação bem-sucedida de um ticket confirma que o pedido foi registrado. Não confirma que uma pessoa o leu nem que responderá dentro de um prazo específico.
Escolha a transferência que sua equipe consegue atender
Uma transferência ao vivo exige um canal com atendentes disponíveis e uma integração que permita a uma pessoa continuar a conversa. A transferência por ticket registra o pedido para acompanhamento posterior. O cliente precisa saber qual das duas está recebendo.
A ação genérica Escalate to Human do Agentkit oferece suporte a Zendesk, Freshdesk, Help Scout, Intercom, HubSpot e Salesforce. O destino recebe um ticket, caso ou conversa, conforme o provedor. Salesforce Live Chat é uma ação separada. Escolher Salesforce como destino da escalada genérica cria um caso, não uma sessão de chat ao vivo.
Agentkit Help Desk é outro destino, nativo. Exige uma conversa salva, um plano com acesso ao Help Desk e o Help Desk ativado para aquele agente. Também é necessário um e-mail válido do solicitante. Tickets de chat do site não têm um editor de respostas na caixa de entrada do Help Desk e não adicionam ao widget um canal de resposta humana ao vivo. Sua equipe precisa de outra rota de acompanhamento, como seu próprio e-mail de suporte, antes de ativar o fluxo.
Para um destino externo, conecte o provedor e confirme que seu plano permite a ação. Depois, adicione e ative a ação no agente. Verifique as permissões e a caixa de entrada da equipe responsável com um pedido de teste inofensivo.
Defina os gatilhos com base nas decisões do suporte
Comece com decisões que sua equipe consegue explicar. Não trate toda menção a "humano" ou toda frase negativa como o mesmo pedido.
| Gatilho | Exemplo | Política a testar |
|---|---|---|
| Pedido explícito | "Por favor, quero falar com uma pessoa." | Ofereça o caminho de suporte disponível e colete os dados de contato necessários. |
| Falhas repetidas | "Essa resposta ainda não resolve meu problema." | Pare de repetir a mesma orientação e ofereça escalada. |
| Fora da autoridade do bot | Uma cobrança contestada ou um pedido para alterar o acesso à conta | Encaminhe à equipe responsável em vez de inventar uma decisão ou confirmar uma alteração não autorizada. |
| Urgência ou frustração | "Minha conta está bloqueada e não consigo trabalhar." | Ofereça ajuda prontamente, descrevendo o canal real de acompanhamento. Não prometa atendimento de emergência sem uma equipe disponível para isso. |
| Regra de cliente verificada | Uma conta conhecida se qualifica para outra rota de suporte | Use dados confiáveis do cliente e uma rota configurada. Um visitante que se declara VIP não tem a identidade verificada. |
Essas são políticas recomendadas, não opções integradas que acionam gatilhos determinísticos. A ação do Agentkit tem instruções When to use que orientam o modelo. Instruções em linguagem natural precisam de testes com diferentes formulações e idiomas suportados. Por si só, não oferecem pontuação confiável de sentimento, consulta de status VIP ou um contador fixo de respostas rejeitadas.
A documentação de escalada da Intercom distingue orientações em linguagem natural, regras baseadas em dados e encaminhamento após a escalada. Essas distinções são úteis ao avaliar um fluxo, mas não significam que o Agentkit implemente o sistema de regras da Intercom.
Passe contexto útil para a pessoa
Para um provedor externo conectado, a escalada do Agentkit coleta um assunto, um resumo do problema, um e-mail válido e um nome quando disponível. O contexto do ticket inclui até as 50 mensagens salvas mais recentes que não sejam mensagens de ferramentas. Cada mensagem exibida tem um limite de 2.000 caracteres. O pedido atual é incluído quando disponível.
Esse contexto tem limites. Não é uma promessa de transcrição completa. O resumo tem um limite de 2.000 caracteres e o assunto, de 150 caracteres. A transcrição exibida contém o texto das mensagens, não arquivos anexados. O provedor de destino pode impor outros limites. Em um chat longo, pode ser necessário repetir um número de pedido antigo no resumo. Verifique o que o destino escolhido realmente exibe. O ticket nativo do Help Desk tem um link para a conversa salva. Não presuma que sua visualização seja idêntica ao corpo do ticket de um provedor externo.
Peça apenas o que a equipe precisa. Um e-mail digitado é um endereço para acompanhamento, não uma prova de que o cliente é dono de uma conta. Não peça que visitantes colem senhas, dados de cartões de pagamento ou credenciais privadas no chat.
Um resumo útil informa o que o cliente precisa, o que o bot já tentou e o que continua sem solução. Se sua equipe precisa de um motivo de escalada identificado ou de uma fila específica, configure e verifique esse fluxo. Não presuma que a ação genérica forneça isso automaticamente.
Estabeleça expectativas sem inventar disponibilidade
Em um fluxo de tickets, diga ao cliente que o suporte entrará em contato pelo canal combinado. Inclua um compromisso de prazo de resposta apenas quando a equipe responsável assumir esse compromisso e puder cumpri-lo. Não diga "um atendente está entrando" só porque um ticket foi criado.
Para pedidos fora do horário de atendimento, colete o e-mail obrigatório e o resumo do problema. Depois, informe o resultado real da criação. Se a conexão tiver expirado ou a criação do ticket falhar, forneça um caminho alternativo de contato que funcione. Uma mensagem tranquilizadora não substitui um registro de suporte ausente.
O anúncio da integração do Chatbase com Zendesk explicita a mesma distinção entre canais. Seu fluxo de tickets usa acompanhamento por e-mail. A integração Sunshine é um caminho separado de chat em tempo real. Verifique a integração real antes de prometer uma transferência ao vivo.
Uma instrução ilustrativa para adaptar
A política abaixo é um ponto de partida para um fluxo de tickets. Não é um classificador testado nem uma regra executável de encaminhamento. O modelo está em inglês.
Use the support-ticket action when the visitor clearly asks for a person, says the suggested answer did not help, or needs a decision outside your authority. Before calling it, collect or confirm a valid follow-up email and summarize the unresolved issue. Do not ask for passwords or payment-card details. After a successful result, explain that the request was recorded for follow-up. Do not claim a human has joined or promise a reply time unless the business has supplied a supported commitment. If creation fails, explain the problem and provide the business's alternative support contact. Do not say a ticket was created when the action failed.
Coloque as orientações dos gatilhos nas instruções When to use da ação. Mantenha as expectativas apresentadas ao cliente consistentes com suas instruções do agente. Teste o fluxo completo, incluindo a caixa de entrada de destino, em vez de verificar apenas as palavras do bot.
Verifique o fluxo antes do lançamento
Use pedidos fictícios e um endereço de suporte que você controla. Os casos abaixo são uma lista de aceitação, não resultados de testes realizados.
| Caso de teste | O que verificar |
|---|---|
| Pedido claro para falar com uma pessoa | A ação correta e ativada é oferecida ou chamada após a coleta dos dados obrigatórios. |
| Duas respostas sem sucesso | O bot oferece escalada em vez de repetir a mesma orientação. Esse limite é sua política de teste, não um contador integrado. |
| Nenhum e-mail conhecido na conversa ou no registro de contato | O bot pede um e-mail válido antes de tentar criar o registro. |
| Conversa longa | O registro de destino contém contexto recente útil, e detalhes anteriores importantes são preservados no resumo. |
| Provedor desconectado | O bot informa a falha e fornece o caminho alternativo de suporte configurado. |
| Help Desk desativado | O bot não afirma que um ticket nativo foi criado com sucesso. |
| Pedido fora do horário de atendimento | O bot descreve o acompanhamento corretamente, sem inventar uma fila ao vivo ou um prazo de resposta. |
| Pedido repetido de escalada | Verifique se o registro existente é reutilizado e se o cliente recebe um status correto. |
Registre o ID do registro de destino e verifique se uma equipe definida consegue encontrá-lo. Repita os casos de gatilho em cada idioma que você atende. Uma mensagem aparentemente correta no chat é apenas uma parte da aceitação.
Meça a criação e a resposta separadamente
Acompanhe tentativas de escalada, criação bem-sucedida de registros, falhas de entrega e tempo até a primeira resposta humana. Use os horários registrados pelo helpdesk de destino ou sua própria instrumentação para medir o tempo de resposta. Os logs de conversa do Agentkit, por si só, não oferecem um painel completo de tempo de transferência ou de satisfação após a transferência.
Revise uma amostra dos casos escalados em busca de contexto ausente e perguntas repetidas. Se fizer uma pesquisa de satisfação, mantenha o número de respostas e o canal junto da pontuação. O guia de KPIs de chatbot explica por que contenção e resolução precisam de definições separadas.
Comece com um destino suportado e uma equipe responsável pelo acompanhamento. Configure a ação de escalada, execute os casos de aceitação e confirme o recebimento antes de convidar clientes a usar o fluxo.
Leituras relacionadas:
