O teste que decide se uma automação de atendimento está pronta para um caso real

A condição que nunca foi verdadeira

Um atendente automático de mensagens tinha uma tarefa simples: reconhecer de qual anúncio a pessoa tinha vindo e citar o assunto já na saudação. Testei uma vez, funcionou, segui para o próximo cliente.
A condição que checava isso nunca foi verdadeira. Nenhuma vez. Todo contato que chegava de anúncio recebeu a mesma saudação genérica, desde o primeiro dia, e nenhum erro apareceu em lugar nenhum. O painel mostrava mensagens entregues, zero falha registrada. A automação simplesmente fazia menos do que prometia, em silêncio, até alguém ler o histórico inteiro e notar o padrão.
Funcionalidade que falha em silêncio parece funcionar para sempre. O que não quebra, ninguém volta a olhar.

A régua que separa o que pode automatizar do que não pode

Em qualquer atendimento que mistura agendamento com dúvida de quem está do outro lado, existe uma linha que vale a pena desenhar antes de ligar qualquer automação.
De um lado fica o que é regra fixa: marcar horário, confirmar presença, lembrar da consulta, repetir endereço e forma de pagamento. O resultado certo já existe antes da pergunta chegar, é só comparar uma data contra uma agenda ou repetir uma informação que não muda de pessoa para pessoa. Isso pode sair da sua mesa com segurança, porque o julgamento já foi feito uma vez, no momento de escrever a regra.
Do outro lado fica tudo que exige julgar o caso na hora: responder dúvida sobre sintoma, decidir o tom de uma resposta a alguém ansioso, confirmar se um horário específico serve para um caso específico. Aqui o risco de errar não é atrasar uma resposta, é entregar algo errado com aparência de certeza, e isso pesa mais quando o dado em jogo é sensível.
Uma revisão publicada em 2022 na npj Digital Medicine avaliou dez estudos sobre ferramentas digitais de triagem de sintoma, e encontrou acurácia diagnóstica entre 19% e 37,9%. Até a parte mais objetiva dessas ferramentas, decidir se o caso espera ou corre, varia tanto de ferramenta para ferramenta que chega a errar em quase metade dos casos nas piores delas.

Por que uma execução certa não prova nada

Um teste separado, numa automação de cadastro e renovação de cliente, rodou oito registros idênticos em sequência. O primeiro terminou sem erro. Os sete seguintes falharam todos pelo mesmo motivo, uma condição que dependia do estado deixado pela execução anterior e que ninguém tinha previsto. De oito tentativas iguais, só uma em oito saiu certa.
O critério de "pronto" que valia até esse teste era simples: rodar uma vez e ver se funciona. Funcionou, uma vez. O problema só apareceu na repetição. A correção não foi apenas no código, foi no critério: "pronto" passou a exigir repetir a mesma ação várias vezes seguidas, em sequência, antes de confiar numa situação real.
A mesma lógica vale para um lembrete de consulta. Funcionar na primeira vez não prova que vai funcionar na vigésima, na que cai em feriado, na que a pessoa reagenda duas vezes. Prova só que funcionou naquela vez específica, com aquele conjunto específico de condições.

Como testar sem usar uma pessoa real como primeira tentativa

Dois critérios resolvem a maior parte do risco de um teste que vaza para fora do ambiente de teste.
O primeiro: qualquer teste que possa, por engano, chegar a um contato real usa um nome obviamente falso. Um aviso no meio da mensagem não protege ninguém, porque às vezes o que aparece numa tela de celular é só o nome, sem o resto do texto. "Maria da Silva" não desperta suspeita. Um nome que claramente não existe se denuncia antes de causar dano.
O segundo, mais caro quando falha: o número ou endereço de quem vai receber a mensagem se confere antes de transmitir qualquer dado, nunca depois. Um dígito errado no número de WhatsApp manda a confirmação de uma consulta, ou o resultado de um exame, para um estranho.
Quando o dado envolvido é de saúde, o risco muda de categoria. A Lei Geral de Proteção de Dados trata "dado referente à saúde" como dado pessoal sensível, no mesmo grupo de origem racial e convicção religiosa, e exige medidas técnicas e administrativas capazes de evitar que esse tipo de informação chegue a quem não devia.

O limite que continua sendo seu depois que a automação funciona

Depois que a parte fácil está automatizada e testada, existe uma tentação de deixar a mesma ferramenta responder também a mensagem mais longa, a dúvida mais específica. Tecnicamente costuma ser simples de configurar. A razão para recusar não é técnica.
Quem responde pelo atendimento continua sendo quem tem a formação para isso, não uma ferramenta configurada para parecer que entende o caso. O máximo que uma automação deveria fazer, nesse território, é preparar um rascunho para revisão, nunca enviar sozinha algo que carrega o peso de um julgamento profissional.
Isso também não termina no dia em que a automação entra no ar. Preço reajustado, horário alterado, um serviço que parou de existir: cada mudança que não chega até a automação se transforma numa resposta errada, repetida até alguém perceber. O problema nunca é a automação ter sido mal configurada. É ninguém ter sido designado para atualizá-la depois.

Quem atende sozinho sente esse gargalo direto: a atualização depende de lembrar, e é a mesma cabeça que decide todo o resto. Quem divide a operação com sócio ou secretária troca esse risco por outro, o de duas pessoas editando a mesma mensagem automática em direções diferentes, sem avisar uma à outra, até alguém de fora receber uma informação de um canal e outra de outro. Nos dois casos a solução não é mais ferramenta. É decidir, antes de qualquer mudança de preço ou horário entrar no ar, quem tem a palavra final sobre o texto que a automação envia.

Este artigo é uma versão condensada de uma análise mais profunda que publiquei em https://chipak.com.br/artigos/o-que-automatizar-no-atendimento-e-o-que-fica-com-voce