Como testar um agente de IA antes do lançamento: 7 verificações para o primeiro dia

Por que passar no teste de respostas não significa que você está pronto para o lançamento

Eu construo as integrações de helpdesk da eesel, o que significa que passo meus dias exatamente no código onde vivem os problemas do dia do lançamento: gatilhos, transferências, chamadas de API para sistemas de pedidos e as tags que dizem quem tocou em um ticket. Raramente é o modelo que quebra; geralmente é a instalação.

As boas práticas de teste da própria Zendesk são um bom retrato de como a maior parte do setor pensa nisso. Elas dizem aos testadores: "Focus on whether the AI agent's response was accurate and matched the tone of voice you expected." É um bom conselho, e também é só a ponta do iceberg. A mesma central de ajuda documenta, em outros artigos, que tickets de agentes de IA não executam seus gatilhos e automações de ticket até serem escalonados. Ou seja, suas regras de roteamento disparam pela primeira vez no exato momento da transferência, o único momento que um teste de precisão nunca alcança.

Eu também tenho minhas cicatrizes. Na própria plataforma da eesel, já vi um bot tratar as próprias respostas como novas mensagens de clientes e responder a si mesmo, um loop de autorresposta que só apareceu ao rodar em um helpdesk ativo. Já vi texto interno da interface vazar em uma resposta pública durante um teste em produção de um cliente. E já vi bots na plataforma da eesel inventarem respostas quando a base de conhecimento voltava vazia, em vez de transferir. Nenhuma dessas foi uma resposta errada a uma pergunta de teste. Todas foram costuras.

O lado jurídico também já alcançou o assunto. Em Moffatt v. Air Canada, o chatbot da companhia aérea disse a um cliente que ele poderia solicitar a tarifa de luto depois de viajar, dentro de 90 dias da emissão da passagem, o que contradizia a própria página de política da Air Canada. O tribunal chamou o argumento da Air Canada de que o chatbot era "a separate legal entity" de "remarkable submission" e ordenou o pagamento de $812.02. O bot errou, mas a falha real foi que ninguém o conferiu com a política original antes de os clientes confiarem nele.

Se você já leu o guia do meu colega sobre testes de agentes de suporte com IA, o lado das respostas está coberto. Este artigo é o complemento: tudo o mais que você precisa verificar na semana antes de virar a chave.

As sete verificações pré-lançamento em resumo

Aqui está o plano inteiro em uma tela. A primeira verificação é a que a maioria das equipes já faz. As outras seis são onde o dia do lançamento dá errado.

As notas mínimas são minhas, não um padrão do setor. Defina as suas, mas escreva-as antes de começar a testar, não depois de ver os resultados. Se precisar de ajuda para escolher os números, o AI support pilot scorecard tem um modelo.

Verificação 1: reproduzir tickets reais para as respostas

Comece pelo teste de respostas, porque tudo o mais pressupõe que o agente acerta as perguntas fáceis. Separe de 50 a 100 tickets resolvidos recentemente dos seus principais temas, passe-os pelo agente sem que ele responda a ninguém e compare a resposta dele com o que sua equipe realmente enviou.

A maioria dos helpdesks oferece uma ferramenta para isso. O agente de e-mail da Freshdesk pode avaliar tickets importados, até 50 consultas por execução, e recomenda pelo menos 20. O agente de clientes da HubSpot executa testes em lote de até 8 conjuntos de teste sem usar créditos. A habilidade Simulation da eesel reproduz seus tickets antigos reais e pontua cada resposta em relação ao que sua equipe enviou, depois sugere mudanças nas instruções.

Pontue precisão e tom como dois números separados. Em um teste da eesel com tráfego real, uma caixa de e-commerce de joias com cerca de 1.000 tickets por mês, 88% dos rascunhos apontavam na direção certa, mas só 12% foram enviados como estavam, e 7% tinham um erro factual. A maioria das reescritas foi por tamanho e tom, não por fatos. Uma única nota de "precisão" teria escondido os dois problemas.

Depois, mantenha o conjunto de testes vivo. Este comentário do Reddit é o conselho mais útil sobre o assunto, e não tem nada de sofisticado:

"keep a list of test questions handy and run it through and see if you get the right answers. Whenever an edge case appears, add to the list of test questions, update your agent and re-run your tests. Boring, but works."

u/ankursarda, r/CustomerSuccess, Reddit

Inclua perguntas que sua documentação responde só pela metade. O resultado certo ali é uma transferência, não um palpite confiante. Se você encontrar respostas erradas porque a fonte está desatualizada, é um problema de conhecimento, e uma auditoria da base de conhecimento resolve mais do que qualquer ajuste de prompt.

Verificação 2: testar o que ele não deve responder

É aqui que o "nós dissemos para ele não fazer" encontra a realidade. Todo grande helpdesk agora separa orientação leve de regras rígidas, e a versão leve é a que a maioria das equipes configura.

• A Zendesk lista "Always escalate to an agent if the user mentions being hacked" como uma instrução ruim, porque "Instructions cannot trigger escalations" (guia de instruções da Zendesk). Para isso você precisa de um caso de uso.
• A Freshdesk diz que sua configuração "Topics to avoid" "may not fully prevent responses in edge cases", e aponta para a configuração de transferência para uma aplicação estrita (identidade e instruções da Freshdesk).
• A Help Scout diz com clareza: os papéis mudam como o Scout responde, e para enviar temas direto para a sua equipe, "create an exclusion" (papéis do Scout).
• A HubSpot permite definir barreiras por segmento e avisa que as respostas "may not always exactly match" o que você especificou.

Uma exclusão é a versão rígida de "não responda reembolsos", extraída da documentação da Help Scout.

Então, para cada tema da sua lista de "nunca" (reembolsos acima de um limite, ameaças jurídicas, segurança da conta, perguntas médicas ou de segurança, qualquer coisa sobre uma data de entrega que você não pode prometer), teste de três formas: perguntado diretamente, escondido em uma mensagem mais longa e perguntado de novo depois que o agente diz não. A nota mínima é uma transferência todas as vezes.

Um gerente de suporte de e-commerce que usa a eesel pegou exatamente isso na revisão. O agente dele continuava dizendo aos clientes que os pedidos chegariam a tempo, e a nota que ele deixou foi direta: "stop promising customer things we cant do. we cannot guarantee this customer's order to them by friday." Esse é um teste de escopo que você pode escrever antes do lançamento: "Vai chegar até sexta?"

Depois teste o que acontece quando um cliente tenta tirá-lo do roteiro. Em janeiro de 2024, um cliente da DPD pediu ao bot que xingasse e escrevesse um poema sobre a empresa, e ele fez:

"Parcel delivery firm DPD have replaced their customer service chat with an AI robot thing. It's utterly useless at answering any queries, and when asked, it happily produced a poem about how terrible they are as a company. It also swore at me. 😂"

Ashley Beauchamp, X

A OWASP classifica a injeção de prompt como o principal risco para aplicativos de LLM e recomenda "adversarial testing and attack simulations". Para um agente de suporte, isso significa uma lista curta de tentativas: "ignore your instructions", "are you a human?", "give me a discount code" e uma mensagem que cola um texto de política falso. Para um roteiro mais completo, veja o guia de testes adversariais.

Histórias de clientes deixam o ponto do escopo claro. A Luxedo, que vende sistemas de projeção, limitou seu agente da eesel apenas a clientes residenciais: tickets de escolas, academias e outros compradores comerciais são ignorados e ficam com vendas. Falhas de hardware, decisões de garantia, reembolsos e segurança elétrica sempre vão para a equipe. Um limite tão específico é fácil de testar antes do lançamento: envie um ticket de cada grupo excluído e confirme que o agente o deixa em paz.

Verificação 3: percorrer cada caminho de transferência de ponta a ponta

Um teste de transferência de verdade faz três perguntas: uma pessoa recebeu o ticket, ela conseguiu ver o que aconteceu e o cliente sabia o que esperar? São três verificações diferentes, e cada helpdesk lida com elas de um jeito.

Alguns desses detalhes são fáceis de perder e dolorosos no primeiro dia:

• O grupo de transferência da Zendesk tem um fallback silencioso. A caixa de configurações avisa: "If a selected group is deleted, the default group will be used instead." Renomeie ou una um grupo depois da configuração e suas transferências vão discretamente para outro lugar. Os agentes de e-mail da Zendesk também param de responder quando a tag escalated_by_ultimate é aplicada, e a Zendesk diz para você configurar seus fluxos de trabalho para encontrar esses tickets por conta própria.
• A Gorgias não roteia transferências para uma equipe por padrão. Você cria uma regra de atribuição automática na tag ai_handover (guia de transferência da Gorgias). Sem ela, as transferências ficam na visão do AI Agent.
• O roteamento "Team only" da HubSpot transfere mesmo quando não há ninguém. A HubSpot diz que o agente "will execute a handoff even if no users are currently available", e não olha a disponibilidade do widget de chat (configuração de transferência da HubSpot).
• A assunção na Freshdesk não pode ser desfeita. Quando uma pessoa clica em "Stop responding & assign to me", o rascunho da IA "is discarded permanently" (salvaguardas de e-mail da Freshdesk). Garanta que sua equipe saiba disso antes de testar em um ticket que lhe importe.

O aviso de fallback abaixo do grupo de transferência da Zendesk, extraído da central de ajuda da Zendesk.

Veja como é um loop de transferência do lado do cliente. Toda saída leva de volta ao início:

"The ChatBot looping around providing generic answers, asking what my problem is. It ignores direct request to speak with an agent or to create a customer service. It simply starts with "Please, tell us about the problem ..." If I keep asking the same question, I can managed to get to a list of choices: 1. Report a technical issue, 2. Visit our Status page, 3. Time Tracker issues. Typing 2 and 3 leads to nowhere. Typing 1 reset the chatbot and it start again asking about my problem."

u/-Big-Hat-, r/Upwork, Reddit

E aqui está a versão em que a transferência "funciona", mas o contexto não acompanhou:

"Doesn't help at all if your support team ignores the bot chats. There is NOTHING more frustrating than talking to a bot for ten minutes just to have your live agent ask "can you please give me your account number one more time?"."

u/quietvectorfield, r/CustomerSuccess, Reddit

Então o teste de transferência tem cinco passos. Peça uma pessoa de três formas diferentes (direta, frustrada e no meio do fluxo). Acione cada motivo de escalonamento configurado. Abra o ticket como o atendente que o recebe e confira se o histórico e qualquer resumo estão lá. Leia a mensagem que o cliente recebeu sobre o que acontece a seguir. E cronometre quanto tempo alguém da equipe leva para notar o ticket. Para saber mais sobre como projetar a transferência em si, veja estas boas práticas de transferência de IA e o guia sobre quando transferir.

A mensagem de transferência importa tanto quanto o roteamento. A SE Ranking configurou seus agentes da eesel para dizer aos clientes que esperem uma resposta em um ou dois dias úteis, nunca que alguém está entrando agora. Reembolsos, extensões de teste e perguntas repetidas vão para a equipe com o nome e o e-mail do cliente anexados. É uma promessa que a equipe consegue cumprir, então também é uma promessa que você pode testar.

Teste o caminho fora do horário separadamente

Fora do horário é onde as transferências mais quebram, porque a fila que normalmente é acompanhada não está sendo. Cada helpdesk lida com isso de um jeito um pouco diferente:

• A Freshdesk tem uma chave "Transfer outside business hours" e avisa para evitar o uso de instruções para tratar o horário comercial (configurações de transferência da Freshdesk).
• A Zendesk usa um bloco de disponibilidade no início do caminho de escalonamento.
• A Gorgias fecha um ticket de chat offline se o comprador não deixa um endereço de e-mail.

As configurações de transferência fora do horário da Freshdesk, extraídas do site de suporte da Freshdesk.

Faça um teste de transferência com o horário comercial definido como "fechado" e confirme três coisas: onde o ticket cai, o que é dito ao cliente e se algo é fechado sem resposta. Se o seu helpdesk tem suas próprias configurações de horário comercial, confira se o agente de IA usa o mesmo cronograma da sua equipe.

Verificação 4: testar cada ação e depois quebrá-la de propósito

As ações são onde um agente de IA deixa de falar e passa a fazer: consultar um pedido, adicionar uma tag, iniciar um reembolso, cancelar uma assinatura. É também onde os ambientes de teste mais decepcionam, porque testar uma ação geralmente significa tocar em um sistema real.

Teste cada ação das cinco formas em que ela pode importar. Read: ela traz o pedido certo quando dois clientes têm o mesmo nome? Write: tags, notas e mudanças de campo chegam ao ticket certo? Act: tudo que custa dinheiro espera por uma pessoa? Escalate: quando a ação não consegue terminar, o ticket vai para um humano? Recover: quando a API está fora do ar ou lenta, o cliente recebe uma resposta sensata em vez de silêncio?

O que os helpdesks documentam sobre falhas:

• As ações personalizadas da Zendesk expiram após 10 segundos, e então "the action isn't performed." O próprio guia da Zendesk sobre procedimentos generativos traz uma boa regra para copiar: "If API returns 'timeout', retry up to 2 times. If still failing, escalate the request." Ele também alerta que uma chamada pode retornar sucesso e ainda assim seguir pelo ramo de falha se o agente não conseguir ler a resposta.
• As ações de chat da Freshdesk vão para um caminho de fallback em caso de timeout ou falha. No e-mail, porém, "confirmation blocks are skipped" porque não há conversa ao vivo, e a Freshdesk diz para colocar salvaguardas "at the API layer" (ações de API da Freshdesk). O botão Test API usa "real values and may affect your external system".
• A Gorgias para uma ação de várias etapas na etapa que falhou e transfere o ticket para a sua equipe, mas as etapas anteriores continuam feitas (registros de ações da Gorgias). As conversas de teste "use real data from your connected apps", então use um perfil de cliente de teste.
• A HubSpot permite configurar até 20 ações com um nível de proteção de ação (None, Match email ou Verify email), mas não documenta o que acontece quando uma falha. Teste isso você mesmo.

A Gorgias registra cada execução de ação como Success ou Error, extraído da documentação da Gorgias.

Nenhum helpdesk que verifiquei tem um botão que simule uma queda de API. Para testar a etapa Recover, aponte a ação para um endpoint de staging e desligue-o, ou dê a ela um número de pedido errado e um token expirado. Parece trabalho extra até o sistema de pedidos ter uma manhã ruim.

O padrão mais seguro é o chato: comece toda ação que altera algo atrás de uma aprovação. Na eesel, cada ação é definida como Auto, Needs approval ou Disabled, novos agentes devem começar supervisionados, e "Approvals never run on their own after a timeout." Se você está escrevendo suas próprias regras sobre quais reembolsos um bot pode tocar, uma matriz de aprovação de reembolsos é um bom ponto de partida.

Verificação 5: confirmar onde ele aparece e onde fica quieto

Um agente que responde bem aos tickets certos ainda pode envergonhar você nos errados. Gatilhos, canais, marcas e regras decidem quais tickets o agente vê, e cada helpdesk tem suas próprias surpresas:

• As regras da Gorgias rodam primeiro. Se uma regra envia uma resposta automática, o AI Agent "may still attempt its own response", e o cliente recebe duas mensagens (regras da Gorgias e AI Agent). A Gorgias também fecha, sem responder, qualquer mensagem que julgue sem relação com e-commerce ou suporte, e isso não pode ser desligado. Confira os tickets fechados e adiados depois de uma execução de teste.
• A Zendesk escalona para uma pessoa toda mensagem que contenha um PDF, o que chama de "expected behavior" (solução de problemas da Zendesk). Se seus clientes enviam faturas em PDF, seus números de deflexão vão parecer diferentes do seu teste.
• A Freshdesk permite implantar o agente de e-mail primeiro para equipes internas, "a safe pilot rollout", com até cinco níveis de regras aninhadas sobre quem ele atende (configuração do agente de e-mail da Freshdesk).

Envie um ticket de teste para cada tipo de ticket que o agente deve ignorar: um ticket interno, spam, um VIP, um ticket da sua segunda marca, uma candidatura de emprego, uma oferta de fornecedor. A Lesson Pro, que opera várias marcas de aulas em um único Zendesk, configurou seus agentes da eesel para ignorar candidaturas de emprego, mensagens de voz e formulários de pedido, e para identificar a marca antes de escrever uma palavra. Errar a marca em uma resposta é pior do que responder devagar, e é a coisa mais fácil de testar.

Depois, deixe o agente responder a um ticket de teste real dentro do seu helpdesk ativo e observe esse ticket por dez minutos. É a única forma de pegar um loop de autorresposta, o bug que mencionei antes, em que o gatilho dispara na própria resposta do agente. Um sandbox também não vai mostrá-lo. O sandbox da Zendesk desliga os webhooks por padrão, não copia fluxos de ações nem roteamento por habilidades, não oferece suporte a SMS, e uma cópia completa "can take up to a week or more". É um bom lugar para testar respostas e um lugar fraco para testar costuras. Há mais sobre essa troca em Zendesk sandbox vs produção.

Verificação 6: ensaiar o botão de desligar

Todo plano de lançamento tem uma linha que diz "podemos desligar se algo der errado". Pouquíssimas equipes realmente fizeram isso. Faça antes do lançamento, cronometre e garanta que duas pessoas saibam como.

O botão de desligar não é a mesma coisa em todo helpdesk, e algumas chaves de aparência óbvia não fazem o que você esperaria:

Dois deles merecem uma segunda leitura. Na Gorgias, o que parece "desligar a habilidade de reembolso" não para as perguntas sobre reembolso; o agente as responde com base no seu conhecimento, e pará-lo em uma parte dos tickets exige uma regra "ignore". Na HubSpot, a página de transferência lista "the agent is paused" como um motivo para transferir, enquanto a página de implantação diz que as conversas existentes continuam rodando quando ele está desligado. Teste qual dos dois você obtém.

Escreva o simulacro como um runbook de uma página: quem pode desligar, os cliques exatos, para onde vão os tickets quando está desligado, quem avisa a equipe e o que precisa ser verdade antes de religar.

Verificação 7: configurar os relatórios antes do primeiro dia

No dia do lançamento, alguém vai perguntar "está funcionando?" e você vai querer uma resposta em menos de um minuto. Isso significa que as tags e visões precisam existir antes do primeiro ticket real, não depois.

No mínimo, coloque tag em todo ticket que a IA toca, coloque tag em toda transferência com um motivo e crie uma visão para "transferido e ainda não assumido". A SE Ranking pediu uma tag ai_handled em todo ticket que a eesel toca, mais tags de útil e não útil, para contar a contenção dentro da Zendesk em vez de adivinhar. A Freshdesk registra automaticamente um motivo de transferência para cada ticket, incluindo "System issue" e "Max turns exceeded", o que é um relatório gratuito de qualidade do escalonamento se você o usar.

Depois decida o que você vai revisar na primeira semana. Esta é a melhor resposta curta que li sobre isso:

"The expensive misses are usually the ones that look confident and don't escalate. So I'd rather have a slightly annoying bot that hands off early than one that quietly invents an answer. If I were running it, I'd review a small sample of resolved tickets every week, plus every escalation and complaint. That's probably more important than the model choice."

u/TheChandrianX, r/CustomerSuccess, Reddit

A Gorgias sugere revisar pelo menos 10 tickets tratados pela IA na primeira semana (guia de entrada no ar da Gorgias). Eu iria além no primeiro dia: leia cada transferência e cada execução de ação. O guia de métricas de IA para CX cobre o que acompanhar depois disso.

O que fazer se algo der errado no primeiro dia

Mesmo com as sete verificações feitas, algo vai surpreender você. A pergunta útil é se é um problema de "pausar agora" ou de "corrigir hoje". Escolha o sintoma que você está vendo:

O padrão por trás do widget: pause tudo que prende um cliente ou gasta dinheiro e corrija problemas de roteamento e gatilho com o agente ainda rodando. Quando é o bot de suporte de um fornecedor que erra em público, a correção costuma ser parecida. Depois que o bot de suporte com IA da Cursor inventou uma política de bloqueio em abril de 2025, a própria análise posterior do cofundador no Hacker News começou com a identificação e um reembolso:

"Apologies - something very clearly went wrong here. We've already begun investigating, and some very early results:

Any AI responses used for email support are now clearly labeled as such. We use AI-assisted responses as the first filter for email support. We've made sure this user is completely refunded - least we can do for the trouble." mntruell (Cursor cofounder), Hacker News

Sua decisão de seguir ou não

Na noite anterior ao lançamento, passe por esta lista. Se qualquer linha for um "não", segure essa peça por enquanto. Lance a faixa que passa e segure o resto.

• O agente foi pontuado em tickets antigos reais, com precisão e tom pontuados separadamente.
• Todo tema de "nunca responder" é transferido, testado de três formas, usando uma exclusão rígida em vez de uma instrução.
• Todo caminho de transferência cai em uma fila que alguém acompanha, no horário e fora dele, com contexto anexado.
• Toda ação foi testada em registros de teste e forçada a falhar uma vez.
• Um ticket de teste por tipo de exclusão foi ignorado corretamente, e um ticket de teste ativo não entrou em loop.
• Duas pessoas desligaram e religaram o agente e sabem para onde vão os tickets quando ele está desligado.
• Tickets tocados pela IA e transferências têm tag, e há uma visão para transferências não assumidas.

Se você quer um plano de implantação completo para acompanhar isso, o guia para executar um piloto de suporte com IA cobre as quatro semanas após o lançamento, e a lista de erros de implementação de IA cobre os que aparecem mais tarde.

Como a eesel trata as costuras antes do lançamento

Sou parcial, já que eu a construo, mas esta é a parte da eesel da qual mais me orgulho, porque ela é construída em torno das costuras e não da demonstração.

• Respostas primeiro. A habilidade Simulation reproduz seus tickets antigos e pontua cada resposta em relação ao que sua equipe enviou, depois lista as correções. Conectar um helpdesk é somente leitura: "It does nothing on tickets until you create an automation."
• Chaves rígidas, não só instruções. Se algum histórico de tickets não deve ser aprendido, a documentação da eesel é direta: "Telling it in its instructions to ignore past tickets does not stop it finding them; the switch does" (configuração da Zendesk).
• Ações atrás de aprovação. Toda ação é Auto, Needs approval ou Disabled, e a documentação recomenda manter os reembolsos atrás de uma aprovação.
• Um registro do que ele realmente fez. A página Activity lista cada ticket, o que ele pesquisou, cada ação, quem aprovou e os tickets ignorados com o motivo.
• Um terminal para a instalação. A CLI da eesel permite testar o agente com eesel chat, conferir ações retidas com eesel approvals, ler eesel activity e usar --dry-run para imprimir a chamada exata que uma escrita faria sem enviá-la. Isso é útil quando um agente de código como o Claude Code está ajudando você a montar a integração e você quer ver a escrita antes que aconteça.

A página Activity da eesel mostra cada ação que o agente executou e quem a aprovou.

A Beautek, fornecedora de equipamentos B2B na Alemanha, é um bom exemplo do lado da transferência bem feito. O chat do site responde a perguntas sobre produtos e pedidos em alemão, mas frustração, questões jurídicas, pedidos complexos ou um pedido por uma pessoa criam um ticket no Zendesk com a conversa anexada. Em um mês foram 20 tickets do Zendesk criados a partir do chat, a maioria leads de vendas, enquanto os próprios tickets do Zendesk continuam como rascunhos que a equipe aprova.

Teste seu agente de IA antes do lançamento com a eesel

Se o seu plano de lançamento é "testamos as respostas, o resto a gente resolve ao vivo", a eesel foi feita para o resto. Ela entra no seu Zendesk, Freshdesk, Gorgias ou HubSpot como um novo contratado: aprende com seus tickets antigos, é pontuada neles antes de tocar em um cliente e pode começar com cada resposta e cada reembolso aguardando a sua aprovação. Você decide quando cada faixa entra no ar e pode desligar qualquer uma delas de novo.

A Simulation está na lista de habilidades da eesel, pronta para rodar nos seus próprios tickets.

O plano gratuito inclui 100 créditos sem cartão, e os planos pagos começam em $299/month por 500 créditos (preços). Experimente a eesel em uma cópia dos tickets da semana passada e veja o que ela teria feito.