Uma resposta educada no WhatsApp não garante um cadastro correto. Este roteiro ajuda pequenas empresas a testar o que acontece entre a conversa e a gravação no sistema.
Imagine uma situação fictícia: uma cliente pede informações pelo WhatsApp, o agente de IA entende a solicitação e responde sem tropeços. Minutos depois, a equipe descobre que a conversa foi associada ao cadastro de outra pessoa. O texto estava certo; a ação no CRM, não.
É uma diferença decisiva. Interpretar uma mensagem, localizar um registro e ter autorização para alterá-lo são tarefas separadas. Antes de conectar o agente à opção "criar ou atualizar contato", vale submetê-lo a cinco testes com dados sintéticos, sem usar conversas reais de clientes.
1. O nome parece igual. É o mesmo cadastro?
Peça ao fluxo que processe duas grafias visualmente equivalentes: João e Joa\u0303o (a segunda usa um acento combinante). A normalização Unicode NFC pode colocá-las na mesma representação textual, conforme o padrão do Unicode Consortium. Isso ajuda a comparar texto; não comprova que os cadastros pertencem à mesma pessoa.
O cuidado vale também para nomes decorativos. Uma pessoa pode copiar caracteres estilizados de um gerador de fontes, como o Letras Diferentes, para um perfil e depois usá-los numa mensagem. O NFC não converte essas letras; a forma NFKC converte muitas delas em caracteres comuns:
console.log("𝐉𝐨𝐚𝐨".normalize("NFKC")); // "Joao"Use esse resultado só como chave de comparação para encontrar possíveis duplicados, nunca para sobrescrever o nome exibido. Não mescle contatos apenas porque o resultado parece semelhante: guarde a forma original e trate a correspondência cadastral como decisão distinta.
2. O número está bem formatado. Mas de quem é?
Digite o mesmo telefone fictício com parênteses, espaços e prefixo internacional. Confirme se a integração consegue representar o número de maneira consistente segundo a recomendação E.164 da UIT, respeitando as regras do país. Normalizar formato não é verificar se o número existe, se continua com a mesma pessoa ou se ela tem direito de acessar um cadastro.
O WhatsApp pode ser um canal de contato válido, mas números podem ser compartilhados ou mudar de titular. Uma correspondência pelo telefone, isoladamente, não deve liberar alteração de endereço, pedidos ou outros dados associados a uma identidade não confirmada.
3. O cliente colou um texto com caracteres invisíveis
Copie Ana Silva com um espaço não separável (U+00A0) ou insira U+200B, um espaço de largura zero, dentro de um nome. A aparência pode enganar quem revisa o atendimento. NFC não é uma função genérica para apagar espaços invisíveis: o NFKC troca o U+00A0 por um espaço comum, mas mantém o U+200B. A equipe precisa decidir como cada campo será tratado.
Um teste simples em JavaScript ajuda a visualizar a diferença sem depender de um CRM:
const a = "Joa\u0303o";
console.log(a.normalize("NFC") === "João"); // true
console.log("Ana\u200BSilva".includes("\u200B")); // true4. O agente disse "confirmado", mas o cliente confirmou?
Provoque uma ambiguidade: "Pode atualizar o cadastro da Marina?" Se o CRM localizar duas Marinas, o agente não deve escolher uma por conta própria. Em vez disso, apresente os dados mínimos necessários e peça uma confirmação explícita da alteração pretendida, seguindo o processo de identificação autorizado pela empresa.
Na arquitetura, a resposta do modelo deve gerar uma proposta de ação, não uma ordem irrevogável. O backend verifica campos obrigatórios, permissões, vínculo com o registro e estado da confirmação antes de gravar. Essa separação responde ao risco de autonomia excessiva descrito pelo OWASP para aplicações com IA.
5. Quando a dúvida persiste, o humano realmente assume?
Simule duas correspondências plausíveis, uma tentativa repetida de corrigir o nome e uma pergunta que exija consulta a dados restritos. O fluxo deve interromper a alteração automática, indicar claramente que haverá atendimento humano e registrar uma pendência acompanhável pela equipe. Não basta o robô prometer "vou transferir" se nenhum atendente receber o caso.
O repasse deve conter o necessário: motivo da dúvida, ID interno da conversa, campos que precisam ser confirmados e ações não executadas. Evite despejar todo o histórico e dados pessoais em notificações abertas. Os princípios de necessidade, qualidade dos dados e segurança estão no art. 6º da LGPD (Lei nº 13.709/2018).
Matriz de QA: execute antes de liberar a integração
| Entrada de teste | Resultado esperado | Verificação |
|---|---|---|
| Duas versões Unicode de "João" | Chave textual coerente; sem mesclagem por nome | Comparação e identificação |
| Mesmo número com formatações distintas | Número padronizado; titularidade não presumida | Telefone e permissões |
| Nome com U+200B ou U+00A0 | Entrada sinalizada segundo a política do campo | Sanitização e auditoria |
| Dois registros chamados Marina | Solicitação de identificação; nenhuma gravação antecipada | Autorização e escrita |
| Falha ou incerteza após a transferência | Fila humana registrada; atendimento sem alteração indevida | Handoff e monitoramento |
Faça ainda um teste de evento repetido: reenvie a mesma mensagem ou webhook com o mesmo identificador de evento. O sistema não deve criar outro contato apenas porque recebeu a entrega novamente. Isso exige idempotência na integração, não uma instrução simpática no prompt.
Antes de ativar: três decisões de gestão
Defina quem pode atualizar quais campos, em que situação a confirmação será exigida e como erros poderão ser corrigidos. Depois, execute os testes em ambiente de homologação, com dados inventados e sem permissão para modificar cadastros reais. Registre o resultado de cada cenário e a pessoa responsável pelo aceite.
🖊️ Em resumo
Se a equipe não consegue explicar o que ocorre quando há dois clientes parecidos ou quando a transferência falha, o agente ainda não está pronto para escrever no CRM. Uma resposta convincente melhora a conversa; só uma integração verificável protege o cadastro.
📖 Leia também