Automações zombie: os fluxos que já ninguém usa e que ninguém se atreve a desligar

Uma automação zombie não está partida: está ligada e não serve a ninguém

Quando alguém se pergunta o que fazer com as automações que já ninguém usa, quase sempre está a pensar em fluxos partidos. Não é isso. Um fluxo partido avisa: rebenta, manda um email vermelho, alguém se queixa e nessa mesma manhã arranja-se. Um zombie funciona. Executa-se à sua hora, faz exatamente o que lhe pediram há dois anos e entrega o resultado a um processo que já não existe.

O relatório que se gera todas as segundas-feiras para um comité que se dissolveu. A sincronização que despeja encomendas numa folha que ninguém abre desde março. O aviso que cai num canal de Slack arquivado. O email semanal que chega a um alias onde três pessoas têm uma regra de «marcar como lido». Todos verdes, todos corretos, todos inúteis.

Sobrevivem porque não têm quem se queixe. Um fluxo partido tem dono de facto —quem sofre o erro—; um zombie não tem ninguém: a pessoa que o pediu mudou de equipa, a que o montou foi-se embora, e quem o vê no painel não sabe quem depende dele. Na dúvida, ninguém lhe toca. E assim vão três anos.

O problema é que não são grátis. Consomem operações ou execuções do teu plano, que é dinheiro real assim que a tua ferramenta cobra por volume. Mantêm credenciais vivas —tokens, utilizadores de serviço, integrações OAuth— muitas delas com permissão de escrita sobre o teu CRM ou o teu ERP. E sujam o diagnóstico: sempre que há um incidente, alguém perde meia hora a descartar fluxos que não interessam antes de chegar ao que interessa. Este guia é o zoom àquela parte de manter as automações com IA que trata de retirar o que está morto, não de cuidar do que está vivo.

O inventário real, não o que julgas ter

O primeiro obstáculo não é decidir o que desligar: é saber o que tens ligado. Quase nenhuma empresa sabe, porque os fluxos não vivem num sítio só. O separador principal da tua ferramenta de automação é a ponta do icebergue.

Os seis esconderijos habituais, por ordem de quantos aparecem quando se levanta o tapete:

• A ferramenta principal (Make, n8n, Zapier, Power Automate), incluindo as pastas de outros utilizadores e os cenários «privados» de quem os montou.
• Os fluxos nativos dentro de cada SaaS: workflows do HubSpot, regras do Salesforce, automações do Notion ou do Airtable. Ninguém os conta como automações e são uma legião.
• Os scripts agendados: Apps Script no Google Workspace, macros com acionador, cron num servidor que era administrado por alguém que já não está cá.
• As tarefas agendadas na cloud: Cloud Scheduler, EventBridge, jobs de um contentor. É aqui que vive o que sai caro.
• Os webhooks de entrada que apontam para endpoints próprios: não se veem em painel de automação nenhum, só nos logs do servidor.
• Os agentes e prompts em produção com acionador próprio, que em muitas empresas já são a camada mais nova e a pior inventariada.

Cada linha do inventário precisa de sete colunas e nem mais uma: nome, o que produz (a saída concreta, não «gere encomendas»), quem a consome, última execução, frequência, credenciais que usa e permissões dessas credenciais. A coluna que faz todo o trabalho é a terceira. Se não consegues escrever um nome próprio —uma pessoa ou um sistema identificável— em «quem a consome», já tens o teu candidato sem precisares de investigar mais nada.

Executar não é usar: como saber se um fluxo é mesmo usado

É aqui que toda a gente se engana: ordena-se a lista por «última execução» e dão-se por bons os que correram ontem. Mas um zombie executa-se pontualmente todos os dias —é literalmente essa a sua definição—. A execução mede que o fluxo está vivo, não que o resultado dele interesse a alguém. São duas perguntas diferentes e só uma é a que estás a tentar responder.

Há três sinais que medem consumo a sério, e qual usar depende do que o fluxo faz no fim:

Se escreve num sistema

Olha para o registo que produz, não para o fluxo. Alguém abre esse documento? Essa linha é editada depois de criada? O campo que preenche aparece nalgum relatório ou vista que alguém consulte? As ferramentas de escritório e os CRM guardam data de último acesso: é o dado mais honesto que vais encontrar e quase ninguém olha para ele.

Se notifica

Alguém responde, reage ou clica? Um canal arquivado, uma lista de correio com regra automática de arquivo ou um aviso que leva oitocentas mensagens sem uma única resposta são a mesma coisa: ninguém o lê. Se a tua plataforma de mensagens te deixa ver leituras ou reações, tens a resposta num minuto.

Se alimenta outro fluxo

Verifica se esse outro fluxo também está na tua lista de duvidosos. Os zombies vêm em cadeia: alguém desligou o consumidor final há um ano e deixou viva toda a canalização que o alimentava. Esta é a que mais poupa quando aparece, porque caem meia dúzia de uma vez.

Quando nenhum sinal é conclusivo —e vai acontecer num terço dos casos— resta um método barato, honesto e surpreendentemente pouco usado: a prova do silêncio. Desligas o fluxo, deixas um aviso visível no lugar dele (uma mensagem automática de «isto está em pausa, escreve aqui se precisares», uma nota na folha, uma linha fixada no canal) e esperas um ciclo completo de negócio. Um mês costuma chegar; um trimestre se o processo for trimestral. Se ninguém reclamar, tens a resposta.

A regra que torna a prova do silêncio legítima e não uma roleta: desliga-se com aviso e com janela, nunca em silêncio. Desligar às escondidas para ver o que acontece é a forma mais rápida de ninguém autorizar a próxima limpeza.

Desligar não é apagar: os três movimentos

A verdadeira razão por que ninguém desliga nada é que «desligar» soa a irreversível. E parece mesmo, porque na cabeça de toda a gente desligar, retirar permissões e apagar são a mesma ação. Não são. São três, com riscos e calendários diferentes, e separá-las é o que desbloqueia a decisão:

1. Deixar de executar. Desativas o acionador. Reversível num clique, custo zero, e é o que fazes no dia um. Não apaga nada: o fluxo continua lá, com o histórico intacto.
2. Revogar o acesso. Retiras a credencial, o token ou o utilizador de serviço que usava —ou no mínimo baixas-lhe as permissões de escrita para só leitura—. Isto é o que quase ninguém faz, e é onde está o risco a sério: um fluxo desligado com um token vivo continua a ser uma chave com permissão de escrita sobre o teu CRM a circular por aí, sem dono e sem ninguém a vigiá-la.
3. Decidir o que se conserva. O fluxo exporta-se (JSON para o repositório, com data e motivo do desligamento). Os dados que produziu ficam onde estão: não se tocam. Os registos e os logs, conforme o que disser a tua política de retenção. Só depois disto se retira do painel, que é a única parte verdadeiramente irreversível.

O calendário importa tanto como a ordem. Os passos um e dois, no mesmo dia —não faz sentido nenhum desligar um fluxo e deixar-lhe as chaves—. O três, passados trinta ou noventa dias de silêncio. Pelo meio, o fluxo está em quarentena: desativado, sem credenciais, recuperável em minutos se alguém aparecer a reclamá-lo. E alguns vão aparecer: isso não é uma falha do método, é o método a funcionar.

O critério escrito: o que se desliga sem discussão

Um critério escrito transforma uma decisão política —«e se alguém precisar disto?»— numa decisão operativa. Não precisa de ser longo. Quatro regras e quem assina as exceções cabem em meia página:

• Sem consumidor com nome → quarentena. Se ninguém consegue escrever uma pessoa ou um sistema identificável na coluna «quem o consome», o fluxo desliga-se. «Usa-o a operações» não é um nome.
• Sem resultado consumido em 90 dias → quarentena. Atenção: resultado consumido, não execução. Um fluxo que correu ontem e cujo resultado ninguém abre há três meses cumpre esta regra.
• Duplicado funcional de outro fluxo vivo → desliga-se o pior mantido, não o mais antigo. A antiguidade não é um critério de qualidade; o número de intervenções manuais do último trimestre, esse sim.
• Credencial de uma pessoa que já não está na empresa → desligamento imediato, sem janela. Isto não é limpeza, é segurança, e não admite prova do silêncio.

E uma regra que governa as outras quatro: qualquer pessoa pode reclamar um fluxo em quarentena, mas reclamá-lo significa aceitar ser o seu dono com nome e apelido. Não «o departamento». Uma pessoa. Sem isso, o fluxo resgatado volta a ser zombie dentro de seis meses e terás feito a limpeza para nada. É a mesma lógica de dono nominal que sustenta toda a governança e controlo da automação: sem nome não há controlo, só um painel.

Cadência: uma hora por trimestre, não um projeto de limpeza

A tentação é montar «o projeto de limpeza de automações»: um mês de trabalho, uma folha de cálculo enorme, um relatório final. Faz-se uma vez, corre bem, e dois anos depois estás na mesma. O que aguenta é o contrário: uma revisão curta e periódica que cabe numa hora.

O que cabe nessa hora trimestral: rever os fluxos que não tiveram resultado consumido, mover para quarentena os que cumpram critério, tirar da quarentena os que alguém tenha reclamado (com o dono já escrito) e apagar definitivamente os que levam um trimestre em quarentena sem que ninguém sinta a falta deles. A primeira vez dói —é normal encontrar entre um terço e metade do inventário em estado duvidoso—; a partir da segunda são trinta minutos.

A peça que evita a recaída põe-se antes, não depois: cada fluxo novo nasce com dono e com data de revisão. Dois campos na descrição, trinta segundos ao criá-lo. É a diferença entre limpar e não voltar a sujar, e encaixa no mesmo hábito de detetar as falhas que não avisam: o barato não é arranjar, é dar por isso a tempo. Se vais montar tudo isto de raiz, o mapa completo está no guia de automatizar com IA.