Come creare una status page di cui i clienti si fidano davvero

La maggior parte delle status page esiste. Poche sono affidabili. Una pagina sempre verde durante un disservizio è peggio di nessuna pagina, perché insegna ai clienti a smettere di guardarla. Una status page affidabile ha quattro proprietà: è onesta su ciò che è rotto, è rapida nell'ammettere gli incidenti, delimita l'impatto con attenzione e risponde alla domanda «mi sta riguardando?» senza costringere chi legge a cercare. Questa guida spiega come progettarne una.

Cosa vogliono davvero i clienti da una status page

Due domande guidano ogni visita a una status page. I clienti vogliono sapere se ciò a cui tengono è rotto e se qualcuno se ne è accorto. Tutto il resto è decorazione.

Se la pagina risponde a entrambe le domande al primo sguardo, i clienti si fidano e smettono di chiamare il supporto. Se non risponde a nessuna delle due, ogni incidente produce cinque ticket di supporto extra e una lenta perdita di credibilità. Il design visivo conta meno della struttura di ciò che viene mostrato above the fold.

Le quattro proprietà di una pagina affidabile

Quattro proprietà distinguono una status page utile da una di vanità. Se le ottieni tutte e quattro, i clienti si fideranno della pagina durante un incidente reale.

• Onestà. Se qualcosa è rotto, viene mostrato come rotto. Se ancora non sai, la pagina dice in fase di indagine. Verde durante un vero incidente distrugge la fiducia per sempre.
• Rapidità. Gli incidenti vengono pubblicati entro pochi minuti dal rilevamento. Un aggiornamento di stato che ritarda di un'ora rispetto a un disservizio reale viene trattato come testo di marketing.
• Chiarezza dell'ambito. Il cliente può capire, in pochi secondi, se l'incidente riguarda ciò che usa. Regione, area di prodotto e gravità sono le tre dimensioni da etichettare.
• Linguaggio semplice. Gli aggiornamenti sono scritti nello stesso tono che useresti per spiegare l'incidente a un amico, non in prosa aziendale al passivo.

Aggiornamenti di incidente che funzionano

La maggior parte dei modelli di status page imposta per default un tono passivo e cauto. «Stiamo indagando sulle segnalazioni di latenza elevata». Questo si legge come un'evasione. Lo schema che genera fiducia è l'inverso: nomina cosa è rotto, nomina l'impatto sull'utente, nomina cosa stai facendo al riguardo.

Un buon primo aggiornamento si legge come: «I login stanno fallendo per circa il 30% dei clienti nelle regioni UE. Il failover del database è in corso, ETA 10 minuti». Una buona risoluzione si legge come: «I login sono ripristinati. La causa principale era uno script di failover bloccato. Abbiamo aggiunto un watchdog in modo che non possa più bloccarsi silenziosamente». Entrambi sono brevi. Entrambi nominano impatto, azione e follow-up.

Delimitare correttamente l'impatto

Una singola status page generale è l'astrazione sbagliata una volta che hai più di una linea di prodotto o regione. Al cliente con un deployment solo statunitense non interessa che la tua regione UE abbia latenza elevata.

• Suddividi la pagina per componente: API, dashboard, ingestione, fatturazione, ecc. Mostra lo stato per ogni componente, non un singolo indicatore globale.
• Aggiungi una dimensione di regione o ambiente dove applicabile. Indica esplicitamente la regione interessata durante gli incidenti.
• Mostra gli ultimi 90 giorni di incidenti sotto lo stato in tempo reale. La vista storica è ciò che i visitatori consultano per decidere se sei abbastanza affidabile su cui scommettere.
• Se lo offri, esponi un feed RSS o JSON in modo che i clienti interessati possano iscriversi con i propri strumenti.

Manutenzione programmata senza il silenzio

La manutenzione programmata è la parte più facile della pagina di stato da gestire correttamente e una delle più trascurate. Pubblica la finestra con 48 ore di anticipo, riassumi cosa sarà interessato e cosa no, e pubblica un follow-up confermando il completamento.

Tratta la manutenzione programmata con lo stesso tono degli aggiornamenti sugli incidenti. Indica la finestra. Indica i servizi interessati. Indica l'impatto. Un post di manutenzione chiaro previene un ticket di supporto. Uno vago ne crea una dozzina.

L'affidabilità della pagina di stato stessa

Ospita la pagina di stato in un'infrastruttura indipendente da quella principale. Se la tua pagina di stato restituisce lo stesso errore del database della tua dashboard durante un'interruzione del database, la pagina stessa diventa parte dell'incidente. Una pagina di stato che si carica da un provider separato, una regione separata o una CDN statica è quel piccolo accorgimento di disciplina architetturale che ripaga la prima volta che si verifica una vera interruzione. La maggior parte dei team lo scopre nel modo più duro.