Hoe bouw je een statuspagina die klanten daadwerkelijk vertrouwen

De meeste statuspagina's bestaan. Slechts weinig worden vertrouwd. Een pagina die tijdens storingen altijd groen is, is erger dan geen pagina, omdat het klanten leert te stoppen met kijken. Een vertrouwde statuspagina heeft vier eigenschappen: ze is eerlijk over wat kapot is, ze is snel met het erkennen van incidenten, ze bakent de impact zorgvuldig af, en ze beantwoordt de vraag «heeft dit invloed op mij?» zonder dat de lezer moet zoeken. Deze gids beschrijft hoe je er een ontwerpt.

Wat klanten daadwerkelijk willen van een statuspagina

Twee vragen sturen elk bezoek aan een statuspagina. Klanten willen weten of datgene wat hen aangaat kapot is, en of iemand het heeft opgemerkt. Al het andere is versiering.

Als de pagina beide vragen in één oogopslag beantwoordt, vertrouwen klanten haar en stoppen ze met support bellen. Als ze geen van beide beantwoordt, levert elk incident vijf extra supporttickets op en een langzaam verlies van geloofwaardigheid. Het visuele ontwerp is minder belangrijk dan de structuur van wat boven de vouw wordt getoond.

De vier eigenschappen van een betrouwbare pagina

Vier eigenschappen onderscheiden een nuttige statuspagina van een prestige-pagina. Krijg alle vier goed en klanten zullen de pagina vertrouwen tijdens een echt incident.

• Eerlijkheid. Als er iets kapot is, wordt het als kapot weergegeven. Als je het nog niet weet, vermeldt de pagina dat er onderzoek loopt. Groen tijdens een echt incident vernietigt het vertrouwen voor altijd.
• Snelheid. Incidenten worden binnen enkele minuten na detectie geplaatst. Een statusupdate die een uur achterloopt op echte storingen wordt behandeld als marketingtekst.
• Duidelijkheid over scope. De klant kan binnen seconden zien of het incident invloed heeft op wat hij gebruikt. Regio, productgebied en ernst zijn de drie dimensies om te labelen.
• Heldere taal. Updates zijn geschreven in dezelfde stem die je zou gebruiken om het incident aan een vriend uit te leggen, niet in lijdende-vorm bedrijfsproza.

Incidentupdates die werken

De meeste statuspaginasjablonen vallen standaard terug op een passieve, voorzichtige toon. «We onderzoeken meldingen van verhoogde latentie.» Dit leest als afleiding. Het patroon dat vertrouwen opbouwt is het omgekeerde: benoem wat kapot is, benoem de impact op gebruikers, benoem wat je eraan doet.

Een goede eerste update leest als: «Inloggen mislukt voor ongeveer 30% van de klanten in EU-regio's. Onze database-failover is bezig, ETA 10 minuten.» Een goede oplossing leest als: «Inloggen is hersteld. De hoofdoorzaak was een vastgelopen failover-script. We hebben een watchdog toegevoegd zodat dit niet meer stilzwijgend kan vastlopen.» Beide zijn kort. Beide benoemen impact, actie en opvolging.

De impact correct afbakenen

Een enkele algemene statuspagina is de verkeerde abstractie zodra je meer dan één productlijn of regio hebt. De klant met een uitsluitend Amerikaanse implementatie geeft er niet om dat je EU-regio een verhoogde latentie heeft.

• Splits je pagina per component: de API, het dashboard, ingestie, facturatie, enzovoort. Toon status per component, geen enkele algemene indicator.
• Voeg een regio- of omgevingsdimensie toe waar van toepassing. Markeer de getroffen regio expliciet tijdens incidenten.
• Toon incidenten van de afgelopen 90 dagen onder de live status. De historische weergave is wat bezoekers raadplegen om te beslissen of je betrouwbaar genoeg bent om op in te zetten.
• Bied indien mogelijk een RSS- of JSON-feed aan, zodat klanten die het belangrijk vinden zich kunnen abonneren in hun eigen tooling.

Gepland onderhoud zonder de stilte

Gepland onderhoud is het makkelijkste deel van de statuspagina om goed te doen en een van de meest overgeslagen onderdelen. Plaats het venster 48 uur van tevoren, vat samen wat wel en niet beïnvloed wordt, en plaats een vervolgbericht ter bevestiging van de afronding.

Behandel gepland onderhoud met dezelfde toon als incidentupdates. Benoem het venster. Benoem de getroffen diensten. Benoem de impact. Een nette onderhoudspost voorkomt een supportticket. Een vage creëert er een tiental.

De betrouwbaarheid van de statuspagina zelf

Host de statuspagina ergens onafhankelijk van je hoofdinfrastructuur. Als je statuspagina dezelfde databasefout retourneert als je dashboard tijdens een databasestoring, wordt de pagina zelf onderdeel van het incident. Een statuspagina die laadt vanaf een aparte provider, een aparte regio of een statische CDN is het kleine beetje architectonische discipline dat zich uitbetaalt de eerste keer dat je een echte storing hebt. De meeste teams ontdekken dit op de harde manier.