Venerdì, 16:43. Un cliente chiama per un appuntamento lunedì. L’assistente capisce tutto, ma l’API del calendario va in timeout. Secondo tentativo, altro timeout. La risposta peggiore sarebbe: «Confermato» sperando che il write venga recuperato più tardi.
La seconda peggiore sarebbe perdere la richiesta.
Tra questi due estremi c’è la modalità degradata: meno funzioni, ma comportamento utile e onesto. Il sistema raccoglie contatto e orario desiderato, non promette disponibilità, crea un job visibile e comunica che la conferma arriverà dopo.
Pattern di resilienza come circuit breaker e health monitoring servono da anni a gestire dipendenze instabili. Una PMI non deve costruire una piattaforma enterprise; deve però sapere quali funzioni sono ancora sicure quando una dipendenza cade.
La modalità degradata parte da una matrice di funzioni
“API down” non basta. Il modello può essere disponibile mentre il CRM è in errore. Il calendario può rispondere in lettura e fallire in scrittura. Un provider di pagamento può essere giù mentre il customer service funziona.
Definite tre stati: normal, degraded, stopped.
In normal mode l’agente esegue il workflow previsto. In degraded mode mantiene ciò che non richiede stato live o commit: intake, informazioni stabili, richiesta di richiamata, queue. Prenotazioni definitive, pagamenti e altre azioni dipendenti dalla fonte non disponibile si fermano.
Stopped mode entra quando neppure raccolta e instradamento sono affidabili. A quel punto serve il canale umano.
Fatto confermato: circuit breaker e health check sono pattern usati per rilevare dipendenze non sane e ridurre errori a cascata.
Raccomandazione: definire in anticipo il comportamento business ridotto, non improvvisarlo durante l’incidente.
“Probabilmente” non è uno stato valido
I sistemi conversazionali tendono a continuare. In presenza di integrazioni rotte, la disponibilità a “essere utili” può diventare una falsa promessa.
Se il calendario non risponde, il modello non deve dedurre che le 10 siano probabilmente libere. Se la scrittura CRM fallisce, non si mostra “cliente creato”. Se il pagamento non dà conferma, lo stato resta non verificato.
Le regole di degraded mode devono quindi dire anche cosa non si fa: nessuna conferma live senza fonte live; nessun success dopo write non confermato; nessun retry cieco quando non sappiamo se la prima transazione sia stata eseguita.
Esempio hotel: il PMS è indisponibile. L’assistente raccoglie date, persone, camera desiderata e contatti. Non conferma disponibilità e tariffa finale se dipendono dal PMS.
La queue è la memoria operativa
Un job differito dovrebbe avere ID, timestamp, azione richiesta, cliente, causa del rinvio e owner. Al cliente viene comunicato «richiesta registrata, conferma in sospeso», non «fatto».
Quando il servizio torna, evitare il replay automatico dell’intera coda. Durante l’outage il personale potrebbe aver risolto alcuni casi manualmente; il cliente potrebbe aver richiamato.
La recovery dovrebbe essere:
- Verificare che la dipendenza sia realmente stabile.
- Riaprire lentamente il traffico nuovo.
- Ordinare la coda per urgenza ed età.
- Controllare lo stato target prima di ogni replay.
- Segnalare i job vecchi che richiedono una nuova conferma.
- Passare le eccezioni a un owner umano.
È il punto in cui resilienza e reconciliation si incontrano.
Dire la verità al cliente è parte della resilienza
Un errore 503 interessa al tecnico. Il cliente vuole sapere se l’appuntamento è davvero fissato.
La frase utile è semplice: «Il nostro sistema di prenotazione non è momentaneamente disponibile. Posso raccogliere la sua preferenza e le confermeremo l’appuntamento appena il collegamento sarà ripristinato.»
Non serve spiegare l’infrastruttura. Serve evitare ambiguità sullo stato.
I casi urgenti devono inoltre uscire dalla queue tecnica. Emergenza artigiana, ospite in arrivo la sera stessa o cliente già presente richiedono un passaggio umano più rapido. L’urgenza business è un segnale diverso dalla health dell’API.
Il pilota minimo: spegnere apposta una dipendenza
In test, rendete indisponibile un servizio. Guardate cosa dice l’agente, quali tool call tenta, come crea i job e cosa succede al restart.
Misurate tempo di rilevazione del guasto, richieste raccolte correttamente in degraded mode, falsi success state, età della queue fino alla risoluzione, job completati dopo recovery senza duplicazioni e tempo di handover dei casi urgenti.
Il successo non è disponibilità automatica al 100%. A volte la risposta più robusta è rifiutare deliberatamente una funzione che non può più essere verificata.
un agente affidabile sa anche essere meno capace. La modalità degradata ideale per una PMI conserva il contatto, non inventa conferme e rende visibile ogni attività da completare.
La coda di degraded mode deve inoltre essere abbastanza ricca da poter essere ripresa senza indovinare. Per ogni job conservate almeno intenzione, dati già validati, target, timestamp, stato di conferma al cliente e chiave di deduplica. Se manca uno di questi elementi, al recovery il sistema rischia di eseguire qualcosa che il cliente non considera più valido.
Definite anche una finestra di validità. Una richiesta di callback può restare utile per ore; uno slot desiderato per “oggi alle 14” no. Quando il servizio torna, i job scaduti non vanno eseguiti automaticamente: vengono ricontrollati o passati a una persona. Il recovery è parte del workflow, non una semplice riaccensione dei worker.
Alla ripresa non reinviate tutto alla cieca. Controllate se l'azione può essere riuscita nonostante il timeout. Qui si incontrano protezione dai doppioni e riconciliazione.
Fonti
FAQ
Degraded mode significa semplicemente retry?
No. Il retry è una tecnica. Il degraded mode decide quali funzioni business restano consentite.
Si può confermare un appuntamento “provvisorio”?
Solo se esiste un vero meccanismo separato che evita conflitti. Altrimenti si raccoglie la preferenza.
La queue va eseguita tutta appena torna l’API?
No. Prima va confrontata con lo stato reale, perché persone o clienti potrebbero essere intervenuti.
Serve health monitoring a una piccola PMI?
Per le dipendenze critiche almeno un controllo semplice di disponibilità ed errori è consigliabile.
Quando passare subito a una persona?
Quando urgenza, sicurezza o impatto rendono irragionevole aspettare la recovery automatica.