Under ett avbrott bedömer kunderna dig på två saker: hur snabbt problemet åtgärdas och vad de får höra medan det pågår. Det första kan du inte alltid styra. Det andra ligger helt i dina händer, och det är den del som de flesta team improviserar.
Improvisation går snett på förutsägbara sätt. Ingen publicerar något på en timme eftersom alla håller på att lösa problemet. Tre personer publicerar tre olika versioner. Uppdateringen talar om ”en degradering i eu-west-klustret” och kunderna har ingen aning om huruvida det påverkar dem. Den här guiden ger dig en plan på en sida där du bestämmer sådant i förväg, och mallar att kopiera.
Planen på en sida
Skriv ner det här en gång, förvara det där den som har jouren hittar det och gå igenom det två gånger om året.
Roller
Incidentansvarig: äger incidenten, bestämmer allvarlighetsgrad och samordnar åtgärden.
Kommunikatör: skriver och publicerar alla uppdateringar som riktar sig till kunder. Inte samma person som den som löser problemet; att åtgärda och skriva samtidigt betyder att det ena blir lidande.
Support: besvarar inkommande frågor med en länk till statussidan och för vidare det som kunderna rapporterar.
I ett litet team har samma personer flera roller. Poängen är att bestämma vem som gör vad före avbrottet, inte under det. Kombinerar du det här med ett jourschema har de två första rollerna alltid ett namn.
Allvarlighetsgrader
Tre nivåer räcker för de flesta team:
Större: produkten, kassan eller inloggningen är nere eller oanvändbar för de flesta kunder. Uppdatera var 30:e minut.
Mindre: en funktion är trasig eller långsam, eller så påverkas en del av dina kunder. Uppdatera varje timme.
Underhåll: planerat arbete. Meddela i förväg och uppdatera när det börjar och slutar.
Kanaler
Statussida: alltid, för varje incident som märks för kunderna. Den är sanningskällan som de andra kanalerna länkar till.
Aviseringar till prenumeranter: e-post- och chattaviseringar från statussidan, så att kunderna slipper uppdatera sidan hela tiden.
Banner i appen: vid större incidenter, om din produkt har en.
Direktmejl: vid större incidenter som har drabbat nyckelkunder, och för den uppföljande sammanfattningen.
Sociala medier: vid större incidenter, med en länk till statussidan, inte en egen version av händelseförloppet.
Löften
Första uppdateringen inom 15 minuter från att ni känner till ett problem som märks för kunderna.
Varje uppdatering säger när nästa kommer.
Varje incident avslutas med en uppdatering om att den är löst.
Större incidenter får en kort skriftlig sammanfattning inom fem arbetsdagar.
Vad en bra uppdatering innehåller
Varje uppdatering, i varje skede, besvarar fyra frågor i den här ordningen:
Vad som påverkas, med kundernas egna ord: ”kassan”, ”mobilappen”, ”inloggningen”, inte det interna tjänstenamnet.
Vad de märker: fel, långsamhet, mejl som inte kommer fram.
Vad de kan göra, om något: en tillfällig lösning, eller ”du behöver inte göra något”.
När de får veta mer.
Det här ska du utelämna: gissningar om orsaken, interna namn och jargong, skuld på en namngiven leverantör eller kollega, och löften om när det är åtgärdat om du inte är säker. ”Vi räknar med att ha löst detta inom 30 minuter” är ett löfte som kunderna kommer att hålla dig till.
Mallar för varje skede
Byt ut delarna inom hakparentes. Håll tonen enkel och lugn.
Undersöker
Vi undersöker rapporter om [fel / långsam laddning] när [kunder försöker slutföra ett köp]. [Övriga delar av webbplatsen fungerar som vanligt.] Vi publicerar en uppdatering inom [30 minuter].
Identifierat
Vi har hittat orsaken: [ett problem hos vår betalleverantör / en felaktig uppdatering som vi släppte kl. 14:05]. [Kortbetalningar misslyckas; faktura och Swish påverkas inte.] Vi [rullar tillbaka uppdateringen / arbetar tillsammans med leverantören] och uppdaterar igen inom [30 minuter].
Övervakar
En åtgärd är på plats och [kassan] fungerar igen. Vi övervakar läget för att säkerställa att det förblir stabilt. [Beställningar som lades mellan 14:05 och 14:40 kan visas som väntande; de behandlas automatiskt.] Nästa uppdatering inom [en timme], eller tidigare om något förändras.
Löst
Den här incidenten är löst. Mellan [14:05 och 14:40 CET] [misslyckades kortbetalningar i kassan för de flesta kunder]. [Orsaken var en felaktig uppdatering, som vi har rullat tillbaka.] [Vi lägger till en kontroll så att den här typen av fel stoppar en release innan den når kunderna.] Vi ber om ursäkt för störningen.
Inget nytt ännu
Vi arbetar fortfarande med [felen i kassan]. Inget har ändrats sedan förra uppdateringen. Nästa uppdatering inom [30 minuter].
Den sista är viktigare än den ser ut. En statussida som inte har ändrats på en timme får kunderna att tro att ingen arbetar med problemet.
Mejl till drabbade kunder
Vid större incidenter som drabbar nyckelkunder är ett kort mejl efteråt värt mer än någon statussida. Skicka det från en person, inte från en no-reply-adress.
Ämne: Om dagens avbrott i kassan
Hej [namn]! Mellan 14:05 och 14:40 i dag misslyckades kortbetalningar i kassan för de flesta av våra kunder, även för dig. Orsaken var en felaktig uppdatering hos oss, som vi rullade tillbaka. [Beställningar som du lade under den tiden har nu behandlats.] Vi [lägger till en automatisk kontroll som stoppar den här typen av release]. Om du såg något som inte stämmer med det här, svara på det här mejlet så tittar jag på det personligen. [Namn, roll]
Sociala medier
Håll det kort och hänvisa till statussidan för detaljer:
Vi ser fel i kassan och arbetar med att lösa det. Uppdateringar här: [länk till statussidan]
Kassan fungerar igen. Tack för ert tålamod, och förlåt för besväret. Sammanfattning: [länk till statussidan]
Efter incidenten
Vid större incidenter publicerar du inom några dagar en kort sammanfattning på statussidan eller via mejl: vad som hände, hur länge, vilka som påverkades, vad som orsakade det och vad ni ändrar. Vår postmortem-mall täcker den interna genomgången som kommer först, och hur du gör om den till en version för kunderna.
Titta sedan på själva kommunikationen. Hur lång tid tog den första uppdateringen? Hölls de utlovade tiderna för uppdateringar? Fick supporten frågor som uppdateringarna borde ha besvarat? Förbättra planen, inte bara systemet.
Gör planen lätt att följa
En plan fungerar bara om den är snabbare att följa än att strunta i. Några saker gör skillnaden:
Få veta det före kunderna. Uptimecheck kontrollerar dina webbplatser och API:er så ofta som varje minut från Stockholm, London och New York, bekräftar varje fel från en andra plats och larmar den som har jouren, så att 15-minutersklockan börjar ticka när problemet uppstår, inte när det första supportärendet kommer in.
Färdiga mallar i verktyget. Statussidor i Uptimecheck erbjuder ett färdigt första utkast för varje skede (undersöker, identifierat, övervakar, löst) på sidans språk, och dina egna sparade mallar, där {components} fyller i de berörda delarna.
Avisera rätt personer. Prenumeranter följer hela sidan eller bara de komponenter de använder, via e-post, Slack, Microsoft Teams, Discord eller webhook, och bara de som följer de berörda komponenterna aviseras.
Meddela underhåll i förväg. Schemalagt underhåll visas på sidan och mejlas till prenumeranterna innan det börjar.
Vår guide till att skapa en statussida som kunderna litar på tar upp vad som ska finnas på själva sidan.
Checklista
Utse incidentansvarig, kommunikatör och support i förväg.
Kom överens om tre allvarlighetsgrader och hur ofta ni uppdaterar för var och en.
Använd statussidan som sanningskälla; andra kanaler länkar till den.
Publicera den första uppdateringen inom 15 minuter, även om allt du vet är att ni undersöker saken.
Svara på vad som påverkas, vad kunderna märker, vad de kan göra och när de får veta mer.
Ange tiden för nästa uppdatering, och håll den.
Avsluta varje incident med en uppdatering om att den är löst.
Skicka en kort sammanfattning efter större incidenter, och utvärdera kommunikationen lika väl som åtgärden.