Se l'automazione si rompe, chi la ripara e in quanto tempo?

Se si rompe, la ripara chi è indicato nel contratto, nel termine che quel contratto fissa: per un flusso critico, rilevamento in meno di 15 minuti e ripristino entro la stessa giornata lavorativa. Se non ci sono un nome e un termine per iscritto, la risposta reale è che non la ripara nessuno finché non si lamenta un cliente, e questo richiede giorni. Ogni automazione che dipende da un'API di terze parti —WhatsApp, Mercado Libre, Google Calendar, un fornitore di IA— prima o poi si rompe, e quasi mai per un errore del codice: si rompe perché è cambiato qualcosa all'esterno. Ciò che separa un incidente di 40 minuti da uno di tre giorni non è la qualità dello sviluppo, sono tre decisioni prese prima di firmare: chi riceve l'avviso, in quanto tempo viene rilevato il guasto e qual è il termine di ripristino garantito. Se il tuo contratto non dice queste tre cose, non hai assistenza: hai un numero di telefono.

Quasi nulla si rompe da solo: cambia qualcosa fuori e il tuo flusso lo scopre per ultimo

Queste sono le modalità di guasto che compaiono nell'operatività reale, con nome e cognome:

• Viene spenta la versione dell'API che stavi usando. Meta versiona la Graph API e ogni versione ha una vita utile di circa due anni; la data di spegnimento viene pubblicata con mesi di anticipo nel changelog per sviluppatori. Il giorno in cui arriva, le chiamate a quella versione smettono di rispondere. È il guasto più prevedibile che esista e anche uno dei più comuni, perché l'avviso arriva a chi amministra l'app di Meta, non al titolare dell'attività.
• Scade un token che nessuno sapeva scadesse. Il classico: qualcuno ha generato nel pannello di Meta il token temporaneo di 24 ore per fare una prova e quel token è rimasto incollato in produzione. La variante lenta è peggiore: il token dell'utente di sistema non scade con il tempo, ma è legato a un account. Se quell'account perde l'accesso al Business Manager, il token muore con lui.
• Se ne va la persona che ha autorizzato gli account. L'impiegata amministrativa ha collegato Google Calendar e la casella di posta con la propria utenza. Si dimette, il venerdì le viene disattivato l'account aziendale, e il lunedì il bot non riesce a leggere l'agenda né a inviare le conferme. Nessuno collega una cosa all'altra per giorni, perché nel ticket di disattivazione non c'è scritto che quell'utenza reggeva tre integrazioni.
• Viene ritirato il modello di IA. Il nome del modello è scritto nel nodo. Il giorno dello spegnimento, ogni messaggio restituisce un errore di modello inesistente. I fornitori avvisano con mesi di anticipo, ma l'avviso arriva via email all'account che ha creato la chiave API, che in molti casi è quello del fornitore e non il tuo. Se quel rapporto si è raffreddato, l'avviso lo legge una casella che nessuno apre.
• Cambia l'HTML di un sistema che non ha API. Il portale di un grossista, il pannello di un ente sanitario, l'extranet di un'assicurazione: quando non c'è un'API, il flusso legge lo schermo. Una riprogettazione, un campo che passa a caricarsi tramite JavaScript o un nuovo captcha, e il dato non si trova più. Non c'è preavviso né qualcuno a cui reclamare. Se una parte della tua operatività dipende dalla lettura di schermate altrui, metti in conto almeno una rottura all'anno e mettila a budget.
• Cambia il tuo stesso volume. Nessuno ha toccato nulla, ma sei passato da 400 a 1.400 conversazioni al mese e l'API inizia a restituire 429 (troppe richieste) nel picco delle 11. È il guasto più difficile da diagnosticare perché è intermittente: alle 16 funziona alla perfezione e il reclamo del cliente sembra un'esagerazione.

Monitoriamo 24/7 non significa nulla: pretendi questi quattro elementi

Il monitoraggio vero sono quattro cose concrete e verificabili. Se ne manca una, c'è una delle modalità di guasto qui sopra che nessuno vedrà finché non la vedrà un cliente.

Un avviso che scatti per assenza, non solo per errore. Se il flusso dei promemoria invia 40 messaggi ogni mattina alle 9, l'avviso utile non è "il nodo è fallito", è "alle 9:15 non è stato registrato nessun invio". Si realizza con un monitoraggio a segnale di vita: il flusso segnala che è stato eseguito e un servizio esterno (healthchecks.io, Better Stack, o un flusso testimone separato) grida se quel segnale non arriva. Senza questo, l'esecuzione che termina in verde senza aver fatto nulla non la rileva nessuno, ed è il guasto che costa di più.

Nuovi tentativi con attesa crescente, e solo per gli errori che lo meritano. Un 429 o un 503 sono temporanei: riprovare dopo 5 secondi, dopo 25 e dopo un minuto risolve la maggior parte dei casi senza che nessuno se ne accorga. Un 401 (credenziale non valida) o un 400 (dato malformato) non si risolvono riprovando; lì il nuovo tentativo moltiplica soltanto l'errore e su alcune piattaforme accelera il blocco. In n8n si tratta di due opzioni per nodo, Retry On Fail e Wait Between Tries, più un ramo che separi il tipo di errore. Chiedi se sono configurate: in n8n sono disattivate di default, quindi se nessuno le ha toccate nodo per nodo, non lo sono.

Idempotenza, perché riprovare non duplichi. È l'elemento che si salta più spesso e quello che genera gli incidenti più imbarazzanti con i clienti. Se il nuovo tentativo riesegue l'azione completa, la stessa persona riceve due messaggi WhatsApp, viene emessa due volte la stessa fattura o viene scalata due volte la giacenza. La soluzione costa poco: prima di eseguire, salvare l'identificativo di origine dell'evento —l'id del messaggio, il numero d'ordine, l'id dell'appuntamento— in una tabella con vincolo di unicità, e se esiste già, non eseguire. La domanda per il tuo fornitore è letterale: se lo stesso webhook arriva due volte, e arriva, perché le piattaforme rinviano quando non ricevono risposta in tempo, cosa succede?

Una coda degli errori che qualcuno guarda. Ciò che è fallito dopo tutti i tentativi non può morire in un log. Va in una tabella, un foglio di calcolo o un canale, con dati sufficienti per rielaborarlo quando la causa sarà risolta; n8n ha l'Error Workflow esattamente per questo. La differenza pratica: quando il token viene riautorizzato il martedì, i 63 messaggi del lunedì vengono rinviati in due minuti invece di perdersi per sempre.

Lo stesso incidente, con e senza quegli elementi

Scenario: e-commerce con 900 SKU che vende su Tiendanube e Mercado Libre —la piattaforma di negozi online e il marketplace dominanti in America Latina— con un flusso n8n che sincronizza le giacenze ogni 10 minuti. Un venerdì alle 19:40 viene invalidata la credenziale di Mercado Libre. Valore medio dell'ordine USD 62. I valori sono tipici per un piccolo e-commerce della regione, non risultati verificati di un'azienda specifica.

Senza monitoraggio. La sincronizzazione smette di funzionare e gli annunci di Mercado Libre continuano a mostrare la giacenza del venerdì pomeriggio. Viene rilevato il lunedì alle 9:30, quando arriva il terzo reclamo: 62 ore di guasto. Nel frattempo sono state vendute 11 unità che non esistevano più, da annullare dall'account del venditore. Costo diretto: USD 682 di vendite perse, più circa 3 ore della persona dell'assistenza a gestire annullamenti e rimborsi, più il colpo alla reputazione di venditore, che si calcola sulle vendite recenti e richiede mesi per essere recuperata. La riparazione tecnica sono 40 minuti di riautorizzazione. La riparazione non è mai la parte cara.

Con i quattro elementi. Due cicli falliti consecutivi (20 minuti) fanno scattare l'avviso. Il flusso entra in modalità sicura: invece di lasciare pubblicata una giacenza che non può più convalidare, congela gli annunci o li porta a zero. Alle 20:15 qualcuno riautorizza dal cellulare; se non c'è reperibilità, si riautorizza il lunedì alle 9 e nel frattempo non è stato venduto nulla che non esistesse. La coda degli errori rielabora le variazioni di giacenza in sospeso. Costo: 40 minuti di lavoro e qualche vendita non realizzata, che sono molto più economiche delle vendite annullate.

La decisione di progettazione che fa risparmiare più denaro è quella che quasi mai viene preventivata: definire cosa fa il sistema quando non riesce ad adempiere. Un bot che non riesce a consultare il prezzo deve dire "ti passo una persona", non inventare un numero né restare muto.

Le sei domande che distinguono un'assistenza reale da un numero di telefono

1. Quale avviso scatta, a chi arriva e in quanto tempo? Una buona risposta suona così: se alle 9:15 il lotto non è partito, entra una notifica nel canale di assistenza e, se dopo 30 minuti resta irrisolto, una email a te.
2. Qual è il tempo di risposta e quale quello di ripristino? Sono cose diverse e conviene chiederle per gravità: bot fermo, guasto parziale, dettaglio estetico. Una presa in carico entro 4 ore lavorative non è una soluzione entro 4 ore lavorative.
3. Cosa succede un sabato alle 22? La risposta onesta e accettabile è "non c'è reperibilità, si interviene il lunedì alle 9, salvo che tu contratti la reperibilità a parte". La risposta sospetta è "c'è sempre qualcuno".
4. Le modifiche di terze parti rientrano nel canone o vengono preventivate? Quando Meta spegnerà la versione dell'API o il fornitore ritirerà il modello, chi paga quella migrazione? È la clausola che muove più denaro e quella che quasi nessuno chiede.
5. Chi altro, oltre alla persona che l'ha costruito, può entrare domani? Se la risposta è un nome proprio, la tua automazione ha un unico punto di rottura ed è umano. Ciò che lo risolve sono la documentazione e le credenziali in un gestore condiviso, non la fiducia.
6. Qual è il piano manuale mentre è fermo? Il numero continua a ricevere messaggi. Che qualcuno possa rispondere a mano dalla casella condivisa —Chatwoot o quella che usi— trasforma una perdita in un fastidio.

Squalificano: "quello non si rompe", "è nel cloud", e qualsiasi SLA che parli soltanto di uptime del server. Che il VPS sia al 99,9% non dice nulla su se i tuoi messaggi sono partiti: il server può essere impeccabile con il token scaduto da una settimana.

La prova di guasto: chiedi che rompano il flusso davanti a te, al mese 1

La prova si fa in 20 minuti. Si revoca di proposito una credenziale in un ambiente di prova, oppure si spegne il nodo di invio, e si cronometrano tre cose: quanto tempo impiega ad arrivare l'avviso, a chi arriva e se gli eventi falliti sono rimasti da qualche parte per essere rielaborati. Se dopo 30 minuti non è arrivato nulla, il monitoraggio non esiste, qualunque cosa dica il contratto. È lo stesso gesto di premere il pulsante di prova del rilevatore di fumo: l'apparecchio appeso al soffitto non prova nulla, il segnale acustico sì. Chiederlo al mese 1 è gratis; scoprirlo al mese 8 costa l'intero incidente.

Quando non vale la spesa

Non tutti i flussi hanno bisogno di un monitoraggio a pagamento, e venderlo lo stesso significherebbe farti pagare del rumore:

• Se il flusso è interno e tollera un giorno. Consolidare il report mensile delle vendite in Looker Studio: se fallisce il giorno 1, viene eseguito il giorno 2 e non è successo nulla. Mettere un avviso su questo abitua il team a ignorare gli avvisi, il che è peggio che non averli.
• Se viene eseguito due volte all'anno. Una chiusura d'esercizio o un caricamento stagionale si copre meglio con una verifica prima di ogni esecuzione che con 12 mesi di monitoraggio.
• Se nessuno all'esterno se ne accorge prima di te. È la regola pratica: monitora ciò che, se fallisce, se ne accorge per primo un cliente, un paziente o un acquirente.
• Se hai già un reparto sistemi con reperibilità. Pagare una seconda reperibilità significa pagare due volte. Quello che conviene comprare è la conoscenza dello stack e la documentazione, non la disponibilità.

Cosa guardiamo per primo quando ci chiamano con un flusso già rotto

Prima, quali credenziali sono ancora attive e a nome di chi: un token legato a qualcuno che non lavora più lì si risolve diversamente da uno scaduto. Poi, quale versione di ciascuna API è scritta nel flusso e se quella versione ha già una data di spegnimento pubblicata. Con queste due risposte si capisce se quello che hai è un problema di 40 minuti o una ricostruzione.

Quella verifica è la revisione gratuita di 15 minuti, e in diversi casi si conclude con un "questo non serve monitorarlo: riautorizza il token, documenta chi è il proprietario di ogni account e vai avanti". Se vuoi farla sul tuo caso, scrivici a info@striqtech.com oppure prenota da striqtech.com.