O que aprendemos processando 676 mil mensagens de vendas no WhatsApp

Tem um contador no nosso banco de dados que passou de 676 mil mensagens processadas. Quando eu olho esse número, não penso em volume — penso em quantas dessas mensagens eram alguém decidindo se ia comprar ou não. Uma mensagem perdida não é um log de erro. É um cliente que perguntou o preço e nunca recebeu resposta.

O Autopilot não foi desenhado num whiteboard de startup. Ele nasceu dentro de uma operação real de vendas, com tráfego pago queimando dinheiro por hora e mais de 50 números de WhatsApp rodando ao mesmo tempo. Cada regra de engenharia que temos hoje existe porque a ausência dela custou dinheiro de verdade — nosso, não de cliente.

Este post é o resumo do que essas 676 mil mensagens e 62 mil contatos nos ensinaram. Nenhuma lição aqui é teórica. Todas têm uma fatura por trás.

Lição 1 — Mensagem recebida nunca morre em silêncio (a REGRA #1)

A primeira doutrina da casa, escrita em maiúsculas no código e na cabeça de quem mexe nele: mensagem recebida nunca é descartada em silêncio. Nunca. Se o processamento falhar, ela vai para fila. Se a fila falhar, tem retry. Se o retry esgotar, tem reconciliação depois — um processo que varre o que escapou e recupera.

Essa regra nasceu do jeito clássico: percebendo, tarde demais, que mensagens de clientes tinham evaporado durante instabilidades. Sem erro no painel, sem alerta, sem rastro. O cliente escreveu, o sistema engoliu, a venda morreu. Descarte silencioso é o pior tipo de bug porque ele não aparece em lugar nenhum — só no faturamento.

• Toda mensagem recebida entra em fila persistente antes de qualquer processamento.
• Falha de processamento gera retry automático, não descarte.
• Reconciliação periódica compara o que chegou com o que foi processado e caça a diferença.
• Perder mensagem é incidente grave, não estatística aceitável.

Lição 2 — Status-truth: o sistema nunca pode mentir para você

Segunda doutrina: nunca reportar sucesso sobre falha. Parece básico, mas a tentação de 'suavizar' status é enorme — marcar como enviado o que está pendente, esconder um erro transitório, deixar o painel verde para o usuário não se assustar. Toda vez que um sistema faz isso, ele quebra a única coisa que importa numa operação: a confiança de que o que você vê é o que aconteceu.

Se uma mensagem falhou, o status é falha. Se está pendente, é pendente. O operador toma decisão de dinheiro em cima desses status — refazer um envio, ligar para um cliente, pausar uma campanha. Painel que mente é pior que painel que não existe, porque te dá segurança falsa para errar com convicção.

Lição 3 — IA sem verificação custa dinheiro (nós pagamos para aprender)

Vou ser direto: a nossa IA já alucinou em conversa de venda e isso custou dinheiro real. Inventou condição que não existia, afirmou coisa que a base de dados não sustentava. O cliente cobrou, e quem paga a conta da alucinação é sempre a operação, nunca o modelo.

Foi depois desse prejuízo — e não antes, admito — que nasceram os guards determinísticos: uma camada de verificação contra dados reais que roda antes de qualquer mensagem gerada por IA sair do sistema. A IA propõe, o guard confere, e só passa o que bate com a realidade.

• Valores e condições citados pela IA são verificados contra a fonte de dados real, não contra a memória do modelo.
• O que não pode ser verificado não pode ser afirmado.
• O guard é código determinístico, não outra IA opinando sobre a primeira.

Lição 4 — Cada número é um paciente: circuit breaker e monitor de saúde

Com mais de 50 números simultâneos, você para de pensar em 'conexão' e começa a pensar em população. Números adoecem: instabilidade, restrição da Meta, queda de sessão. A pergunta deixa de ser 'se' e vira 'quando' — e o que importa é quanto tempo você demora para perceber e o quanto o problema se espalha.

Duas respostas de engenharia para isso. Primeira: circuit breaker por conexão — um número doente é isolado antes de contaminar a operação, sem derrubar os saudáveis. Segunda: monitor de saúde que verifica cada número junto à Meta a cada 10 minutos, com auto-pausa quando algo degrada e auto-retomada quando normaliza. O sistema percebe antes do cliente. Essa ordem não é detalhe; é a diferença entre incidente e vergonha.

Lição 5 — Aquecimento não é superstição, é rampa: 40/70/100

Número novo mandando volume total no primeiro dia é número pedindo para ser restringido. Aprendemos a tratar entrada de número como rampa controlada: 40% do volume na primeira fase, 70% na segunda, 100% só quando o histórico sustenta. É menos glamouroso do que 'conecta e dispara', e é exatamente por isso que funciona.

• Fase 1: 40% do volume-alvo, priorizando conversas de entrada e respostas.
• Fase 2: 70%, ampliando gradualmente o envio ativo.
• Fase 3: 100%, com o monitor de saúde vigiando a cada 10 minutos o tempo todo.

Lição 6 — O trabalho chato é o que salva: backup diário, retenção de 14 dias

Nenhuma dessas lições vale nada se um dia ruim apagar a base. Backup diário com retenção de 14 dias não é feature, é apólice. Sua base de contatos e histórico de conversas é, provavelmente, o ativo mais valioso da operação — mais que o site, mais que o criativo campeão. Tratamos como tal. A parte da engenharia que ninguém posta no LinkedIn é a que paga as contas.

“Escala não é conseguir mandar mais mensagem. É garantir que nenhuma delas se perca no caminho — nos dois sentidos.”

O que isso tem a ver com você

Tudo que descrevi — REGRA #1, status-truth, guards de IA, circuit breaker, monitor de saúde, aquecimento, backup — está dentro do Autopilot hoje, de série, porque foi assim que a nossa própria operação sobreviveu. Não vendemos essas ideias como diferenciais; para nós elas são o mínimo aceitável. Se a sua operação de WhatsApp ainda depende de sorte nesses seis pontos, você não tem um problema de ferramenta. Tem um risco de caixa esperando data de pico para se apresentar.