Tijdens een storing beoordelen klanten je op twee dingen: hoe snel het probleem is opgelost, en wat ze horen terwijl eraan gewerkt wordt. Het eerste heb je niet altijd in de hand. Het tweede volledig, en juist dat is het deel waarin de meeste teams improviseren.
Improviseren gaat op voorspelbare manieren mis. Een uur lang plaatst niemand iets, omdat iedereen bezig is met het probleem. Drie mensen plaatsen drie verschillende versies. De update spreekt van “a degradation in the eu-west cluster” en klanten hebben geen idee of het hen raakt. Deze gids geeft je een plan van één pagina om die dingen vooraf te beslissen, en templates om te kopiëren.
Het plan van één pagina
Schrijf dit één keer op, bewaar het waar de persoon met dienst het kan vinden, en loop het twee keer per jaar na.
Rollen
Incidentleider: is eigenaar van het incident, bepaalt de ernst en coördineert de oplossing.
Communicator: schrijft en plaatst elke update voor klanten. Niet dezelfde persoon als degene die het probleem oplost; tegelijk oplossen en schrijven betekent dat een van beide eronder lijdt.
Support: beantwoordt binnenkomende vragen met een link naar de statuspagina, en geeft door wat klanten melden.
In een klein team dragen dezelfde mensen meerdere petten. Het gaat erom dat je vóór de storing beslist wie wat doet, niet tijdens. Combineer je dit met een on-call-rooster, dan hebben de eerste twee rollen altijd een naam.
Ernstniveaus
Voor de meeste teams zijn drie niveaus genoeg:
Groot: het product, de checkout of het inloggen is voor de meeste klanten down of onbruikbaar. Update elke 30 minuten.
Klein: één functie werkt niet of is traag, of een deel van je klanten is getroffen. Update elk uur.
Onderhoud: gepland werk. Kondig het vooraf aan en geef een update bij de start en het einde.
Kanalen
Statuspagina: altijd, bij elk incident dat klanten raakt. Het is de bron van waarheid waar de andere kanalen naar linken.
Meldingen voor abonnees: e-mail- en chatmeldingen vanuit de statuspagina, zodat klanten niet steeds hoeven te verversen.
Banner in de app: bij grote incidenten, als je product er een heeft.
Directe e-mail: bij grote incidenten die belangrijke accounts raakten, en voor de samenvatting achteraf.
Social media: bij grote incidenten, met een link naar de statuspagina, niet met een eigen versie van het verhaal.
Beloftes
Eerste update binnen 15 minuten nadat je weet van een probleem dat klanten raakt.
Elke update zegt wanneer de volgende komt.
Elk incident eindigt met een update dat het is opgelost.
Grote incidenten krijgen binnen vijf werkdagen een korte schriftelijke samenvatting.
Wat een goede update bevat
Elke update, in elke fase, beantwoordt vier vragen in deze volgorde:
Wat er getroffen is, in de woorden die klanten gebruiken: “afrekenen”, “de mobiele app”, “inloggen”, niet de interne naam van de service.
Wat ze merken: foutmeldingen, traagheid, e-mails die niet aankomen.
Wat ze kunnen doen, als dat er is: een workaround, of “je hoeft niets te doen”.
Wanneer ze meer horen.
Wat je weglaat: gissingen over de oorzaak, interne namen en jargon, de schuld bij een genoemde leverancier of collega leggen, en beloftes over wanneer het is opgelost, tenzij je het zeker weet. “We verwachten dit binnen 30 minuten op te lossen” is een belofte waar klanten je aan zullen houden.
Templates voor elke fase
Vervang de delen tussen haken. Houd de toon eenvoudig en rustig.
Investigating (onderzoek)
We onderzoeken meldingen van [foutmeldingen / trage laadtijden] wanneer [klanten proberen af te rekenen]. [Andere delen van de site werken normaal.] We plaatsen binnen [30 minuten] een update.
Identified (oorzaak gevonden)
We hebben de oorzaak gevonden: [een probleem bij onze betaalprovider / een foutieve update die we om 14:05 hebben uitgerold]. [Kaartbetalingen mislukken; facturen en Swish zijn niet getroffen.] We [draaien de update terug / werken samen met de provider] en geven binnen [30 minuten] een nieuwe update.
Monitoring (in de gaten houden)
Er is een oplossing doorgevoerd en [afrekenen] werkt weer. We houden het in de gaten om zeker te zijn dat het stabiel blijft. [Bestellingen die tussen 14:05 en 14:40 zijn geplaatst, kunnen als in behandeling worden getoond; ze worden automatisch verwerkt.] Volgende update binnen [een uur], of eerder als er iets verandert.
Resolved (opgelost)
Dit incident is opgelost. Tussen [14:05 en 14:40 CET] [mislukten kaartbetalingen bij het afrekenen voor de meeste klanten]. [De oorzaak was een foutieve update, die we hebben teruggedraaid.] [We voegen een controle toe zodat dit soort fouten een release tegenhoudt voordat die klanten bereikt.] Onze excuses voor de overlast.
Nog geen nieuws
We werken nog aan [de fouten bij het afrekenen]. Er is niets veranderd sinds de vorige update. Volgende update binnen [30 minuten].
Die laatste is belangrijker dan hij lijkt. Een statuspagina die al een uur niet is bijgewerkt, doet klanten denken dat niemand eraan werkt.
E-mail aan getroffen klanten
Bij grote incidenten die belangrijke accounts raken, is een korte e-mail na afloop meer waard dan welke statuspagina ook. Verstuur hem vanaf een persoon, niet vanaf een no-reply-adres.
Onderwerp: Over de storing bij het afrekenen van vandaag
Hoi [naam], vandaag tussen 14:05 en 14:40 mislukten kaartbetalingen bij het afrekenen voor de meeste van onze klanten, ook voor jou. De oorzaak was een foutieve update aan onze kant, die we hebben teruggedraaid. [Bestellingen die je in die periode hebt geplaatst, zijn inmiddels verwerkt.] We [voegen een automatische controle toe die dit soort releases tegenhoudt]. Zag je iets wat hier niet mee overeenkomt? Beantwoord deze e-mail, dan zoek ik het persoonlijk uit. [Naam, functie]
Social media
Houd het kort en verwijs voor details naar de statuspagina:
We zien fouten bij het afrekenen en werken eraan. Updates vind je hier: [link naar statuspagina]
Afrekenen werkt weer. Bedankt voor je geduld, en sorry voor het ongemak. Samenvatting: [link naar statuspagina]
Na het incident
Publiceer bij grote incidenten binnen een paar dagen een korte samenvatting op de statuspagina of per e-mail: wat er gebeurde, hoe lang, wie er getroffen was, wat de oorzaak was en wat je verandert. Onze postmortem-template behandelt de interne evaluatie die daaraan voorafgaat, en hoe je die omzet in een versie voor klanten.
Kijk daarna naar de communicatie zelf. Hoe lang duurde de eerste update? Werden de beloofde updatetijden gehaald? Kreeg support vragen die de updates hadden moeten beantwoorden? Verbeter het plan, niet alleen het systeem.
Maak het plan makkelijk te volgen
Een plan werkt alleen als volgen sneller gaat dan negeren. Een paar dingen maken het verschil:
Weet het eerder dan je klanten. Uptimecheck controleert je sites en API’s tot elke minuut vanuit Stockholm, Londen en New York, bevestigt elke fout vanaf een tweede locatie en waarschuwt de persoon met dienst. Zo begint de klok van 15 minuten te lopen wanneer het probleem begint, niet wanneer het eerste supportticket binnenkomt.
Templates klaar in de tool. Statuspagina’s van Uptimecheck bieden voor elke fase (investigating, identified, monitoring, resolved) een kant-en-klaar eerste concept in de taal van de pagina, plus je eigen opgeslagen templates, waarin {components} de getroffen onderdelen invult.
Informeer de juiste mensen. Abonnees volgen de hele pagina of alleen de onderdelen die ze gebruiken, via e-mail, Slack, Microsoft Teams, Discord of webhook, en alleen wie de getroffen onderdelen volgt, krijgt een melding.
Kondig onderhoud vooraf aan. Gepland onderhoud verschijnt op de pagina en wordt vóór de start naar abonnees gemaild.
Onze gids over een statuspagina maken die klanten vertrouwen behandelt wat je op de pagina zelf zet.
Checklist
Wijs vooraf de rollen incidentleider, communicator en support toe.
Spreek drie ernstniveaus af, elk met een eigen updatefrequentie.
Gebruik de statuspagina als bron van waarheid; andere kanalen linken ernaar.
Plaats de eerste update binnen 15 minuten, ook als je alleen weet dat je het onderzoekt.
Beantwoord wat er getroffen is, wat klanten merken, wat ze kunnen doen en wanneer ze meer horen.
Noem het tijdstip van de volgende update, en houd je eraan.
Sluit elk incident af met een update dat het is opgelost.
Stuur na grote incidenten een korte samenvatting, en evalueer zowel de communicatie als de oplossing.