Esercitazioni antincendio: strategie di comunicazione durante una crisi

Immaginatevi il peggio#section1

Il primo passo per un efficace piano di emergenza è anche quello più disagevole: dovete immaginare tutto quello che può andare storto, dalla cosa più probabile a quella meno dannosa, fino a quella rara e catastrofica. Radunate il vostro team e a turno costruite un elenco di disastri potenziali. Se avete già avuto a che fare con queste cose in passato, potete cominciare raccontando cosa è andato storto in quelle occasioni. Assicuratevi di non limitare la discussione solo a quello che è già accaduto: parlate anche di tutto quello che potrebbe accadere.

Generando queste idee, ricordatevi di considerare le sorgenti potenziali di disastro che si trovano sia sotto il vostro controllo sia fuori. Le dipendenze, come il fallimento di un hosting provider o un calo di corrente in ufficio, può avere tanto effetto sul vostro sito quanto un deploy errante o un baco. E se il vostro servizio si estende oltre il web, ad esempio, se siete un’autorità del trasporto locale, allora dovete considerare tutti i tipi di eventi che possono avere un effetto negativo sul sito. In questo esempio, disastri naturali, attività della polizia o incidenti che possono accadere. (Nota a margine: queste riunioni possono essere deprimenti. Fate girare dei muffin per tenere alto il morale del vostro team).

Una volta che avete una grande e lunga lista di incubi, organizzateli su due assi: dai più probabili a quelli meno probabili e dai più pericolosi ai meno dannosi. Mentre delineate il vostro piano di emergenza, dovreste prestare grande attenzione a qualsiasi evento che sia molto probabile o molto pericoloso. Analogamente, quelli che sono rari o poco dannosi dovrebbero ottenere minor attenzione. Adesso avete una lista con delle priorità, delle cose per cui dovete avere un piano.

Figura 1: Una mappa dei possibili disastri per una fantomatica autorità dei trasporti.

Infine, elaborate quante più circostanze attenuanti possibili per ciascuno di questi eventi. Non riuscirete ad immaginare tutte le circostanze possibili, dal momento che proprio la natura di un disastro lo rende difficilmente predicibile con un certo grado di sicurezza, ma potete fare delle ipotesi plausibili riguardo i tipi di cose che possono accadere, basandovi sull’esperienza passata e sulla vostra conoscenza del vostro servizio.

Ad esempio, in Typekit (dove sono Communications Director), una delle cose peggiori che possa accadere è che il nostro network di font sia giù. Tuttavia, un’interruzione totale è estremamente rara: è più probabile che ci sia un’interruzione in un posto particolare (dovuta a un problema locale con la nostra rete di distribuzione di contenuto). Comprendere quali siano queste potenziali circostanze ci permette di elaborare una comunicazione più efficace durante lo stesso evento. Così, se la nostra rete è giù in un certo posto, sappiamo di dover comunicare il disservizio, mentre rassicuriamo i nostri clienti che la rete è a posto in qualunque altro luogo.

Assegnate dei ruoli#section2

Avete ora identificato qualunque cosa potrebbe andare storta e avete di conseguenza assegnato una priorità a ciascun evento e avete mangiato tre muffin per arrivare alla fine della riunione. Adesso è ora di considerare cosa succede quando accade ciascuno di questi eventi.

Nel palazzo di Manhattan dove avevo l’ufficio, ciascun piano era assegnato a due fire marshal: inquilini volontari del palazzo che avevano dato la disponibilità a essere point men in caso di incendio. Il loro lavoro consisteva nell’assicurarsi che tutti fossero usciti, nel chiamare aiuto medico se necessario e nel dirigere il personale del servizio di emergenza nel punto giusto. Tutti gli altri potevano uscire tranquillamente dal palazzo sapendo che i fire marshal si sarebbero occupati di tutto.

Analogamente, il vostro piano di emergenza ha bisogno che assegniate dei ruoli ben definiti. Tutti hanno bisogno di sapere quali sono le loro responsabilità fin dall’inizio, così che il team possa lavorare efficacemente. In Typekit, abbiamo identificato tre ruoli chiave richiesti da ogni procedura di emergenza:

• Pompieri: i pompieri sono le persone responsabili di spegnere l’incendio. Devono prendersi cura di qualunque cosa sia rotta e ripararla in fretta. Nel nostro caso, si comincia con l’operations team, che può chiamare gli ingegneri nel caso servissero dei rinforzi.
• Communications team: il communications team è responsabile della comunicazione verso il mondo esterno all’azienda durante la crisi. Fanno dei post nello status blog, rispondono a domande su Twitter, prendono in carico le risposte dei ticket di supporto e così via. Prendono le decisioni riguardanti a chi comunicare e come, dall’inizio della crisi fino a che è risolta. Inoltre, hanno potere decisionale sulle comunicazioni di follow-up necessarie. Ad esempio, nel caso di un’interruzione grave, potrebbero decidere di fare una bozza di un dettagliato blog post che spieghi cosa è successo, così come i piani che abbiamo per impedire che accada di nuovo.
• Messaggero: il communications team ha bisogno di capire che lavoro stanno facendo i pompieri, ma i pompieri devono concentrarsi sul sistemare le cose piuttosto che sul rispondere alle domande. Ed ecco che entra in scena il messaggero, il cui lavoro consiste nel mantenere i contatti tra i pompieri ed il communications team, aggiornando quest’ultimo sui progressi dei primi. In Typekit, il messaggero è solitamente un ingegnere che origlia il lavoro dei pompieri, riportando le informazioni critiche al communications team e rispondendo alle loro domande. E’ importante che il messaggero abbia abbastanza familiarità con il lavoro dei pompieri in modo da comprenderle e poterlo tradurre efficacemente al communications team.

In una grande azienda, potete assegnare molte persone allo stesso ruolo, così che in caso di emergenza ci sia sempre qualcuno pronto ad agire. (Ricordatevi: il peggior disastro può capitare nei momenti meno opportuni.) In un piccolo team come quello di Typekit, potreste aver bisogno di persone a cui stia bene ricoprire diversi ruoli in diverse occasioni. Ad esempio, Typekit ha un’unica persona incaricata della comunicazione (la sottoscritta), ma in caso io non possa esserci durante l’emergenza, chiunque nell’azienda ha i mezzi per offrirsi volontario per ricoprire il mio ruolo. Similmente, ciascuno dei nostri ingegneri può essere chiamato a fare il pompiere o il messaggero.

Oltre a definire i ruoli, dovete considerare come farli lavorare assieme. Chi viene svegliato nel mezzo della notte quando qualcosa va male? Come li raggiungete? Cosa succede se non sono raggiungibili? Definite un sistema interno per radunare il vostro team in caso di emergenza ed assicuratevi che tutti comprendano cosa ci si aspetta da loro. I sistemi automatizzati come PagerDuty possono sollevarvi dal fare ipotesi ed assicurarvi che qualcuno sia disponibile nel momento del bisogno.

Analogamente, identificate le circostanze sotto le quali tutti in azienda hanno bisogno di essere informati di un’emergenza (sia che siano coinvolti nella sua risoluzione sia che non lo siano). Gli eventi che hanno dato il via alla creazione di un piano di emergenza a Typekit sono accaduti lo scorso dicembre, non molto prima della pausa invernale. Durante un sabato pomeriggio, quando la maggior parte del nostro team è impegnata con lo shopping natalizio, partì un thread via e-mail per condividere un simpatico video sulla tipografia. Pochi di noi stavano partecipando a quel thread, quando abbiamo cominciato a ricevere degli allarmi che riferivano che c’era qualcosa che non funzionava nella nostra rete di font. Abbiamo spostato la nostra attenzione per gestire il problema, continuando però a conversare nello stesso thread. Altri membri del team diedero una sbirciatina alle loro e-mail quel pomeriggio, diedero un’occhiata ad un thread molto lungo su un argomento apparentemente frivolo e proseguirono la loro giornata ignorando quello che stava accadendo. Ci volle quasi un’ora per realizzare la severità della crisi e chiamare le persone individualmente per farci aiutare. Questa cosa ci ha fatto perdere molto tempo (e quello dei nostri utenti) ed è anche risultata in messaggi mischiati dal momento che almeno un membro del nostro staff stava rispondendo ad un tweet preoccupato con delle informazioni inaccurate. Da quel momento, abbiamo implementato l’equivalente di un allarme antincendio in tutta l’azienda: abbiamo impostato un account Yammer così che qualunque post venga fatto su questo, venga mandato un messaggio SMS a tutte le persone dell’azienda. Quando viene identificato un evento importante, la prima cosa che facciamo è postarlo su Yammer per radunare le truppe.

Definite un protocollo#section3

Adesso che tutti sono al proprio posto, hanno bisogno di ordini. Durante una crisi c’è molta tensione: i vostri clienti potrebbero essere agitati o arrabbiati e il vostro team potrebbe essere molto sotto pressione per sistemare le cose. E’ molto importante non farsi assalire dal panico per nessuno di questi motivi, ma comunicare in maniera tale da rassicurare i vostri clienti che vi state prendendo cura delle cose.

Un protocollo definisce cosa comunicare, attraverso quali canali, così che il communications team non debba sprecare tempo per decidere come gestire un particolare evento. In Typekit, il nostro protocollo definisce le strategie di comunicazione a seconda della severità del problema (se affligge la critica rete dei font o il meno critico sito web), se abbiamo già identificato la causa e quanto ci vorrà prima che sia risolto. Dato ciascuno di questi fattori, ci suggerisce poi come comunicare su ciascuno dei nostri canali principali:

• il nostro status blog,
• il nostro Twitter feed,
• i support tickets,
• le liste e-mail dei nostri partners
• e il nostro blog.

Ad esempio, qualunque interruzione di uno qualsiasi dei nostri servizi ci obbliga a renderlo noto sullo status blog. Seguiranno dei post addizionali quando ne sapremo di più sul problema o quando saremo prossimi alla soluzione. Se non abbiamo una soluzione immediata, rispondiamo brevemente agli utenti su Twitter o attraverso il nostro canale di supporto che stiamo lavorando al problema e gli suggeriremo di seguire lo status blog per gli ultimi aggiornamenti. Gli eventi molto estesi o responsabili di disagi per un numero significativo di utenti daranno il via a dei tweet broadcast a tutti quelli che ci seguono. Infine, ciascun evento che va a colpire il sistema dei nostri partner potrebbe richiedere un’allerta via e-mail all’operations team di queste organizzazioni.

Il protocollo ha preso queste decisioni in anticipo, riducendo il carico cognitivo sul team incaricato di rispondere alla crisi durante l’emergenza. Chiunque sia chiamato a gestire le comunicazioni può rapidamente far riferimento al protocollo per determinare quando e dove dovrebbero rispondere. Non hanno bisogno di pensare a chi dovrebbe essere allertato o in che modo: devono semplicemente (e rapidamente) seguire il percorso che è già stato definito.

Assicuratevi di stabilire i vostri canali in maniera oculata: i canali esistenti come il vostro sistema di supporto o il vostro account Twitter sono quelli ovvi. I sistemi di notifica all’interno del vostro sito o della vostra applicazione sono un altro esempio. Se dovete comunicare quando il vostro sito o il vostro servizio sono giù, considerate uno status blog (ospitato su un sistema completamente separato, così che non sia giù nello stesso momento in cui lo è il vostro servizio). Se avete molti sistemi differenti, potrebbero richiedere dei canali unici. Potreste considerare anche adattamenti al vostro sito in caso di problemi: una barra di allarme che appare con le informazioni importanti, ad esempio, o una feature sulla vostra homepage.

Comunicate in maniera appropriata#section4

Ovviamente, sapere quando e dove rispondere non dice come farlo. Comunicare bene è, nelle migliori circostanze, una sfida e diventa sempre più difficile durante le emergenze. E’ importante fornire una guida su come redarre le comunicazioni durante la crisi, così che il vostro team abbia un supporto quando la pressione è alta.

Aiuta fare un passo indietro e ricordarsi per prima cosa perché si vuole comunicare durante una crisi. Tale comunicazione va intesa come risposta a tre obiettivi chiave:

• condividere i fatti di una situazione così che gli utenti capiscano cosa sta succedendo,
• dimostrare quello che si sta facendo per rispondere alla crisi,
• comprendere la frustrazione.

L’ultimo punto è importante: gli utenti saranno probabilmente infastiditi (o peggio) quando il vostro sito o servizio non è disponibile oppure con dei malfunzionamenti. Un buona comunicazione gli fa sapere che capite come si sentono, mostra che avete tutto sotto controllo e li rassicura che rimmarrete affidabili nonostante lo stato attuale delle cose. Il modo in cui comunicate con i vostri utenti durante questi eventi può avere più di un’influenza duratura su di loro rispetto a qualunque comunicato che annuncia una giornata di sole.

Perciò, tutte le comunicazioni durante la crisi dovrebbero:

• Essere tempestive, per mostrare che siete sul pezzo.
• Essere concise, nel senso di brevi ma comprensibili. Le comunicazioni durante la crisi dovrebbero essere compatte, dare molte informazioni in poco spazio e tempo.
• Essere il più trasparenti possibile. Forse di più di qualunque altro contenuto creiate, le comunicazioni durante la crisi devono essere oneste e chiare se volete che i vostri clienti abbiano fiducia che risolverete il problema.
• Articolate chiaramente quello che state facendo e, quando possibile, quanto tempo ci vorrà. Quest’ultimo potrebbe essere difficile da stimare, quindi non date un tempo se non ne siete sicuri, ma se sapete che non c’è una soluzione imminente, è meglio essere onesti con i propri utenti riguardo a ciò.
• Offrite delle scuse sincere. Indipendentemente dalla sorgente del problema, avete deluso i vostri utenti. Prendetene atto e poi rimettetevi al lavoro per far sì che non succeda di nuovo.

Dal momento che avete già fatto il duro lavoro per anticipare molte delle cose che possono andare male e le circostanze attorno a queste, potete usare tali scenari e principi per creare degli esempi di comunicazione ad uso e consumo del vostro team. In Typekit, abbiamo molti status update pronti all’uso per eventi che possono attaccare la nostra rete di font, così che tutti (anche il solitario ingegnere delle 3 di mattina) possano aggiornare lo status blog in un attimo con un post accurato, chiaro ed appropriato. In maniera simile, abbiamo delle linee guida per i tweet e per appropriate risposte di supporto, inclusi dei template che tutti nel nostro team possono utilizzare al bisogno.

Un pattern di comunicazione che trovo utile in queste comunicazioni può essere suddiviso in due parti: 1) cosa sta succedendo e 2) cosa stiamo facendo per risolverlo. Intendo dire che la prima parte di ogni affermazione di crisi dovrebbe identificare cosa sta succedendo: cosa si è rotto, come si è rotto, cosa significa per gli utenti e così via. La seconda parte dovrebbe affermare chiaramente cosa stiamo facendo per gestire la situazione. Tutto ciò rende la comunicazione più tranquillizzante dal momento che avete riconosciuto il problema, ma fa anche in modo che i vostri utenti sappiano che state lavorando per trovare una soluzione. Quindi, una frase del tipo “La rete dei font è giù a San Jose, stiamo lavorando con il nostro partner CDN per risolvere il problema” è efficace. Mentre una così: “Scusate, la rete dei font ci sta dando dei problemi in questo momento” non lo è. L’ultima fa apparire la cosa come se steste aspettando che il problema si risolva da solo piuttosto che prendervene carico.

Considerate inoltre di aggiungere una sezione alla vostra guida di stile che riporti come adattare il linguaggio ed il tono in caso di emergenza. Se il vostro stile solito è spiritoso e leggero, sarebbe meglio che lasciate perdere gli scherzi durante la crisi per comunicare che state prendendo seriamente la situazione. (Se non avete una guida di stile, la comunicazione della crisi è una buona scusa per cominciare ad averne una). Potreste anche considerare di interrompere le altre comunicazioni per dimostrare che siete concentrati sulla risoluzione del problema. Fermate i tweet o i blog post programmati perché potrebbero distrarre dal messaggio.

Infine, assicuratevi che tutte queste belle linee guida vengano usate mettendole nel punto giusto, così che il vostro team possa trovarle in un attimo. Una posizione centrale, l’intranet potrebbe essere un buon inizio. Se avete uno status blog o un altro sistema di gestione del contenuto, fornite dei link da questi alla documentazione. Ancora meglio, fornite una dashboard di emergenza con un URL facile da ricordare e che il vostro team possa visitare per trovare qualunque cosa di cui abbiano bisogno. In altre parole, tutti dovrebbero sapere dove sono gli estintori.

Figura 2: Lo schermo dell’admin dello status blog di Typekit ha dei reminder utili riguardanti lo scopo della comunicazione durante la crisi, dei link alla nostra guida di stile e i documenti di protocollo, e i template per gli status update.

Revisionate e modificate#section5

Dopo una crisi che ha avuto successo (e sì, ci sono cose così), versatevi un drink. Avete gestito bene un’emergenza, rapidamente e con una comunicazione accurata, diffondendo la tensione e allietando i vostri utenti con la vostra attenzione e cura dei loro bisogni. Bravi!

Ma aspettate: non avete finito. Nessuna crisi termina nel momento in cui il sito o il servizio tornano su. Adesso che non siete più in modalità emergenza, è ora che guardiate indietro a quello che è successo e a come potete migliorarlo.

Se state gestendo un servizio, probabilmente avete già familiarità con i post-mortem che seguono un calo di tensione. I post-mortem guardano quello che è successo durante un evento, ponendo domande difficili riguardanti il motivo per cui ciò è accaduto, se si sarebbe potuto prevenire o se lo si sarebbe potuto gestire meglio. E’ importante che la vostra strategia di comunicazione faccia parte di questo processo. Riguardate come ha funzionato il vostro piano di emergenza e misurate come sono andate le cose. Avete risposto abbastanza rapidamente? Se no, perché? La vostra comunicazione è stata efficace? I vostri utenti sono stati soddisfatti delle vostre risposte o la loro frustrazione è aumentata ancora di più?

Non aspettate un’emergenza per rivedere la vostra strategia di gestione della crisi. Programmate delle revisioni regolari (diciamo, ogni due mesi) per rivedere il piano con il vostro team e valutare se qualcosa deve essere aggiornato. E’ possibile che i vostri sistemi siano cambiati da quando avete messo in atto il vostro piano, che quindi non è più ottimizzato. Potreste esservi espansi in altri mercati e aver bisogno di espandere in maniera simile i canali su cui comunicate. Potrebbero esserci dei nuovi membri dello staff che portano una nuova prospettiva sulla gestione e che potrebbero avere domande sul processo che prima di allora non avevate preso in considerazione. Fate queste revisioni così come fareste delle esercitazioni antincendio periodiche: anche se pensate di sapere dove sono le uscite di emergenza, prendetevi un attimo per camminare lungo il corridoio con i vostri colleghi.

Rilassatevi#section6

Forse la parte più difficile di una crisi è il senso di non avere il controllo: tutti, da voi ai vostri utenti alle persone che lavorano per spegnere l’incendio, vi sentirete come se foste in balia di qualcuno o qualcosa di cui non potete completamente controllare il comportamento. Pianificare un’emergenza dà una sensazione di serenità durante un disastro che vi permette di lavorare efficacemente anche quando vi sentite come se l’universo stesse cospirando contro di voi. In maniera ugualmente importante, vi permette di condividere tale serenità con i vostri utenti, aiutandoli ad avere fiducia nelle vostre capacità.

Non sarete in grado di anticipare o pianificare qualunque disastro ma un po’ di pianificazione alla lunga paga. Ero in quel grattacielo di Manhattan il pomeriggio del 14 Agosto 2003, quando ci fu un blackout nell’intero Nord Est, che fece chiudere tutta New York (e altri sette stati, più gran parte dell’Ontario). Ci vollero diversi minuti per realizzare che il calo di tensione era diffuso e che la corrente non sarebbe tornata presto. Così, come ci era stato insegnato, ci dirigemmo verso le uscite di emergenza. Solo qui le cose non andarono secondo i piani: il sistema di backup che dava luce alle scale non funzionò, lasciandoci scendere nel buio totale. Alcune persone dei piani più alti fecero questa scoperta prima di noi ed improvvisarono unendo un po’ di puntatori laser e puntandoli sui gradini in modo che le persone avessero abbastanza luce per scendere piano piano le scale. La lezione? Un buon piano vi porterà fino al 90% della gestione della crisi, lasciano a voi (e ai vostri utenti) una buona posizione per improvvisare il restante 10%. Cosa ho imparato: nelle settimane seguenti al blackout, fu creato un nuovo piano per rimpiazzare il sistema di bakcup e per testarlo con la stessa tempistisca degli allrami antincendio, così che la prossima volta, durante un’emergenza, ci sarebbe stata una cosa in meno che non sarebbe funzionata. Non si discute.

Illustrazioni: {carlok}