7 min de leitura
A automação disse "sucesso". O cliente foi cobrado duas vezes.
Pedido duplicado, cobrança em dobro, lead que some: o erro mais caro de automação é o que diz sucesso. Veja por que acontece e o que cobrar de quem fez a sua.

Em 1º de agosto de 2012, a partir de mais ou menos 8h da manhã em Nova York, um sistema da Knight Capital começou a mandar e-mails automáticos para funcionários da empresa. Antes da abertura do mercado, foram 97. Todos com a mesma mensagem de erro: "Power Peg disabled".
Ninguém tratou aquilo como alerta. Segundo a ordem da SEC, o órgão que regula o mercado de ações dos Estados Unidos, esses e-mails não tinham sido desenhados para funcionar como alerta, e a equipe geralmente não os lia.
O mercado abriu. Ao processar 212 ordens de clientes, o sistema automático de roteamento de ordens da Knight mandou milhões de ordens ao mercado em 45 minutos: foram mais de 4 milhões de negócios fechados, com mais de 397 milhões de ações. A Knight perdeu mais de US$ 460 milhões. Depois, levou uma multa de US$ 12 milhões.
Você não opera na bolsa. Mas a lição serve inteira para uma empresa de 15 pessoas: aviso que ninguém lê não é alerta.
O erro que trava é o menos perigoso
Quando uma automação para de funcionar, alguém percebe. O pedido não aparece, o vendedor reclama, o cliente liga. É chato, mas é visível.
O pior erro é o outro: a automação roda, o painel mostra "sucesso" em verde, e a coisa errada acontece em silêncio. Alguns exemplos que podem aparecer em qualquer operação:
- O mesmo pedido entra duas vezes e é separado duas vezes no estoque.
- O cliente é cobrado duas vezes pela mesma compra.
- Um lead do formulário nunca chega ao CRM, e ninguém fica sabendo que ele existiu.
- A mensagem de confirmação não sai, mas o fluxo marca como enviada.
Nenhuma das duas aparece no teste de demonstração. Elas aparecem na terceira semana, com volume real.
Por que a duplicidade acontece
Vale entender o mecanismo, porque ele muda o que você deve cobrar de quem faz a sua automação.
Quando um sistema avisa outro que algo aconteceu (um pagamento aprovado, um pedido novo), normalmente usa um webhook: uma mensagem automática que um sistema manda para outro na hora do evento. Daqui pra frente, vou chamar só de aviso.
Quem manda o aviso espera uma confirmação de recebimento. Se a confirmação não chega a tempo, porque o outro lado estava lento, ficou fora do ar por um minuto ou demorou para processar, o aviso é mandado de novo.
Isso é comportamento esperado, não defeito. A documentação da Stripe, plataforma de pagamentos, diz que os sistemas que recebem avisos "podem ocasionalmente receber o mesmo evento mais de uma vez" (tradução livre). Em produção, a Stripe tenta reenviar um aviso por até três dias. E ela não garante que os avisos cheguem na ordem em que os eventos aconteceram.
Traduzindo para a sua operação: se a automação não estiver preparada, o mesmo pagamento aprovado pode gerar duas notas, duas mensagens de agradecimento ou duas baixas no estoque. E o aviso de "pagamento cancelado" pode chegar antes do "pagamento aprovado", deixando o status final errado.
Na mesma página, a Stripe recomenda o remédio: registrar os avisos que já foram processados e ignorar os repetidos.
O que uma automação bem feita precisa ter
Você não precisa saber o nome técnico de nada disso para cobrar. São quatro coisas.
Lembrar o que já foi feito
Todo aviso tem uma identificação. A automação precisa guardar quais já processou e, se o mesmo chegar de novo, não fazer nada. Parece óbvio. Só que muita automação montada às pressas não faz isso, porque no teste cada aviso chegou uma vez só.
O mesmo cuidado vale para a ordem. Em vez de confiar que o último aviso que chegou é o mais recente, a automação confere o estado atual no sistema de origem antes de agir.
Alerta que chega numa pessoa com nome
Um erro gravado num histórico que ninguém abre é igual aos 97 e-mails da Knight. Um alerta que funciona chega onde a pessoa já olha (o WhatsApp dela, o e-mail que ela lê, o canal do time), tem um responsável com nome e diz o que fazer.
E alerta demais vira ruído. Se o canal apita 40 vezes por dia por coisa sem importância, as pessoas param de ler, e o alerta que importa passa batido. Prefira poucos alertas, todos levados a sério.
Conferência diária simples
É a que eu mais recomendo e a que menos gente faz. Todo dia, um número precisa bater com outro. Por exemplo:
- Pedidos que entraram na loja x pedidos que o financeiro viu.
- Leads do formulário x leads criados no CRM.
- Pagamentos aprovados na plataforma x baixas no sistema.
Se os números não batem, alguém é avisado. Essa conferência pega exatamente o que o "sucesso" esconde: o que sumiu e o que duplicou. Pode ser uma automação pequena ou uma planilha que alguém olha toda manhã. O importante é existir.
Um dono
Automação não é obra que termina na entrega. A plataforma de pagamento muda o formato do aviso, o CRM troca um campo, a regra de desconto muda. Alguém precisa perceber e ajustar. Sem dono, a automação piora aos poucos, e o primeiro a perceber costuma ser o cliente.
5 perguntas para fazer pra quem fez a sua automação
Leve estas perguntas para a próxima conversa com quem montou seus fluxos, seja alguém do time, um freelancer ou uma empresa.
- Se o mesmo aviso chegar duas vezes, o que acontece? A resposta boa explica como a automação reconhece o repetido. A ruim é "isso não acontece".
- Se um passo falhar no meio, quem fica sabendo e em quanto tempo? Peça o nome da pessoa e o canal.
- Que conferência garante, todo dia, que nada sumiu nem duplicou? Se não existe nenhuma, quem vai descobrir o problema é o cliente.
- Se um dos sistemas ligados mudar alguma coisa, quem percebe e quem ajusta? Sem resposta clara, a manutenção fica por conta da sorte.
- Onde está escrito como isso funciona? Se a resposta é "na minha cabeça", o risco é seu.
Respostas vagas não querem dizer que a pessoa trabalhou mal. Querem dizer que a automação foi feita para funcionar, e ainda falta prepará-la para falhar sem estrago.
Onde a Nov.IA entra
Construir a automação é metade do trabalho. A outra metade é acompanhar depois. É para isso que existe o Tech Partner: acompanhamento mensal, com monitoramento dos fluxos, correção quando algo falha e ajuste quando a operação muda.
Se você ainda está escolhendo o que automatizar, comece pelo guia de automação de processos. Ele tem uma seção sobre os erros que fazem uma automação dar errado. E se quiser ver como funciona um projeto com escopo fechado, com alertas de falha desde o primeiro dia, veja o Sprint de Automação.
Fontes
- SEC: comunicado 2013-222 sobre a Knight Capital
- SEC: ordem administrativa sobre a Knight Capital (PDF)
- Stripe: documentação de webhooks
Perguntas frequentes
Por que minha automação duplica pedidos ou cobranças?
Porque sistemas reenviam o mesmo aviso quando não recebem confirmação a tempo. A Stripe, por exemplo, documenta que o mesmo evento pode chegar mais de uma vez. A automação precisa registrar o que já processou e ignorar os repetidos.
Como saber se uma automação está falhando em silêncio?
Com uma conferência diária simples: compare números que deveriam bater, como pedidos que entraram e pedidos que o financeiro viu. Se não batem, uma pessoa com nome recebe um alerta.
Registro de erro serve como alerta?
Não. Um registro que ninguém lê não avisa ninguém. Alerta de verdade chega onde a pessoa já olha, tem um responsável com nome e diz o que fazer.
Automação precisa de manutenção?
Sim. Sistemas, campos e regras mudam. Sem alguém responsável por monitorar e ajustar, a automação piora aos poucos, e o primeiro a perceber costuma ser o cliente.
Tem automação rodando e não sabe se ela está errando em silêncio? No diagnóstico gratuito de 30 minutos, você mostra os fluxos que já existem. A gente aponta onde pode haver duplicidade, aviso perdido ou falta de dono.
Quer que a gente olhe isso na sua operação?
Em 30 minutos você mostra a rotina e os sistemas envolvidos. A gente aponta o que vale mexer primeiro e o que pode esperar.
Agendar diagnóstico gratuito (30 min)