Un'automazione zombie non è rotta: è accesa e non serve a nessuno
Quando qualcuno si chiede cosa fare con le automazioni che ormai non usa più nessuno, quasi sempre sta pensando a flussi rotti. Non è quello. Un flusso rotto avvisa: si pianta, manda una mail rossa, qualcuno si lamenta e quella stessa mattina si sistema. Uno zombie funziona. Parte alla sua ora, fa esattamente quello che gli hanno chiesto due anni fa e consegna il suo risultato a un processo che non esiste più.
Il report che si genera ogni lunedì per un comitato che è stato sciolto. La sincronizzazione che riversa ordini in un foglio che nessuno apre da marzo. L'avviso che cade in un canale Slack archiviato. La mail settimanale che arriva a un alias dove tre persone hanno una regola di «segna come letto». Tutti verdi, tutti corretti, tutti inutili.
Sopravvivono perché non hanno nessuno che si lamenti. Un flusso rotto ha un proprietario di fatto —chi subisce l'errore—; uno zombie non ha nessuno: la persona che l'ha chiesto è passata a un altro team, quella che l'ha montato se n'è andata, e chi lo vede nel pannello non sa chi dipenda da lui. Nel dubbio, nessuno tocca. E così vanno avanti da tre anni.
Il problema è che non sono gratis. Consumano operazioni o esecuzioni del tuo piano, che sono soldi veri appena il tuo strumento fattura a volume. Tengono vive credenziali —token, utenti di servizio, integrazioni OAuth— molte con permesso di scrittura sul tuo CRM o sul tuo ERP. E sporcano la diagnosi: ogni volta che c'è un incidente, qualcuno perde mezz'ora a scartare flussi che non contano prima di arrivare a quello che conta. Questa guida è lo zoom su quella parte della manutenzione delle automazioni con IA che riguarda il ritirare ciò che è morto, non il curare ciò che è vivo.
L'inventario vero, non quello che credi di avere
Il primo ostacolo non è decidere cosa spegnere: è sapere cosa hai acceso. Quasi nessuna azienda lo sa, perché i flussi non vivono in un posto solo. La scheda principale del tuo strumento di automazione è la punta dell'iceberg.
I sei nascondigli abituali, in ordine di quanti ne saltano fuori quando si alza il tappeto:
- Lo strumento principale (Make, n8n, Zapier, Power Automate), incluse le cartelle di altri utenti e gli scenari «privati» di chi li ha montati.
- I flussi nativi dentro ogni SaaS: workflow di HubSpot, regole di Salesforce, automazioni di Notion o Airtable. Nessuno li conta come automazioni e sono una legione.
- Gli script schedulati: Apps Script in Google Workspace, macro con trigger, cron su un server amministrato da qualcuno che non c'è più.
- Le attività pianificate nel cloud: Cloud Scheduler, EventBridge, job di un container. È qui che vive la roba cara.
- I webhook in entrata che puntano a endpoint tuoi: non si vedono in nessun pannello di automazione, solo nei log del server.
- Gli agenti e i prompt in produzione con trigger proprio, che in molte aziende sono già lo strato più nuovo e il peggio inventariato.
Ogni riga dell'inventario ha bisogno di sette colonne e non una di più: nome, cosa produce (l'output concreto, non «gestisce ordini»), chi lo consuma, ultima esecuzione, frequenza, credenziali che usa e permessi di quelle credenziali. La colonna che fa tutto il lavoro è la terza. Se non riesci a scrivere un nome proprio —una persona o un sistema identificabile— sotto «chi lo consuma», hai già il tuo candidato senza bisogno di indagare altro.
Esecuzione non è uso: come capire se un flusso viene usato davvero
Qui è dove sbagliano tutti: si ordina la lista per «ultima esecuzione» e si danno per buoni quelli che hanno girato ieri. Ma uno zombie si esegue puntualmente ogni giorno —è letteralmente la sua definizione—. L'esecuzione misura che il flusso è vivo, non che il suo risultato interessi a qualcuno. Sono due domande diverse e solo a una stai cercando di rispondere.
Ci sono tre segnali che misurano davvero il consumo, e quale usare dipende da cosa fa il flusso alla fine:
Se scrive in un sistema
Guarda il record che produce, non il flusso. Qualcuno apre quel documento? Quella riga viene modificata dopo essere stata creata? Il campo che riempie compare in qualche report o vista che qualcuno consulta? Gli strumenti di office e i CRM salvano la data di ultimo accesso: è il dato più onesto che troverai e quasi nessuno lo guarda.
Se notifica
Qualcuno risponde, reagisce o clicca? Un canale archiviato, una mailing list con regola di archiviazione automatica o un avviso che ha ottocento messaggi senza una sola risposta sono la stessa cosa: nessuno lo legge. Se la tua piattaforma di messaggistica ti fa vedere letture o reazioni, hai la risposta in un minuto.
Se alimenta un altro flusso
Controlla se anche quell'altro flusso è nella tua lista dei dubbi. Gli zombie arrivano in catena: qualcuno ha spento il consumatore finale un anno fa e ha lasciato viva tutta la tubatura che lo alimentava. Questa è quella che fa risparmiare di più quando salta fuori, perché ne cade mezza dozzina in un colpo solo.
Quando nessun segnale è conclusivo —e succederà in un terzo dei casi— resta un metodo economico, onesto e sorprendentemente poco usato: la prova del silenzio. Spegni il flusso, lasci un avviso visibile al suo posto (un messaggio automatico di «questo è in pausa, scrivi qui se ti serve», una nota nel foglio, una riga fissata nel canale) e aspetti un ciclo completo di business. Un mese di solito basta; un trimestre se il processo è trimestrale. Se nessuno reclama, hai la risposta.
La regola che rende la prova del silenzio legittima e non una roulette: si spegne con avviso e con finestra, mai in silenzio. Spegnere di nascosto per vedere che succede è il modo più rapido perché la prossima pulizia non te la autorizzi nessuno.
Spegnere non è cancellare: le tre mosse
Il vero motivo per cui nessuno spegne niente è che «spegnere» suona irreversibile. E sembra esserlo, perché nella testa di tutti spegnere, togliere permessi e cancellare sono la stessa azione. Non lo sono. Sono tre, con rischi e calendari diversi, e separarle è ciò che sblocca la decisione:
- Smettere di eseguire. Disattivi il trigger. Reversibile in un clic, costo zero, ed è quello che fai il giorno uno. Non cancella niente: il flusso resta lì, con il suo storico intatto.
- Revocare l'accesso. Togli la credenziale, il token o l'utente di servizio che usava —o come minimo gli abbassi i permessi di scrittura a sola lettura—. Questo è quello che quasi nessuno fa, ed è dove sta il rischio vero: un flusso spento con un token vivo resta una chiave con permesso di scrittura sul tuo CRM che gira in giro, senza padrone e senza nessuno che la sorvegli.
- Decidere cosa si conserva. Il flusso si esporta (JSON nel repository, con data e motivo dello spegnimento). I dati che ha prodotto restano dove sono: non si toccano. Registri e log, secondo quello che dice la tua politica di retention. Solo dopo questo si toglie dal pannello, che è l'unica parte davvero irreversibile.
Il calendario conta quanto l'ordine. I passi uno e due, lo stesso giorno —non ha alcun senso spegnere un flusso e lasciargli le chiavi—. Il tre, dopo trenta o novanta giorni di silenzio. Nel mezzo, il flusso è in quarantena: disattivato, senza credenziali, recuperabile in pochi minuti se qualcuno si presenta a reclamarlo. E qualcuno si presenterà: non è un difetto del metodo, è il metodo che funziona.
Il criterio scritto: cosa si spegne senza discutere
Un criterio scritto trasforma una decisione politica —«e se servisse a qualcuno?»— in una operativa. Non serve che sia lungo. Quattro regole e chi firma le eccezioni stanno in mezza pagina:
- Senza consumatore con un nome → quarantena. Se nessuno riesce a scrivere una persona o un sistema identificabile nella colonna «chi lo consuma», il flusso si spegne. «Lo usa operations» non è un nome.
- Senza risultato consumato da 90 giorni → quarantena. Attenzione: risultato consumato, non esecuzione. Un flusso che ha girato ieri e il cui risultato non l'ha aperto nessuno da tre mesi rientra in questa regola.
- Doppione funzionale di un altro flusso vivo → si spegne quello peggio mantenuto, non il più vecchio. L'anzianità non è un criterio di qualità; il numero di interventi manuali dell'ultimo trimestre sì.
- Credenziale di una persona che non è più in azienda → spegnimento immediato, senza finestra. Questa non è pulizia, è sicurezza, e non ammette prova del silenzio.
E una regola che governa le altre quattro: chiunque può reclamare un flusso in quarantena, ma reclamarlo significa accettare di esserne il proprietario con nome e cognome. Non «il reparto». Una persona. Senza questo, il flusso salvato torna zombie in sei mesi e avrai fatto la pulizia per niente. È la stessa logica del proprietario nominale che regge tutta la governance e controllo dell'automazione con IA: senza un nome non c'è controllo, c'è solo un pannello.
Cadenza: un'ora a trimestre, non un progetto di pulizia
La tentazione è montare «il progetto di pulizia delle automazioni»: un mese di lavoro, un foglio di calcolo enorme, un report finale. Si fa una volta, viene bene, e due anni dopo sei al punto di prima. Quello che regge è il contrario: una revisione corta e periodica che sta in un'ora.
Cosa ci sta in quell'ora trimestrale: ripassare i flussi che non hanno avuto risultato consumato, mettere in quarantena quelli che rientrano nel criterio, tirare fuori dalla quarantena quelli che qualcuno ha reclamato (con il suo proprietario già scritto) e cancellare definitivamente quelli che stanno in quarantena da un trimestre senza che nessuno ne senta la mancanza. La prima volta fa male —è normale trovare fra un terzo e la metà dell'inventario in stato dubbio—; dalla seconda in poi sono trenta minuti.
Il pezzo che evita la ricaduta si mette prima, non dopo: ogni flusso nuovo nasce con un proprietario e con una data di revisione. Due campi nella descrizione, trenta secondi quando lo crei. È la differenza fra pulire e non sporcare di nuovo, e va a braccetto con la stessa abitudine di rilevare i guasti che non avvisano: la cosa economica non è aggiustare, è accorgersene in tempo. Se stai per montare tutto questo da zero, la mappa completa è nella guida per automatizzare con l'IA.