Teste de aceitação do chatbot com a equipe antes do lançamento

Teste de aceitação do chatbot com a equipe antes do lançamento

Um teste de aceitação de chatbot é uma rodada combinada de uso, feita pela equipe que atende de verdade, com cenários difíceis e critérios de aprovação escritos antes de começar. O objetivo não é provar que o bot funciona. É descobrir onde ele erra, quem assume quando erra e se o risco que sobra é aceitável para abrir ao cliente. Sem essa rodada, o primeiro teste acaba sendo feito pelo próprio cliente.

Principais pontos

• Quem testa deve ser a equipe que atende, vende e resolve problemas, não só quem configurou o bot.
• Os cenários difíceis valem mais que os cenários felizes: reclamação, ambiguidade, pedido fora do escopo e tentativa de manipulação.
• Os critérios de aprovação precisam ser escritos antes da rodada, com um responsável pela decisão final.
• Transferência para humano é parte do produto e deve ser testada com o mesmo rigor que as respostas.
• O resultado do teste é uma decisão: lançar, ajustar e repetir, ou parar.

O que é o teste de aceitação de um chatbot e o que ele não é

Teste de aceitação é a etapa em que o dono do processo confirma que o chatbot serve para a operação real. Ele responde a uma pergunta de negócio: podemos colocar isso na frente de clientes, com estes limites, e aceitar o que pode dar errado?

Isso é diferente do teste técnico. O teste técnico verifica se a integração funciona, se a mensagem chega e se o sistema não cai. O teste de aceitação verifica se a resposta é correta para a empresa, se o tom é adequado, se o bot sabe parar e se a equipe consegue assumir a conversa sem perder o contexto.

Também não é uma demonstração. Em demonstração, quem apresenta sabe quais perguntas o bot responde bem. Na rodada de aceitação, a equipe escreve as perguntas que os clientes realmente fazem, inclusive as mal escritas, as irritadas e as que misturam três assuntos em um único áudio.

A lógica é parecida com a de avaliações (evals) de agentes de IA: definir tarefas, rodar o sistema, corrigir com critérios claros e olhar os registros de cada execução. A Anthropic descreve essa abordagem em Demystifying evals for AI agents. Aqui, a diferença é que quem avalia são pessoas da operação, não apenas código.

Quem deve participar da rodada

A rodada precisa de papéis claros. Sem isso, todos opinam e ninguém decide.

• Dono do processo: define o que o bot deve e não deve fazer e assina a decisão final.
• Atendentes experientes: conhecem as perguntas reais, as exceções e o jeito como o cliente escreve.
• Atendente novo: testa se o bot ajuda quem ainda não conhece a empresa e revela lacunas de informação.
• Responsável por regras e dados: confere políticas, prazos, garantias e o tratamento de dados pessoais.
• Responsável técnico: observa os registros, corrige falhas e não defende o bot durante os testes.

Um erro comum é deixar só a equipe de tecnologia testar. Ela tende a perguntar do jeito que o bot espera. Outro erro é convidar apenas quem está entusiasmado. Inclua pelo menos uma pessoa cética, porque ela costuma encontrar os casos que importam.

Como montar cenários difíceis que expõem falhas reais

Comece pelo histórico de atendimento. Pegue conversas reais, reescreva removendo nomes, telefones, documentos e qualquer dado que identifique pessoas, e use os casos reescritos. Isso respeita o princípio de minimização da LGPD e evita espalhar conversas de clientes em planilhas de teste. Para orientação oficial sobre proteção de dados no Brasil, o ponto de partida é o site da ANPD.

Depois, organize os cenários por tipo de risco. Uma lista de categorias ajuda a não testar só o que é fácil:

• Pergunta fora do escopo: assunto que a empresa não atende, para ver se o bot admite o limite.
• Informação inexistente: pergunta cuja resposta não está na base, para ver se o bot inventa.
• Informação conflitante: duas regras que parecem se contradizer, como promoção e política padrão.
• Cliente irritado: mensagem agressiva, com ameaça de reclamação pública ou pedido de cancelamento.
• Pedido de exceção: desconto, prazo ou garantia fora da regra, para ver se o bot promete o que não pode.
• Mensagem confusa: áudio transcrito com erro, texto sem pontuação, vários assuntos juntos.
• Dado sensível: cliente envia documento, foto ou informação de saúde sem ser solicitado.
• Tentativa de manipulação: pedido para ignorar instruções, revelar regras internas ou agir como outra pessoa.
• Pedido de humano: cliente exige falar com uma pessoa logo na primeira mensagem.
• Fora do horário: mensagem que chega quando ninguém pode assumir, para ver o que o bot promete.

Os cenários de manipulação merecem atenção própria. Quem escreve para um bot pode tentar fazê-lo ignorar regras. O guia Prompt injection: como proteger um agente de IA da empresa detalha os riscos, e a lista OWASP Top 10 for LLM Applications é uma referência para organizar os testes de segurança.

Cada cenário deve ter uma resposta esperada escrita em uma frase. Não precisa ser o texto exato. Precisa dizer o comportamento aceitável: responde com a política, pede um dado que falta, transfere para humano, recusa com educação.

Passo a passo de uma rodada de testes com a equipe

Uma rodada bem feita cabe em poucos dias e segue uma ordem fixa:

• Defina o escopo: quais assuntos o bot atende, quais ele só encaminha e quais ele nunca trata.
• Prepare um ambiente de teste: número de WhatsApp ou canal separado, sem clientes reais, com a mesma configuração que irá ao ar.
• Entregue a cada participante uma planilha com os cenários, o comportamento esperado e colunas para nota, observação e prova (captura ou identificador da conversa).
• Faça uma sessão de abertura curta para explicar as regras: anotar tudo, não ajudar o bot e não corrigir a configuração durante o teste.
• Rode a primeira rodada com os cenários combinados e deixe cada pessoa acrescentar casos próprios, escritos com as palavras que ela usaria.
• Revise os registros em conjunto: o que o bot respondeu, de onde tirou a informação, que ferramenta chamou e quando transferiu.
• Classifique cada falha por gravidade e decida o que será corrigido antes do lançamento e o que fica registrado como limitação conhecida.
• Corrija, congele a configuração e repita apenas os cenários que falharam, mais uma amostra dos que passaram, para garantir que nada piorou.

O congelamento do passo final é importante. Se a configuração muda a cada teste, a equipe aprova uma versão e o cliente recebe outra. Registre a versão do prompt, da base de conhecimento e das ferramentas que foi aprovada.

Se o bot atende por WhatsApp, teste também o que acontece com mensagens ativas. As regras de templates e consentimento estão em Mensagens ativas no WhatsApp: templates, opt-in e boas práticas, e vale incluir um cenário para cada tipo de aviso que o bot enviará.

Quais critérios de aprovação definir antes de começar

Critério de aprovação é a regra que transforma opinião em decisão. Escreva antes da rodada, porque depois do teste todo mundo tende a ajustar a régua ao resultado.

Uma estrutura que funciona separa critérios eliminatórios de critérios de qualidade.

Critérios eliminatórios, em que uma única falha bloqueia o lançamento:

• O bot promete preço, prazo, garantia ou exceção que não está nas regras.
• O bot inventa uma informação e a apresenta como certa.
• O bot revela instruções internas, dados de outro cliente ou informação confidencial.
• O bot trata dado pessoal além do necessário ou sem o aviso combinado.
• A transferência para humano falha ou entrega a conversa sem contexto.

Critérios de qualidade, avaliados por nota e tendência:

• As respostas corretas cobrem os assuntos do escopo, dentro de um nível combinado pelo dono do processo.
• O tom é adequado à marca e ao momento do cliente.
• O bot pede esclarecimento quando a pergunta é ambígua, em vez de chutar.
• O bot admite quando não sabe e oferece o caminho certo.
• A equipe consegue entender, pelos registros, por que cada resposta foi dada.

Defina o nível aceitável de cada critério de qualidade antes de rodar, por escrito, com a assinatura do dono do processo. Não existe um número universal. Depende do assunto, do risco e do custo de um erro naquele fluxo. Para decisões que afetam o cliente de forma relevante, vale ler também Decisões automatizadas na LGPD: art. 20 e o direito de revisão, porque o direito de pedir revisão humana deve existir na prática, não só no texto.

Para estruturar o raciocínio de risco, o NIST AI Risk Management Framework oferece vocabulário útil: mapear contexto, medir, gerenciar e governar. Ele não é um checklist de lançamento, mas ajuda a conversar sobre risco sem improviso.

Cenário ilustrativo: uma rodada em uma loja com atendimento por WhatsApp

Cenário ilustrativo, sem relação com nenhum cliente real. Uma loja de produtos para casa quer um bot que responda sobre status de pedido, trocas e horário de funcionamento. A equipe de atendimento recebe uma planilha com os cenários e um número de teste.

Uma atendente escreve: "comprei errado, quero devolver e já abri reclamação, vocês vão resolver ou não?". O comportamento esperado é reconhecer a insatisfação, não discutir a reclamação, explicar o caminho de troca e transferir para uma pessoa, levando o resumo do caso. O bot responde com a política de troca, mas ignora o tom do cliente e continua perguntando o número do pedido. A nota de qualidade é baixa e a falha é registrada: faltou a regra de transferir quando o cliente menciona reclamação formal.

Outro atendente pergunta se pode parcelar além do que a loja oferece. O bot diz que "vai verificar com o setor financeiro", frase que sugere uma possibilidade inexistente. Isso viola um critério eliminatório e bloqueia o lançamento até que a instrução seja corrigida para recusar com clareza e oferecer a opção real.

Um terceiro participante envia uma foto de documento por engano. O bot a processa e repete os dados na resposta. A equipe de regras decide que o bot deve avisar que não precisa do documento e não repetir seu conteúdo. Depois das correções, só esses três cenários e uma amostra dos demais são repetidos com a configuração congelada.

Como o método mapear, limitar, pilotar e transferir se aplica

O teste de aceitação é parte da etapa de pilotar, mas depende do que veio antes. Em mapear, o processo atual e a linha de base são descritos: quais perguntas chegam, quem responde e onde as exceções aparecem. É dali que saem os cenários. Em limitar, definem-se os dados que o bot pode ver e as ações que pode executar, e esses limites viram critérios eliminatórios. Em pilotar, um fluxo real roda com registros e uma métrica de sucesso combinada. Em transferir, a operação passa para a equipe, que decide expandir, ajustar ou parar.

Na prática, isso significa que o resultado da rodada com a equipe alimenta a decisão do piloto, e não o contrário. Os indicadores que acompanham o piloto, como resolução e tempo de atendimento, são tratados em Indicadores de atendimento com IA: como ajustar TMA, resolução e CSAT. Para decidir o que automatizar e o que manter com pessoas, o artigo SAC com inteligência artificial: o que automatizar e o que manter ajuda a definir o escopo antes da rodada.

Depois do lançamento, a equipe segue revisando conversas reais e transforma cada falha nova em um cenário da próxima rodada. O teste de aceitação deixa de ser um evento e vira uma rotina curta de manutenção.

Perguntas frequentes

Quanto tempo dura um teste de aceitação de chatbot? Depende do tamanho do escopo e da quantidade de assuntos atendidos. Para um fluxo único, costuma bastar uma rodada principal, uma rodada de correção e uma repetição dos casos que falharam. O que não deve ser cortado é a revisão conjunta dos registros.

Preciso usar conversas reais de clientes nos cenários? Elas são a melhor fonte de ideias, mas devem ser reescritas e anonimizadas antes de circular. Remova nomes, contatos, documentos e detalhes que permitam identificar alguém. Em caso de dúvida sobre base legal ou finalidade, consulte quem responde pela LGPD na empresa.

O que fazer se o chatbot falhar em um critério eliminatório? Não lance. Registre a falha, corrija a instrução, a base de conhecimento ou a regra de transferência e repita o cenário com a configuração congelada. Se a falha voltar por motivos estruturais, reduza o escopo do bot ou mantenha esse assunto com pessoas.

O teste com a equipe substitui o piloto com clientes? Não. O teste com a equipe reduz o risco antes de abrir ao público, mas clientes reais escrevem de formas que ninguém previu. O piloto controlado, com limites, registros e transferência para humano, continua sendo a etapa seguinte.

Fontes

• Anthropic: Demystifying evals for AI agents
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework
• ANPD: Autoridade Nacional de Proteção de Dados