No post anterior, a ponte da Caetano’s funcionou: o cliente enviou `ENCOMENDA` no WhatsApp, a Evolution API chamou o n8n e a planilha ganhou uma solicitação.
Em demonstração, isso parece vitória.
Em produção, é só o começo do problema.
Porque automação não quebra no slide. Quebra na segunda execução, no token expirado, no cliente que aperta duas vezes, na planilha com permissão errada e no fluxo que “funcionou ontem”.
Hoje vamos falar do que a demo esconde.
## O mito do “já está automatizado”
Uma execução verde no n8n não prova operação.
Prova que, naquele minuto, com aquele payload, com aquela credencial válida, o caminho feliz existia.
O mundo real manda o mesmo evento duas vezes. Manda evento sem e-mail. Manda e-mail repetido. Manda timeout. Manda API fora. Manda alguém editando a planilha no meio do expediente.
Se a sua definição de pronto é “rodou uma vez”, você não tem automação. Tem protótipo com cara de processo.
## 1. Duplicidade: a encomenda que nasceu gêmea
O cliente envia `ENCOMENDA`. A conexão oscila. A Evolution API reenvia o evento. O webhook processa duas vezes.
Resultado clássico: duas linhas iguais na planilha. Ou pior — dois avisos para a equipe e duas respostas automáticas para o cliente.
A pergunta correta não é “como evito 100% das duplicatas?”. É: **o que acontece se o mesmo evento chegar de novo?**
Se a resposta for “cria outro registro e vida que segue”, a operação vai pagar essa conta em silêncio.
## 2. Idempotência: a palavra feia que salva o fim de semana
Idempotência é o princípio simples: processar o mesmo pedido mais de uma vez não deveria bagunçar o resultado.
Na prática:
- use o ID da mensagem recebido da Evolution API como chave de idempotência
- prefira “atualizar se existir / criar se não existir” em vez de só append cego
- registre se aquele evento já foi processado antes de executar a ação cara (criar oportunidade, disparar e-mail, cobrar)
Não é elegância de engenharia. É higiene.
Sem isso, cada retry vira risco de negócio.
## 3. Loops: a automação que alimenta a si mesma
Cenário comum:
1. o cliente envia uma mensagem
2. o n8n responde pelo WhatsApp
3. a Evolution API envia a resposta ao mesmo webhook
4. o fluxo trata a própria resposta como nova mensagem
5. responde novamente
Ou: o fluxo falha, tenta de novo, falha, tenta de novo — e cada tentativa gera efeito colateral.
Loop ruim não parece bug no primeiro minuto. Parece “sistema trabalhando”. Até a conta de API subir, a planilha lotar ou o Slack virar sirene.
Toda automação precisa de uma pergunta cruel: **este fluxo pode se retrigger sozinho?** No WhatsApp da Caetano’s, o primeiro freio é ignorar `fromMe = true`.
## 4. Credenciais: o vilão silencioso
O token do Google expira.
A API key da Evolution API é rotacionada.
O usuário que autorizou a planilha sai da empresa.
O ambiente de teste usa uma credencial; o de produção, outra — e ninguém documentou.
A automação não “fica um pouco pior”. Ela morre no meio do caminho, muitas vezes sem avisar o time de negócio.
Sintoma típico: o WhatsApp continua recebendo mensagens. O cliente recebe “solicitação registrada”. Por baixo, nenhuma linha foi criada.
Isso é pior do que falha visível. É falha educada.
## 5. Falhas externas: o mundo não te deve uptime
Planilha fora.
Evolution API desconectada do WhatsApp.
Webhook com DNS errado.
Timeout de 15 segundos no meio do pico.
Sua automação depende de sistemas que você não controla. Então ela precisa de comportamento para quando o destino falhar:
- mensagem honesta para o usuário quando a conversa depende da resposta
- alerta para o time (e-mail, Slack, ticket)
- fila ou retry com limite — não retry infinito
- registro do payload que falhou, para reprocessar depois
“Tenta de novo depois” sem limite não é resiliência. É esperança com CPU.
## 6. Retries sem critério
Retry é bom. Retry burro é caro.
Regras mínimas:
- retry em erro temporário (timeout, 429, 503)
- não retry cego em erro de validação (e-mail inválido, campo obrigatório faltando)
- backoff: esperar um pouco mais a cada tentativa
- teto de tentativas
- dead letter: depois do teto, isola o caso e avisa humano
Sem isso, você transforma um problema pontual em tempestade de requisições.
## 7. Ausência de logs: operar no escuro
Se você não consegue responder “o que aconteceu com a encomenda enviada por este número às 14h22?”, você não opera automação. Você torce.
Log útil não é dump infinito. É trilha:
- quando entrou
- com qual chave / e-mail
- qual decisão tomou (criou / atualizou / ignorou)
- se falhou, com qual erro
- se reprocessou, quantas vezes
Sem log, cada incidente vira arqueologia. Com log, vira manutenção.
## O checklist antes de chamar de “produção”
Antes de comemorar a ponte WhatsApp → Evolution API → n8n → planilha, responda:
1. O que acontece se o mesmo evento chegar duas vezes?
2. O que o cliente vê se o destino estiver fora?
3. Quem é avisado quando a credencial cair?
4. Onde vejo o histórico das últimas 50 execuções?
5. Consigo reprocessar um caso falho sem criar lixo?
6. Existe dono do fluxo quando quebrar sexta às 18h?
Se alguma resposta for “não sei”, a automação ainda é demo.
## Traduzindo para o mundo real
Lembra da recepção e do protocolo interno?
O protocolo que grava o cartão na ficha é automação.
O protocolo que grava o mesmo cartão cinco vezes é bagunça.
O protocolo que diz “registramos” e joga o cartão no lixo é pior: destrói confiança.
Automação boa não é a que mais corre. É a que continua correta quando o dia sai do roteiro.
## Quando não “só automatizar mais”
O reflexo errado, depois desses erros, é empilhar nó no n8n até o diagrama parecer metrô de São Paulo.
Às vezes o certo é:
- simplificar o processo antes de orquestrar
- colocar um humano no meio em exceções caras
- negar a automação de um passo que ainda não tem regra estável
Mais nós não corrigem processo mal definido. Só espalham o problema mais rápido.
## O limite da regra — e a porta da próxima etapa
Tudo o que montamos até aqui assume formato combinado.
JSON esperado.
Campos conhecidos.
Caminhos fechados.
Isso é força — e teto.
Porque o cliente da Caetano’s não fala em schema. Ele escreve:
> “Quero um bolo parecido com o da foto para sábado, mas preciso saber se pode ser sem leite.”
Nenhuma comparação `mensagem = ENCOMENDA` resolve isso com elegância. A regra rígida ignora ou empurra tudo para uma pessoa sem contexto.
É nesse ponto — e só nesse ponto — que começa a fazer sentido falar de IA generativa: não para substituir a automação que mal sobreviveu ao webhook, mas para interpretar linguagem quando a regra deixar de bastar.
No próximo bloco da série, vamos entrar nisso com o pé no chão: o que muda ao adicionar um LLM no fluxo, o que continua sendo regra, e o que vira risco se você trocar arquitetura por prompt bonito.
Até lá.
Comentários
Faça login para comentar e reagir.
Carregando comentários...