A automação que mais falha: lições de 50 projetos

Depois de implementar mais de 50 automações em empresas da Argentina, Uruguai, Colômbia e México, posso dizer com certeza que o problema quase nunca é técnico. As automações que mais falham não são as que usam tecnologia complexa ou integram sistemas difíceis. São as que se constroem sobre processos que ninguém se deu ao trabalho de entender primeiro.

Existe uma fantasia perigosa no mercado: a de que a automação é um atalho. Que você pode pegar um processo manual caótico, colocar tecnologia por cima, e magicamente ele se torna eficiente. Não funciona assim. Nunca funcionou assim. E mesmo assim, continuamos vendo empresas caírem na mesma armadilha.

O dado concreto: dos mais de 50 projetos que executamos, 35% dos que começaram mal foi porque o cliente queria automatizar um processo que nem sequer tinha documentado. Outros 25% falharam porque não se mediu o estado atual antes de começar. E 15% morreram porque ninguém pensou no que acontece quando o bot encontra um caso que não entende.

Este artigo é um passeio pelos erros que vimos, as lições que tiramos, e o framework que desenvolvemos para que as automações não só funcionem na demo, mas sobrevivam em produção.

É o erro mais comum e o mais caro. Uma distribuidora de alimentos em Buenos Aires nos chamou para automatizar seu processo de pedidos. O fluxo era assim: os vendedores mandavam pedidos por WhatsApp para uma assistente administrativa, que os passava para um Excel, que depois era carregado manualmente no ERP. Queriam que um bot pegasse as mensagens do WhatsApp e as carregasse direto no ERP.

Quando mapeamos o processo, descobrimos que a assistente não só transcrevia — também corrigia erros dos vendedores (códigos de produto errados, quantidades impossíveis), validava estoque olhando outra planilha, e ligava para o cliente quando algo não batia. Automatizar o fluxo do jeito que estava teria gerado um desastre de pedidos incorretos.

O que fizemos: primeiro redesenhamos o processo. Os vendedores passaram a usar um formulário estruturado em um app simples (nada mais de WhatsApp livre). O formulário valida códigos e quantidades contra o catálogo em tempo real. Só depois automatizamos a carga no ERP. O resultado: 94% de redução no tempo de carga, e os erros caíram de 12% para menos de 1%.

A lição é dura mas simples: se você automatiza um processo quebrado, só consegue que ele quebre mais rápido. Sempre é preciso redesenhar primeiro.

Um escritório contábil com 80 funcionários nos pediu para automatizar a conciliação bancária. 'Leva muito tempo', nos disseram. Quando perguntamos quanto exatamente, a resposta foi 'muito'. Não tinham métricas.

Insistimos em medir antes de mexer em qualquer coisa. Resultado: a conciliação consumia 340 horas/mês distribuídas em 8 pessoas. O custo real era de USD 5.100/mês (considerando salários e overhead). A taxa de erro era de 3,2%, o que gerava retrabalhos que somavam outras 45 horas/mês.

Com esses números, pudemos montar um business case sólido, priorizar quais conciliações automatizar primeiro (as de maior volume e menor complexidade), e projetar um ROI realista. Pós-implementação: as 340 horas caíram para 40 (as que exigem intervenção humana por exceções), o erro caiu para 0,1%, e o ROI foi de 680% no primeiro ano.

Sem a medição inicial, nada disso teria sido possível. Não teríamos sabido por onde começar, não poderíamos ter justificado o investimento perante a diretoria, e não teríamos como demonstrar o impacto depois. Se você não consegue medir o processo antes de automatizá-lo, não automatize.

Uma companhia de seguros nos contratou para automatizar a abertura de sinistros. O fluxo principal era limpo: o segurado reporta pelo site, o sinistro é classificado, um ajustador é designado, e o pedido é processado. Automatizamos tudo em 6 semanas e o piloto foi impecável.

Duas semanas em produção, começaram os problemas. Sinistros com múltiplos veículos envolvidos que o sistema não sabia como registrar. Relatos onde o segurado não era o condutor. Casos onde o mesmo sinistro era reportado duas vezes por canais diferentes. Reclamações contra a apólice de um terceiro. Cada um desses edge cases representava menos de 2% do volume, mas somados eram 18% dos casos totais.

A equipe de operações acabou com mais trabalho do que antes, porque tinha que resolver os casos que o bot registrava errado além dos que processava corretamente. A automação gerou mais carga operacional nas primeiras semanas.

A solução: implementamos um sistema de 'escalamento inteligente'. Quando o bot detecta um caso que não se encaixa nos padrões conhecidos, ele marca, extrai a informação que conseguiu processar, e escala para um operador humano com contexto. O operador resolve, e essa resolução alimenta o modelo para que da próxima vez ele lide sozinho. Em 3 meses, os edge cases que exigiam intervenção caíram de 18% para 5%.

Este é um clássico que vemos em empresas onde um C-level se empolgou com AI depois de uma conferência. Chegam com uma lista de 15 processos para automatizar e querem começar todos ao mesmo tempo. É a receita perfeita para o fracasso.

Uma empresa de logística em Montevidéu queria automatizar: faturamento, rastreamento de envios, atendimento ao cliente, gestão de reclamações, relatórios para clientes, coordenação de fretes, liquidação de comissões, e controle de estoque. Tudo de uma vez. Com uma equipe de TI de 4 pessoas.

O que fizemos: dissemos não. Propusemos começar por UM único processo — o que tivesse maior volume, menor complexidade, e maior impacto visível. Escolhemos faturamento. Em 8 semanas automatizamos, estabilizamos, e a equipe de TI aprendeu a mantê-lo. Só então passamos para o segundo processo.

18 meses depois, têm 6 dos 8 processos automatizados, funcionando em produção, com métricas claras de impacto. Se tivéssemos começado todos de uma vez, estou convicto de que hoje não teriam nenhum funcionando bem.

A regra: um processo por vez. No máximo dois se forem independentes e você tiver equipe suficiente. Automação é um músculo que se treina, não um botão que se aperta.

Um banco digital nos pediu para automatizar o processo de onboarding de clientes corporativos. Trabalhamos com a área de tecnologia e com o gerente de operações. Desenhamos uma solução tecnicamente impecável. Quando colocamos em produção, os analistas de onboarding odiaram.

Por quê? Porque ninguém perguntou a eles como faziam o trabalho de verdade. O processo documentado dizia uma coisa, mas na prática os analistas tinham desenvolvido atalhos, validações informais e critérios próprios que não estavam em nenhum manual. A automação ignorou todos.

Aprendemos a lição da pior maneira. Agora, antes de automatizar qualquer processo, passamos 2-3 dias sentados ao lado das pessoas que o executam. Não lendo documentação — observando. Perguntando 'por que você faz assim?' e 'o que acontece quando X?'. 90% da informação crítica para uma boa automação está na cabeça das pessoas que fazem o trabalho, não nos manuais de procedimento.

O benefício extra: quando a equipe participa do design, a adoção é radicalmente melhor. Passam de 'os que o bot vai substituir' para 'os que desenharam como o bot trabalha'. E isso muda tudo.

Isso parece básico, mas vemos o tempo todo: empresas que implementam uma automação, deixam rodando, e não olham mais até que explode. É como contratar um funcionário novo e nunca supervisioná-lo.

Um caso que nos doeu: uma empresa de e-commerce automatizou a atualização de preços do ERP para a loja online. Funcionou perfeito durante 3 meses. Um dia, um erro no ERP mandou preços zerados para 200 produtos. O bot os atualizou diligentemente. Venderam 47 produtos a R$0 antes de alguém perceber.

Desde então, toda automação que implantamos inclui um stack de monitoramento inegociável: alertas por anomalias (volume incomum, valores fora do esperado, taxas de erro), dashboard de performance em tempo real, log completo de cada execução com rastreabilidade, e circuit breakers automáticos que pausam a automação quando algo não bate.

O monitoramento não é um nice-to-have. É parte do custo da automação. Se você não pode bancá-lo, não está pronto para automatizar.

Depois de todos esses aprendizados, desenvolvemos um framework que aplicamos em cada projeto. Não é ciência de foguete — é bom senso sistematizado. Mas funciona.

Medir: antes de mexer em qualquer coisa, medimos o processo atual. Tempo por execução, frequência, taxa de erro, custo real (incluindo overhead), e satisfação da equipe. Isso nos dá a linha de base para calcular ROI e priorizar.

Redesenhar: com os dados em mãos, analisamos o processo. Tem passos desnecessários? Pode ser simplificado? Os edge cases estão identificados? O fluxo de informação faz sentido? Redesenhamos primeiro no papel — sem tecnologia — até que o processo faça sentido.

Automatizar: só agora colocamos tecnologia. Escolhemos as ferramentas conforme o caso (RPA, integrações via API, workflows com AI, ou uma combinação). Implementamos em fases: primeiro o fluxo principal com os casos mais comuns, depois vamos adicionando edge cases.

Monitorar: implantamos o stack de observabilidade desde o primeiro dia. Definimos KPIs claros (tempo de execução, taxa de sucesso, volume processado, exceções), configuramos alertas, e revisamos performance semanalmente durante o primeiro mês, quinzenalmente nos dois seguintes.

Cada fase tem um checkpoint com o cliente onde decidimos se avançamos, ajustamos, ou pivotamos. Não há compromisso de 'automatizar X coisa' — há compromisso de 'melhorar Y métrica'. Isso muda completamente a dinâmica do projeto.

Vou compartilhar números reais (anonimizados) de projetos que concluímos nos últimos 18 meses.

Projeto 1 — Conciliação bancária (escritório contábil, 80 pessoas): Investimento total USD 35.000. Economia anual USD 61.200. ROI no primeiro ano: 175%. Tempo de retorno: 7 meses.

Projeto 2 — Processamento de faturas (distribuidora, 200 pessoas): Investimento total USD 28.000. Economia anual USD 89.000. ROI no primeiro ano: 318%. Tempo de retorno: 4 meses. Bônus: eliminaram 2 dias de atraso no ciclo de cobrança.

Projeto 3 — Onboarding de clientes (fintech, 120 pessoas): Investimento total USD 52.000. Economia anual USD 145.000. ROI no primeiro ano: 279%. Tempo de retorno: 5 meses. Bônus: o NPS de novos clientes subiu 23 pontos.

Projeto 4 — Classificação de tickets de suporte (SaaS, 60 pessoas): Investimento total USD 18.000. Economia anual USD 42.000. ROI no primeiro ano: 233%. Tempo de retorno: 6 meses.

O padrão é consistente: as automações bem feitas se pagam sozinhas em 4-7 meses. As que são mal feitas... bom, por isso você está lendo este artigo.

Um dado importante: esses números incluem nossos honorários, o custo de licenças de ferramentas, e o investimento de tempo da equipe do cliente. Não são números inflados — é o que realmente aconteceu.

Antes de entrar em contato com qualquer consultoria (incluindo nós), faça a si mesmo estas perguntas:

Você consegue descrever o processo em um parágrafo? Se não consegue explicá-lo claramente, ele não está pronto para ser automatizado. Primeiro documente.

Você tem métricas do processo atual? Se não sabe quanto tempo leva, com que frequência é executado, e qual é a taxa de erro, comece medindo.

O processo é estável? Se muda a cada duas semanas, automatizá-lo é jogar dinheiro fora. Espere ele se estabilizar.

Você tem alguém que possa supervisionar a automação? Não precisa de um engenheiro full-time, mas sim de alguém que revise alertas e saiba o que fazer quando algo falha.

A equipe está a bordo? Se as pessoas que fazem o trabalho veem a automação como uma ameaça, ela vai fracassar. Envolva a equipe desde o primeiro dia.

Se respondeu 'sim' às cinco, você está pronto. Se respondeu 'não' a alguma, isso não significa que não pode automatizar — significa que tem trabalho prévio a fazer. E esse trabalho prévio é tão valioso quanto a automação em si.

Na Orionis fazemos as duas coisas: ajudamos a preparar o terreno e depois automatizamos. Se quiser avaliar seus processos, escreva para [email protected]. A conversa inicial é sem custo e sem compromisso.