La domanda a cui nessuno risponde finché non sono le 23:40 di un venerdì
L'automazione funziona da otto mesi e nessuno è più tornato a parlarne. È esattamente quello che si era comprato. Il problema è che quel silenzio viene scambiato per la risposta a una domanda che non è mai stata fatta: se questa cosa si ferma, chi la prende in carico? E la domanda finisce per rispondersi da sola, male, la prima notte in cui il flusso degli ordini smette di creare bolle: qualcuno scrive nel gruppo WhatsApp del team, qualcun altro risponde alle sette del mattino, e per strada sono rimasti fermi quattordici ordini che nessuno sa ancora che esistono.
La reperibilità e il supporto delle automazioni sono la parte del giorno due che quasi nessuno compra, perché nella demo non si vede. Non è un servizio 24×7 con centralino. Sono quattro decisioni prese a freddo —cosa è grave, chi si chiama, cosa fa quella persona quando arriva e cosa si fa nel frattempo— scritte in un posto dove le trovi anche se non sei tu. Senza di loro il tuo piano di emergenza è la tua memoria, e la tua memoria ad agosto va in ferie.
Severità vere: cosa giustifica chiamare qualcuno e cosa aspetta domani
La prima decisione non è chi chiami: è quando si chiama qualcuno. Senza quella riga scritta succedono le due cose brutte insieme. O sembra tutto urgente —e il team impara a ignorare gli avvisi perché scattano per qualsiasi cosa— oppure niente lo sembra, e il guasto che costava soldi si scopre il lunedì.
Il settore delle operations risolve questa cosa da decenni con i livelli di severità, e la pratica consolidata è sensata: PagerDuty raccomanda di mappare ogni livello direttamente sulla politica di escalation e di avviso, e avverte che sei o sette livelli che nessuno sa distinguere producono paralisi da classificazione: fra tre e cinque è il punto giusto. In un'azienda che non ha un team di reperibilità, tre bastano e avanzano.
| Livello | Cosa significa a casa tua | Cosa si fa |
|---|---|---|
| Grave | Si stanno perdendo soldi o impegni con il cliente proprio adesso: non escono ordini, non si incassano fatture, non si risponde a nessuno. | Si avvisa subito la persona reperibile, a qualsiasi ora. Si attiva il piano manuale. |
| Fastidioso | Il processo funziona a metà o solo per una parte: un'integrazione ferma ma con via alternativa, un lotto non elaborato che si può rilanciare. | Si registra e si prende in carico alla prima ora del giorno lavorativo successivo. Di notte non si chiama nessuno. |
| Brutto ma può aspettare | Qualcosa non va e non ha conseguenze immediate: un report che non è stato generato, un campo che arriva vuoto in un posto che nessuno guarda fino alla chiusura del mese. | Entra nella coda di manutenzione della settimana. |
Il criterio che fa funzionare questa tabella non è tecnico, è di business: la severità la definisce il danno che fa ogni ora che passa, non quanto è rotto il sistema. Un flusso completamente morto che muove solo un report interno è «brutto ma può aspettare». Un flusso che funziona al 90% ma sta mandando preventivi con il prezzo sbagliato è grave. Scrivi la tabella con questa logica e con i nomi dei tuoi processi —«ordini web», «fatturazione», «avvisi ai clienti»— non con categorie astratte. Una severità che alle 23:40 va interpretata non serve a niente.
La reperibilità che sta dentro una piccola impresa (non copiare il modello di una big tech)
Qui è dove la maggior parte degli articoli diventa inutile: descrivono rotazioni settimanali, escalation a tre livelli e cercapersone. Tu hai due persone che sanno mettere le mani nei flussi e una delle due sei tu. La reperibilità realistica a quella scala ha quattro pezzi e nessuno costa soldi.
- Un nome a settimana, scritto. Non «il team», non «chi se ne accorge». Una persona precisa per settimana, su un calendario condiviso, con le settimane già distribuite fino a fine trimestre. Il valore non sta nella rotazione: sta nel fatto che alle 23:40 nessuno debba decidere chi disturbare.
- Un canale che interrompe davvero. L'email non sveglia nessuno e un canale Slack silenziato nemmeno. L'avviso di severità grave deve arrivare da qualcosa che suoni: una telefonata, un SMS, una notifica configurata come eccezione alla modalità «non disturbare». Il resto può passare dal canale di sempre.
- Un sostituto, e uno solo. Se la persona reperibile non risponde entro un tempo che decidi tu —quindici minuti è ragionevole—, si avvisa il sostituto. Niente catene a quattro livelli: in un'azienda di venti persone, il terzo livello è sempre la stessa persona.
- Una regola di compenso esplicita. Se qualcuno interviene su un guasto di sabato, quello si paga o si recupera. La reperibilità che sta in piedi sulla buona volontà dura esattamente fino alla seconda volta che qualcuno salta una cena.
E una decisione onesta prima di montare qualsiasi cosa: ti serve davvero la reperibilità notturna? Se i tuoi processi critici hanno conseguenze solo in orario d'ufficio —fatturazione, ordini B2B, avvisi interni—, la risposta giusta è non avere reperibilità di notte e dirlo ad alta voce, invece di reggere una reperibilità informale che nessuno ha accettato. Quello che ti serve sempre, invece, è che il guasto resti registrato e visibile alla prima ora. In n8n si monta con un unico flusso di errore collegato a tutti gli altri: la documentazione ufficiale descrive come un solo Error Workflow con nodo Error Trigger si riusi in tutti i flussi di produzione, senza costruire l'avviso uno per uno. Make e Zapier hanno i loro equivalenti.
Il runbook di una pagina: l'unica cosa che fa rispondere qualcun altro
La reperibilità senza runbook è un telefono che squilla per avvisare qualcuno che non può fare niente. Un runbook è la scheda di una pagina —una, non dodici— che trasforma «il flusso degli ordini è fermo» in una sequenza che può eseguire anche chi non l'ha costruito. PagerDuty lo dice senza fronzoli: gli incidenti ad alta severità devono puntare a un runbook, così chi risponde non improvvisa.
Uno per flusso critico. Non per flusso: per flusso critico, che in un'azienda normale sono fra tre e cinque. Ogni scheda risponde a sei domande e a nient'altro:
- Cosa fa questo flusso e cosa succede se è fermo. Due righe di business, non di tecnica. «Crea la bolla nell'ERP quando entra un ordine web. Se è fermo, gli ordini entrano ma non vengono preparati.»
- Come si verifica in trenta secondi se è vivo. Il link esatto allo storico delle esecuzioni, e cosa si guarda lì dentro.
- Le tre cause già successe in passato, e il loro rimedio. Credenziale scaduta, quota del fornitore esaurita, campo che arriva vuoto. Con il clic preciso, non con la teoria.
- Come si ferma del tutto. Il pulsante, l'interruttore, il posto. Fermare è un'azione legittima e molto spesso quella giusta: un flusso fermo fa meno danni di un flusso che decide male.
- Cosa si fa nel frattempo (il piano manuale, sezione successiva).
- A chi si scala se niente di tutto questo funziona, con nome e telefono.
Il runbook è un cugino stretto della documentazione del flusso, ma non è la stessa cosa e conviene non mescolarli: documentare le tue automazioni serve perché qualcuno possa mantenerle e modificarle con calma; il runbook serve per i quindici minuti successivi al blocco. Uno si legge da seduti, l'altro in piedi. Se pretendi che lo stesso documento faccia entrambe le cose, ti ritrovi con dodici pagine che alle 23:40 non apre nessuno.
Il piano manuale: continuare a fatturare a mano non è un fallimento, è il piano
Questo è il pezzo che più gente salta, ed è quello che salva più soldi. Mentre l'automazione è ferma, il business va avanti. Gli ordini continuano a entrare, i clienti continuano a scrivere e le fatture continuano a scadere. La domanda non è «quando lo aggiustiamo?», è «come continuiamo a operare finché non è aggiustato?».
C'è un riflesso culturale che qui dà fastidio: tornare al processo manuale si vive come una sconfitta, come ammettere che l'automazione non valeva niente. È il contrario. Un sistema serio ha una modalità degradata; quello che non ce l'ha non è più automatico, è più fragile. Scrivi, per ogni flusso critico, la versione a mano del processo: chi la esegue, dove annota quello che via via sta facendo e qual è il volume massimo che regge prima di dover iniziare a dire di no.
Quest'ultima parte è quella che quasi nessuno scrive ed è quella che decide tutto il resto: il piano manuale ha un tetto. Dodici ordini al giorno si inseriscono a mano; quattrocento no. Sapere il tuo numero in anticipo cambia la conversazione durante il blocco, perché trasforma «reggiamo» in «reggiamo fino alle due del pomeriggio, da lì smettiamo di accettare ordini web». E il registro parallelo di quello che è stato fatto a mano non è burocrazia: è quello che rende possibile la riconciliazione successiva senza duplicare niente, un lavoro con una sua meccanica precisa e sviluppato in recuperare i dati persi in un'automazione ferma.
Il postmortem di tre righe: perché senza di lui lo stesso blocco torna a marzo
L'incidente finisce, tutti tirano un respiro e nessuno scrive niente. Tre mesi dopo succede di nuovo la stessa identica cosa e la persona che l'aveva sistemato la prima volta non si ricorda più come. Questo è il costo vero di saltare il postmortem, e non si paga sul momento: si paga nella ripetizione.
Non serve il documento di dieci pagine di un'azienda da migliaia di persone. Il libro SRE di Google —dove è nata buona parte di questa pratica— insiste su due cose che scalano anche verso il basso: che sia senza colpevoli, concentrato sul perché il sistema ha permesso il guasto e non su chi lo ha commesso, e che si possa partire da una procedura molto elementare e affinarla strada facendo. Alla tua scala sono tre righe, scritte lo stesso giorno, nel posto dove vive il runbook:
- Cosa è successo e da quando. Con l'ora di inizio reale, non quella di rilevamento. La differenza fra le due è, quasi sempre, la scoperta più utile di tutto l'esercizio.
- Cosa lo ha sistemato. L'azione precisa. Questo va dritto nella sezione delle cause note del runbook, ed è quello che fa sì che la seconda volta duri dieci minuti invece di tre ore.
- Cosa abbiamo cambiato perché non torni. Una cosa sola, con un responsabile e una data. Se non ce n'è nessuna, scrivi anche quello: «accettiamo che possa ripetersi» è una decisione valida e consapevole; «poi vediamo» non lo è.
Quando quelle tre righe si accumulano per un anno, smetti di avere aneddoti e inizi ad avere una mappa: quale flusso si ferma più spesso, quale fornitore ti è costato più ore, quale rimedio hai applicato sei volte senza risolvere la causa. Quella mappa è ciò che trasforma la manutenzione reattiva in manutenzione vera, quella che anticipa.
Cosa montare questa settimana
Tutto quello che precede sta in un pomeriggio se lo fai in questo ordine e non provi a farlo perfetto: la tabella dei tre livelli di severità con i nomi dei tuoi processi; il calendario con un nome a settimana e un canale che suoni; il runbook di una pagina dei tuoi due flussi più critici; la versione manuale di quei due processi con il tetto scritto; e l'abitudine delle tre righe dopo ogni blocco. Niente di tutto questo richiede uno strumento nuovo. Richiede che qualcuno lo decida a freddo e lo lasci scritto dove si trova.
Il confine onesto: questo è pensato per chi ha qualche flusso e vuole dormire tranquillo senza montare un dipartimento. Quando sotto ci sono decine di processi, più team e agenti che decidono da soli, la risposta agli incidenti smette di essere una scheda e diventa una funzione con turni, accordi sui livelli di servizio e una sua meccanica di escalation: quella è la gestione degli incidenti degli agenti IA. E se quello che vuoi è che severità, reperibilità, runbook e piano manuale restino montati sui tuoi flussi attuali e gestiti da qualcuno che non sei tu, quella è l'automazione delle operazioni: il giorno due, fatto, invece di un'intenzione scritta su un tovagliolo.