Durante un’interruzione del servizio, i clienti ti giudicano su due cose: quanto velocemente risolvi il problema e cosa sentono dire mentre lo risolvi. La prima non sempre dipende da te. La seconda dipende interamente da te, ed è la parte che la maggior parte dei team improvvisa.
Quando si improvvisa, le cose vanno storte in modi prevedibili. Per un’ora nessuno pubblica nulla perché sono tutti impegnati a risolvere il problema. Tre persone pubblicano tre versioni diverse. L’aggiornamento parla di “un degrado nel cluster eu-west” e i clienti non hanno idea se li riguardi. Questa guida ti dà un piano di una pagina per decidere queste cose in anticipo e dei template da copiare.
Il piano di una pagina
Mettilo per iscritto una volta, tienilo dove la persona di reperibilità può trovarlo e rivedilo due volte all’anno.
Ruoli
Responsabile dell’incidente: ha la responsabilità dell’incidente, decide la gravità e coordina la risoluzione.
Addetto alla comunicazione: scrive e pubblica ogni aggiornamento rivolto ai clienti. Non è la stessa persona che risolve il problema: chi risolve e scrive allo stesso tempo finisce per fare male una delle due cose.
Supporto: risponde alle domande in arrivo con un link alla pagina di stato e riferisce ciò che segnalano i clienti.
In un team piccolo, le stesse persone ricoprono più ruoli. L’importante è decidere chi fa cosa prima dell’interruzione, non durante. Abbinando il piano a un calendario di reperibilità, i primi due ruoli hanno sempre un nome.
Livelli di gravità
Per la maggior parte dei team bastano tre livelli:
Grave: il prodotto, il checkout o il login sono down o inutilizzabili per la maggior parte dei clienti. Aggiornamento ogni 30 minuti.
Minore: una funzione è rotta o lenta, oppure è coinvolta una parte dei clienti. Aggiornamento ogni ora.
Manutenzione: lavori pianificati. Annunciali in anticipo e aggiorna quando iniziano e quando finiscono.
Canali
Pagina di stato: sempre, per ogni incidente che tocca i clienti. È la fonte di riferimento a cui rimandano gli altri canali.
Notifiche agli iscritti: notifiche via email e chat dalla pagina di stato, così i clienti non devono continuare ad aggiornarla.
Banner nell’app: per gli incidenti gravi, se il tuo prodotto ne ha uno.
Email diretta: per gli incidenti gravi che hanno colpito i clienti principali e per il riepilogo successivo.
Social media: per gli incidenti gravi, con un link alla pagina di stato, non con una versione diversa dei fatti.
Impegni
Primo aggiornamento entro 15 minuti da quando vieni a sapere di un problema che tocca i clienti.
Ogni aggiornamento dice quando arriverà il prossimo.
Ogni incidente si chiude con un aggiornamento di risoluzione.
Gli incidenti gravi ricevono un breve riepilogo scritto entro cinque giorni lavorativi.
Cosa contiene un buon aggiornamento
Ogni aggiornamento, in ogni fase, risponde a quattro domande in quest’ordine:
Cosa è coinvolto, con le parole che usano i clienti: “il checkout”, “l’app mobile”, “l’accesso”, non il nome interno del servizio.
Cosa notano: errori, lentezza, email che non arrivano.
Cosa possono fare, se c’è qualcosa da fare: una soluzione alternativa, oppure “non è richiesta alcuna azione”.
Quando avranno nuove informazioni.
Cose da lasciare fuori: ipotesi sulla causa, nomi interni e gergo tecnico, colpe attribuite a un fornitore o a un collega con nome e cognome, e promesse sui tempi di risoluzione se non ne sei certo. “Prevediamo di risolvere entro 30 minuti” è una promessa su cui i clienti ti terranno al punto.
Template per ogni fase
Sostituisci le parti tra parentesi quadre. Mantieni un tono semplice e calmo.
Investigating
Stiamo verificando delle segnalazioni di [errori / caricamenti lenti] quando [i clienti cercano di completare l’acquisto]. [Le altre parti del sito funzionano normalmente.] Pubblicheremo un aggiornamento entro [30 minuti].
Identified
Abbiamo individuato la causa: [un problema del nostro fornitore di pagamenti / un aggiornamento difettoso che abbiamo rilasciato alle 14:05]. [I pagamenti con carta non vanno a buon fine; fatture e Swish non sono coinvolti.] Stiamo [annullando l’aggiornamento / lavorando con il fornitore] e pubblicheremo un nuovo aggiornamento entro [30 minuti].
Monitoring
È stata applicata una correzione e [il checkout] funziona di nuovo. Stiamo monitorando la situazione per assicurarci che resti stabile. [Gli ordini effettuati tra le 14:05 e le 14:40 potrebbero risultare in sospeso; verranno elaborati automaticamente.] Prossimo aggiornamento entro [un’ora], o prima se cambia qualcosa.
Resolved
L’incidente è risolto. Tra [le 14:05 e le 14:40 CET], [i pagamenti con carta al checkout non sono andati a buon fine per la maggior parte dei clienti]. [La causa era un aggiornamento difettoso, che abbiamo annullato.] [Stiamo aggiungendo un controllo perché questo tipo di errore blocchi un rilascio prima che arrivi ai clienti.] Ci scusiamo per il disagio.
Nessuna novità
Stiamo ancora lavorando su [gli errori al checkout]. Non ci sono novità rispetto all’ultimo aggiornamento. Prossimo aggiornamento entro [30 minuti].
Quest’ultimo conta più di quanto sembri. Una pagina di stato ferma da un’ora fa pensare ai clienti che nessuno ci stia lavorando.
Email ai clienti coinvolti
Per gli incidenti gravi che colpiscono i clienti principali, una breve email dopo l’incidente vale più di qualsiasi pagina di stato. Inviala a nome di una persona, non da un indirizzo no-reply.
Oggetto: Il problema al checkout di oggi
Ciao [nome], oggi tra le 14:05 e le 14:40 i pagamenti con carta al checkout non sono andati a buon fine per la maggior parte dei nostri clienti, te compreso. La causa era un aggiornamento difettoso da parte nostra, che abbiamo annullato. [Gli ordini che hai effettuato in quella fascia oraria sono stati elaborati.] Stiamo [aggiungendo un controllo automatico che blocca questo tipo di rilascio]. Se hai notato qualcosa che non corrisponde a quanto descritto, rispondi a questa email e me ne occuperò personalmente. [Nome, ruolo]
Social media
Sii breve e rimanda alla pagina di stato per i dettagli:
Stiamo riscontrando errori al checkout e ci stiamo lavorando. Aggiornamenti qui: [link alla pagina di stato]
Il checkout funziona di nuovo. Grazie per la pazienza e scusate il disagio. Riepilogo: [link alla pagina di stato]
Dopo l’incidente
Per gli incidenti gravi, pubblica entro pochi giorni un breve riepilogo sulla pagina di stato o via email: cosa è successo, per quanto tempo, chi è stato coinvolto, qual è stata la causa e cosa stai cambiando. Il nostro template di postmortem copre l’analisi interna che viene prima e spiega come trasformarla in una versione per i clienti.
Poi analizza la comunicazione stessa. Quanto ci è voluto per il primo aggiornamento? Gli orari promessi per gli aggiornamenti sono stati rispettati? Il supporto ha ricevuto domande a cui gli aggiornamenti avrebbero dovuto rispondere? Correggi il piano, non solo il sistema.
Rendi il piano facile da seguire
Un piano funziona solo se seguirlo è più veloce che ignorarlo. Alcuni accorgimenti fanno la differenza:
Sappilo prima dei clienti. Uptimecheck controlla i tuoi siti e le tue API fino a ogni minuto da Stoccolma, Londra e New York, conferma ogni errore da una seconda località e avvisa la persona di reperibilità, così il conto alla rovescia dei 15 minuti parte quando inizia il problema, non quando arriva il primo ticket al supporto.
Template pronti nello strumento. Le pagine di stato di Uptimecheck offrono una prima bozza pronta per ogni fase (investigating, identified, monitoring, resolved) nella lingua della pagina, oltre ai tuoi template salvati, in cui {components} inserisce le parti coinvolte.
Avvisa le persone giuste. Gli iscritti seguono l’intera pagina o solo i componenti che usano, via email, Slack, Microsoft Teams, Discord o webhook, e ricevono la notifica solo quelli che seguono i componenti coinvolti.
Annuncia la manutenzione in anticipo. La manutenzione programmata compare sulla pagina e viene inviata via email agli iscritti prima che inizi.
La nostra guida su come creare una pagina di stato di cui i clienti si fidano spiega cosa mettere sulla pagina stessa.
Checklist
Assegna in anticipo i ruoli di responsabile dell’incidente, addetto alla comunicazione e supporto.
Concorda tre livelli di gravità e una cadenza di aggiornamento per ciascuno.
Usa la pagina di stato come fonte di riferimento; gli altri canali rimandano a essa.
Pubblica il primo aggiornamento entro 15 minuti, anche se sai soltanto che stai verificando.
Spiega cosa è coinvolto, cosa notano i clienti, cosa possono fare e quando avranno nuove informazioni.
Indica l’orario del prossimo aggiornamento e rispettalo.
Chiudi ogni incidente con un aggiornamento di risoluzione.
Invia un breve riepilogo dopo gli incidenti gravi e analizza la comunicazione oltre alla correzione.