Come gestire la comunicazione durante i tempi di inattività dell'applicazione?

Ultimamente ho avuto molte esperienze con i tempi di inattività delle applicazioni, sia dei fornitori che delle mie applicazioni. Questo mi ha fatto pensare e, nel migliore dei modi, posso cercare su Google non esiste davvero un modo valido o standard di gestire la comunicazione con i clienti durante gli incidenti di inattività.

L'ho visto gestito in molti modi dall'approccio "biasimiamo tutti tranne noi" all'approccio "abbiamo sbagliato e ci dispiace" .

Quindi le mie domande sono ... quando fallisci con un'app e causi tempi di inattività:

1. Ammetti immediatamente la colpa? (Dovresti, legalmente?)
2. Quante informazioni fornite al cliente riguardo a cosa è andato storto? ("Un problema" vs. "Un errore di sintassi del codice in una delle nostre query SQL")
3. Ritorni con un piano di prevenzione di follow-up o lo lasci semplicemente a "questo è stato risolto"?
4. Fornite aggiornamenti in tempo reale? Quante volte? Via Twitter o sito Web pubblico?

Altre buone pratiche per questo che hai trovato di successo?

Ecco cosa faccio:

• Indica chiaramente quali sono le conseguenze (in questo momento e nell'immediato futuro). Evidenziare le probabili conseguenze permanenti o la loro mancanza (perdita di dati, perdita di ore dei dipendenti).
• Mantieni il tono molto neutro. Non spendere energia per colpa / colpa. Idealmente ciò trasmette "Voglio darti informazioni ma la mia attenzione è necessaria anche altrove".
• La tua notifica verrà inoltrata a molte persone, assicurati che il tuo CEO capisca l'essenza nel primo paragrafo. Di solito fornisco un "sommario esecutivo". I dettagli tecnici possono fornire informazioni di base ad altre persone tecniche.
• Fornisci i dettagli di contatto (preferibilmente qualcuno che ha il tempo nel bel mezzo del tempo morto) per ulteriori domande e chiedi pazienza nella stessa frase (funziona spesso).
• Prometti aggiornamenti quando la situazione cambia.

Invia aggiornamenti quando ci sono buone notizie, prima dell'orario di chiusura dell'ufficio ("tutto il personale continuerà per tutta la notte" - contabilizzare i fusi orari se necessario) e di nuovo intorno all'orario di apertura dell'ufficio.

Quando il problema è risolto (per qualsiasi definizione di quella parola), invia:

• Un riassunto che include i tempi delle conseguenze
• Le azioni / modifiche intraprese a breve termine e pianificate per il futuro ("insegnamenti tratti"); basato su:
• Analisi tecnica delle cause alla radice

Mantieni le chiamate per colpa, colpa o linciaggio in mail separate, preferibilmente dopo un certo tempo di recupero.

Non impegnarti a nulla durante i tempi di inattività a meno che tu non sia davvero, davvero sicuro di poterlo consegnare. In qualche modo due situazioni "cattive notizie" separate sono peggiori di una lunga.

Preferisco utilizzare un supporto in cui viene inviata una notifica su ogni messaggio (posta, Twitter, ..)

La cosa più importante che ho trovato sia come fornitore di servizi che come utente del servizio è la responsabilità proattiva. Non è in grado di dire quello che dici, ma quando (quanto tempo) lo dici.

Se ti viene comunicato che un problema si è verificato ed è stato risolto (o in fase di elaborazione), è molto meglio che scoprire il problema da solo e provare a contattare il fornitore per capire cosa sta succedendo nel mondo. Aiuta anche con il gioco della colpa e consente di risparmiare molto tempo per la risoluzione dei problemi (siamo noi o sono loro?).

Per quanto riguarda i dettagli, trovo che dare un semplice riassunto di ciò che è accaduto sia utile a meno che gli utenti non richiedano specificamente ulteriori informazioni. Ci saranno alcune persone che vogliono sempre quanti più dettagli possono ottenere, ma la maggior parte delle persone vuole solo che le cose funzionino (anche se sono altamente tecniche).

Infine, essere in grado di spiegare quali passi hai fatto in modo che non accada di nuovo fanno molto per l'avviamento e la fiducia futuri.

Senza sapere molto di più sulla tua particolare app, su come è concesso in licenza, sul campo per cui fornisci i servizi, ecc .; è impossibile rispondere alle tue domande senza indovinare.

1. Possedere i propri errori è di solito il percorso. Consulta il tuo avvocato se il tuo campo è quello in cui si applicano molte leggi, SLA o contratti meticolosi.
2. È una linea sottile tra troppi e troppo piccoli dettagli. In generale, i dettagli sono sufficienti a far sì che un utente comune possa capire.
3. Se è un errore piccolo e risolto rapidamente; non soffermarti su di esso. Se è stato davvero un grosso problema, hai il controllo dei danni da fare.
4. Piccoli errori, avvisa quando è inattivo e quando è stato corretto. Grandi errori, avvisare quando sono state raggiunte le pietre miliari della soluzione.

Preferisco che i miei fornitori forniscano troppe informazioni sui tempi di inattività. Ma molte aziende semplicemente non possono o sono chiuse dagli avvocati. Consultare il proprio avvocato / assicurazione in caso di dubbi.