Una cinquantina di automazioni e un registro per sapere se sono vive
Ogni processo che gira da solo ha un nome, chi lo esegue, una prova di vita e un interruttore. Perché una dashboard senza prove mente, e come ce ne siamo accorti.
AI · immagine generataUn'agenzia che costruisce i propri strumenti finisce, prima o poi, con molte cose che girano da sole. Da noi sono una cinquantina: lavori pianificati sul CRM e sui siti, script legati alla casella email, copie notturne di database, automazioni native dei vecchi strumenti, perfino attività programmate su un computer dell'ufficio. Ognuna, presa da sola, è semplice. Il problema è l'insieme: a un certo punto nessuno sa più dire, con certezza, quali stanno girando.
Questo articolo racconta come abbiamo risposto: un registro unico, in cui ogni processo autonomo ha una voce, e una regola che rende la pagina onesta.
Il registro, voce per voce
Ogni voce dichiara le stesse cose:
- un nome comprensibile a una persona, non il percorso tecnico;
- dove gira (il CRM, un sito, uno script, un'automazione nativa, un computer), perché questo decide chi lo può spegnere;
- la cadenza, scritta come la direbbe una persona: «ogni 15 minuti», «la notte alle 03:15»;
- entro quanto ci si aspetta il prossimo segno di vita;
- cosa fa e chi lo esegue, così quando si ferma si sa a chi chiedere;
- il rischio: può scrivere a un cliente? avvisa solo il team? tocca solo dati?
- la prova di vita, e soprattutto di che tipo è.
Quest'ultimo punto è la ragione per cui il registro esiste.
Cinque tipi di prova, perché una data non basta
All'inizio avevamo una pagina che metteva in verde o in rosso i processi guardando l'ultima data registrata. Uno risultava fermo da sette giorni: sembrava morto. Non lo era. Quella data non era il segno di vita del processo: era un registro, scritto solo quando c'era del lavoro da fare. Il processo girava tutte le notti e non aveva niente da scrivere.
Da lì abbiamo distinto cinque tipi di prova:
| Tipo | Quando si scrive | Se è vecchia vuol dire |
|---|---|---|
| battito | a ogni giro, anche a vuoto | è rotto |
| registro | solo se c'era qualcosa da fare | è normale |
| configurazione | solo se qualcuno la cambia | la data non dice niente |
| dato | si misura dal risultato prodotto | la prova è il lavoro fatto |
| nessuna | non lascia traccia | non è mai verde: «non misurabile» |
Senza questa distinzione una dashboard mente nel modo peggiore: accende allarmi rossi su sistemi sani, finché nessuno li guarda più. E quando poi si rompe qualcosa davvero, il rosso è uno fra tanti.
«Nessuna prova» non è una resa
L'ultima riga della tabella è la più utile. Alcuni processi oggi non si possono osservare: le attività pianificate su un computer (se il computer è spento non partono, e nessuno lo viene a sapere), le automazioni native di uno strumento esterno che non espone un registro leggibile, una copia che gira su un servizio di cui non leggiamo l'esito.
Dichiararli invisibili, invece di lasciarli fuori, ha due effetti. La pagina non li mostra mai in verde, quindi non promette niente che non può sapere. E l'elenco degli invisibili diventa la coda di lavoro per renderli visibili. Un processo che si dichiara invisibile è più utile di uno che si dichiara sano senza prove.
Quello che il registro ci ha fatto trovare
Censire tutto, sul codice in produzione e sui dati veri e non su quanto era scritto altrove, ha fatto emergere cose che nessuno stava guardando.
Un controllo che si era fermato da solo. Una procedura che rileggeva le classificazioni automatiche delle email per correggerle aveva lavorato su qualche migliaio di messaggi e poi si era fermata, a metà giugno. Nessuno se n'era accorto, perché nessuna spia lo diceva. Girava come sessione lanciata a mano e non lasciava traccia.
Un motore dormiente ma armato. Un vecchio script che classificava le email con un modello AI era fermo da mesi, ma la sua chiave era ancora al suo posto e il progetto esisteva. Bastava riaccendere un trigger perché si rimettesse in mezzo alla catena, prendendo le email nuove prima del motore giusto. Nessun errore, da nessuna parte: soltanto contatti che non nascono. Un registro che non lo elencava dichiarava sana una catena con un concorrente in attesa.
Due mail partite da sole. A luglio due messaggi sono usciti verso clienti mentre il pannello delle automazioni diceva che non ne partiva nessuno. Da quell'incidente è nato un interruttore generale, e ogni automazione che può scrivere a un cliente nasce spenta.
Un solo esecutore per automazione
Spostando le automazioni dal vecchio CRM al nuovo abbiamo adottato una regola rigida: ogni automazione ha un solo esecutore. La versione nuova nasce dietro un interruttore spento, mentre la gemella vecchia continua a girare. Il passaggio è un gesto doppio: si spegne di là e si accende di qua, nello stesso minuto. Finché non succede, il registro mostra la versione nuova come «spenta», ed è la verità. Due esecutori accesi insieme non danno un errore: producono due fotografie diverse dello stesso giorno, oppure due promemoria per la stessa cosa.
Chi controlla il controllore
Tutti gli allarmi del CRM dipendono da un unico processo che aggiorna le spie. Se si ferma lui, si fermano tutti gli allarmi, in silenzio. Per questo c'è una sentinella esterna, su un'altra infrastruttura, che ogni mezz'ora controlla una cosa sola: che quel processo abbia battuto di recente. Se tace, manda l'allarme sullo stesso canale delle spie. La sentinella lascia a sua volta un battito che le spie interne sorvegliano. Si guardano a vicenda.
Il cron che girava ma non esisteva
L'ultimo errore è di pochi giorni fa. Nel nuovo CRM ogni battito è legato al processo che lo emette: il database rifiuta il battito di un processo che non è registrato. Abbiamo messo in produzione un lavoro pianificato nuovo dimenticando la sua riga nel registro. Il lavoro girava regolarmente, ma il suo battito veniva rifiutato, con un avviso che si vedeva solo nei log. Per la spia di salute quel processo semplicemente non esisteva.
Il vincolo ha fatto il suo mestiere: invece di accettare un battito orfano, ha rifiutato. Ma un rifiuto che finisce solo in un log è ancora troppo silenzioso. Ce ne siamo accorti perché aspettavamo quella riga e non arrivava. Da allora la riga nel registro è parte dello stesso script che crea il lavoro, e dopo ogni pubblicazione si verifica che il primo battito sia arrivato davvero.
In sintesi
Non serve uno strumento di monitoraggio costoso per sapere se le proprie automazioni sono vive. Serve un elenco unico, scritto guardando cosa gira davvero; una distinzione onesta fra i tipi di prova; un interruttore per ogni processo; e l'abitudine di non fidarsi del verde quando nessuno può dimostrarlo.

