Antes de colocar um agente para atender clientes, teste o que ele deve fazer e o que precisa recusar ou encaminhar. Uma conversa que terminou bem não demonstra que o fluxo aguenta perguntas diferentes, falhas de serviço e mensagens repetidas.
Escreva o esperado antes de testar
Crie uma tabela com entrada, comportamento esperado, comportamento observado e resultado. Use dados fictícios. Defina critérios claros: por exemplo, não confirmar preço sem consulta válida e não executar uma ação que exige aprovação.
Separe o teste de linguagem do teste de operação. O texto pode parecer adequado enquanto a consulta usa o cliente errado. Também pode haver resposta gerada sem entrega no canal. Confira as etapas, além da mensagem visível.
Três ciclos úteis
Primeiro, uma conversa normal: apresentação, dúvida, explicação e próximo passo. Veja se o agente mantém o assunto e pede somente os dados necessários.
Depois, objeções: desconto não aprovado, condição antiga, pedido fora do escopo e perguntas repetidas. O agente deve explicar limites com clareza, sem inventar benefício para encerrar a conversa.
Por fim, falhas e limites: API indisponível, resultado vazio, cliente que pede informações de outra pessoa e mensagem tentando alterar as regras. Uma tentativa de manipulação não deve ganhar permissão administrativa porque está escrita em tom convincente.
Casos mínimos para sua tabela
- Pergunta comum com resposta aprovada.
- Informação que não existe na base.
- Serviço de consulta fora do ar.
- Solicitação de desconto sem autorização.
- Pedido para falar com a equipe.
- Mensagem duplicada recebida duas vezes.
- Resposta lenta enquanto uma pessoa assume a conversa.
- Pedido de dados de outro cliente.
- Tentativa de revelar configuração ou executar ação fora do escopo.
- Retorno após uma atualização das regras da empresa.
Como julgar uma falha
Classifique a causa: informação incorreta, consulta errada, permissão excessiva, estado da conversa ou entrega no canal. Ajuste uma causa por vez e repita o conjunto anterior. Se só repetir a pergunta que falhou, você pode corrigir um caso e prejudicar os demais.
Não use apenas uma segunda IA como avaliadora. Regras objetivas, conferência humana e registros da execução complementam a análise. A documentação do n8n descreve avaliações com conjuntos de casos; a ferramenta apoia o processo, mas a qualidade depende do conjunto escolhido.
Libere aos poucos e mantenha saída de emergência
Comece com escopo e volume limitados, responsável pelos avisos e caminho de atendimento conhecido. Registre como pausar, quem corrige e quando repetir os testes. Retenção de logs deve respeitar a necessidade do serviço, sem acumular dados privados indefinidamente.
Este roteiro não é um certificado de segurança nem uma garantia de falha zero. É uma forma prática de encontrar problemas antes que atinjam clientes. Use-o com a equipe e descreva sua integração na página de sistemas do Bora se precisar adaptar o fluxo.
Sobre esta orientação
Conteúdo preparado com apoio de IA e revisão editorial. Os exemplos são fictícios e não representam resultados obtidos por clientes. Consulte as fontes e valide o processo no seu ambiente antes de colocá-lo em operação.