Automações que parecem simples mas falham sempre

“É simples: quando chega um email de confirmação de encomenda, extraímos o número da encomenda, procuramo-lo no ERP e atualizamos o estado no site.” Foi assim que começou a conversa com um cliente que queria automatizar o seu fluxo de encomendas. 6 meses depois, a automação tinha falhado dezenas de vezes, cada falha tinha exigido intervenção manual e o cliente estava mais sobrecarregado do que antes.

O problema não era a tecnologia, mas sim o facto de o processo real ser mais complexo do que parecia: formatos de email inconsistentes, encomendas parciais, devoluções que usavam o mesmo tipo de email e alterações no modelo que estragavam o parser (o código que lê a mensagem e extrai os dados).

Há padrões de automação que vemos falhar vezes sem conta. Não são falhas técnicas, são falhas na análise do processo.

Padrão 1: extrair dados de emails

A ideia é atraente: o email é universal e parece simples. A realidade é outra:

Os emails são HTML inconsistente. Uns chegam bem paginados, outros com HTML caótico gerado a partir do Word e outros em texto simples. O teu parser tem de os perceber a todos.

Os remetentes mudam sem avisar. O fornecedor muda de ferramenta de envio e as confirmações passam a chegar de outro endereço e com outro formato. A automação para até alguém dar por isso.

Corpo, anexos ou ligações. Os dados podem estar no corpo, num PDF anexo, atrás de uma ligação externa ou nos três sítios ao mesmo tempo, com informação contraditória.

Casos-limite humanos. O email de “encomenda cancelada” usa o mesmo modelo que o de “encomenda confirmada”, com uma única linha diferente. O parser marca-a como concluída quando devia marcá-la como cancelada.

Alternativa mais robusta: ligações diretas por API entre sistemas sempre que possível. Quando não for, formatos estruturados (um CSV por SFTP, webhooks com JSON) em vez de emails em texto livre. Se trabalhas com ferramentas como o Make ou o Zapier, aqui explicamos como ligar o teu site ao Make/Zapier sem criar uma bomba-relógio.

Padrão 2: sincronizar dados entre sistemas

“Quero que o CRM e o ERP tenham os mesmos clientes.” Parece razoável. A realidade:

Formatos de dados incompatíveis. O CRM tem “nome” e “apelidos” separados; o ERP, um único campo “nome_completo”. O CRM usa “ES” para Espanha e o ERP usa “34” ou “ESP” conforme o campo.

Ciclos de sincronização. A atualiza um cliente e sincroniza-o com B. B faz uma alteração automática (por exemplo, atribuir um número de cliente), isso dispara uma sincronização de volta para A e a alteração original é sobrescrita. E assim sem fim.

Conflitos de edição. Alguém edita o mesmo cliente nos 2 sistemas entre uma sincronização e a seguinte. Que versão ganha? A mais recente não tem de ser a correta para o negócio.

Sistema de referência. Que sistema “manda”? Se o ERP é o sistema financeiro oficial, talvez certos campos só devam poder ser atualizados a partir dele. Defini-lo exige perceber o negócio, e não só a tecnologia.

Solução: um sistema de referência claro para cada dado, campos de “última modificação” e “origem da alteração”, e resolução manual de conflitos para os casos problemáticos. Nada de sincronizar às cegas. Explicamos isto com mais detalhe em o que uma empresa ganha quando os seus sistemas deixam de funcionar em silos.

Padrão 3: automatizar de ponta a ponta processos que exigem critério

Uma empresa tinha um processo de registo de clientes com 5 passos: verificar a documentação, criar contas em 2 sistemas diferentes, enviar um email de boas-vindas consoante o tipo de cliente e avisar a equipa de gestão de conta.

Automatizaram-no por completo. O resultado: clientes com documentação incompleta foram ativados na mesma, foram criadas contas nos sistemas errados porque a classificação por tipo de cliente falhou e os emails de boas-vindas acabaram no spam porque ninguém tinha verificado a entregabilidade.

O erro foi automatizar decisões que exigiam critério humano.

Alternativa: automatizar os passos mecânicos (criar contas, enviar emails) e manter um ponto de aprovação humana antes da ativação final. Semiautomação em vez de automação total.

Padrão 4: integrar com APIs que “funcionam bem”

“A API do fornecedor está documentada e funciona.” Sim, nos testes. Em produção:

Limites de utilização não documentados. A API aceita 100 chamadas por minuto nos testes. Em produção, com volume real, começas a receber erros 429 (Too Many Requests) sem aviso prévio.

Falhas de serviço não anunciadas. O fornecedor reinicia os servidores aos domingos às 3 da manhã. A tua automação falha em silêncio e ninguém dá por isso até segunda-feira.

Alterações sem controlo de versões. Um campo que era obrigatório passa a ser opcional e a tua validação falha. Ou aparece um campo novo e o teu código ignora dados importantes.

Erros ambíguos. A API devolve um 200 OK, mas o corpo diz {“status”: “error”}. Ou devolve um 500 sem corpo.

Solução: registos detalhados, novas tentativas com esperas crescentes (backoff exponencial), disjuntores ou circuit breakers (se a API falhar demasiado, deixa-se de insistir durante algum tempo) e uma monitorização que avise quando as falhas ultrapassam um limiar aceitável.

Padrão 5: fazer scraping porque não há API

O scraping (extrair dados diretamente de páginas web) é tentador quando não há API oficial, mas é frágil por natureza:

O HTML muda. Um redesign do site, uma alteração nas classes CSS ou uma estrutura diferente, e o teu scraper deixa de extrair os dados certos, muitas vezes sem que ninguém dê por isso.

Medidas anti-scraping. CAPTCHAs, limites de pedidos, bloqueios de IP. O scraper funciona em desenvolvimento e falha em produção quando o site deteta o volume.

Condições de utilização. Muitos sites proíbem o scraping nas suas condições de utilização. Podem bloquear-te tecnicamente e, em alguns casos, também agir contra ti pela via legal.

Dados pensados para pessoas. A página mostra dados formatados para serem lidos, não dados estruturados: “há 2 horas” em vez de uma data e hora exatas, “1,2 M€” em vez de 1200000.

Alternativa: negociar um acesso oficial à API (mesmo que seja pago), usar dados públicos estruturados se existirem ou repensar se precisas mesmo desses dados de forma automatizada.

Padrão 6: automatizar decisões com dados incompletos

“Se o cliente não compra há 90 dias, enviar-lhe um email de reativação com desconto.” Parece lógico. Mas:

• E se o cliente comprou na loja física e essa compra não consta do sistema?
• E se não quiser receber comunicações comerciais?
• E se já recebeu 3 emails de reativação e não abriu nenhum? Continuamos a insistir?

Os dados que vês não são a realidade completa.

Solução: mais dados de contexto, limiares conservadores e, sempre, respeitar os pedidos de cancelamento e as preferências de comunicação de cada cliente, o que além disso é uma obrigação legal.

Como fazer automações que não falhem (ou que falhem bem)

Não somos contra a automação: usamo-la constantemente, mas com precauções.

1. Perceber o processo antes de o automatizar. Observar como é feito à mão durante umas semanas, identificar todos os casos-limite e perguntar “o que acontece se…?” até esgotar as respostas.

2. Desenhar para o erro, não para o caso ideal. Numa automação bem feita, boa parte do código dedica-se a gerir erros, deixar registo e recuperar. O caso ideal é a parte fácil.

3. Registos detalhados. Quando alguma coisa falha, precisas de saber exatamente o que aconteceu: identificadores, datas e horas, conteúdo das chamadas às APIs. Depurar sem logs é adivinhar, e sem documentação é ainda pior: contamos isso em o custo oculto das automações mal documentadas.

4. Monitorização e alertas. Configura avisos para quando as falhas ultrapassarem um limiar, quando faltar a atividade esperada ou quando os dados parecerem anómalos.

5. Regresso ao manual. Quando a automação falha, tem de ser fácil intervir à mão sem estragar nada e sem ficar num estado intermédio com dados a meio.

6. Começar simples e alargar aos poucos. Automatizar primeiro o caso mais comum, com alertas para as exceções, e ir incorporando casos-limite à medida que aparecem.

Perguntas frequentes

Como sei se o meu processo é suficientemente estável para o automatizar?

Se muda todas as semanas, se tem muitas exceções resolvidas à mão ou se exige critério constantemente, provavelmente não é um bom candidato. Os processos repetitivos e bem definidos são os melhores.

Quanto custa manter uma automação?

Como referência orientativa, conta com entre 10% e 30% do custo de desenvolvimento inicial por ano para manutenção, ajustes e novos casos-limite. O importante é orçamentá-lo desde o início e incluí-lo ao calcular o ROI real do projeto de automação.

O que faço se uma automação falha constantemente?

Reavaliar se vale a pena. Voltar ao processo manual é uma opção válida se a automação gerar mais trabalho do que poupa.

Conclusão

A automação é poderosa, mas não é mágica. As automações que parecem simples escondem muitas vezes uma complexidade que só aparece em produção. A chave está em antecipar essa complexidade, desenhar a pensar na falha e manter expectativas realistas.

Se estás a pensar em automatizar processos e queres uma avaliação honesta da viabilidade e do custo real, conta-nos o que queres automatizar. Preferimos dizer-te logo no início “isto é mais complexo do que parece” do que “isto não funciona como esperavas” 6 meses depois.