Statusseite bei Störungen: Was sollten Ihre Kunden erfahren?

Eine nützliche Statusseite erklärt Kunden, was betroffen ist, was bekannt ist und wann die nächste Information zu erwarten ist. Sie sollte keine vermutete Ursache als Tatsache veröffentlichen und keine vollständige Wiederherstellung melden, nur weil eine Änderung eingespielt wurde. Vereinbaren Sie den Kommunikationsablauf ebenso sorgfältig wie die Seite selbst.

Dieser Leitfaden betrifft die Beauftragung einer öffentlichen Störungskommunikation für eine Website oder App. Er empfiehlt kein kostenpflichtiges Pflichtwerkzeug, verspricht keinen durchgängigen Support und ersetzt keine Regelung zur Meldung von Sicherheitsvorfällen. Diese Verantwortlichkeiten müssen gesondert geklärt werden.

Zuerst die Auswirkung auf Kunden beschreiben

Bei einer erfundenen Bestell-App hilft „Neue Bestellungen können derzeit nicht abgeschickt werden“ mehr als ein unerklärter Datenbankfehler. Klären Sie, ob bestehende Aufträge, Produktansichten und Mitarbeiterzugänge ebenfalls betroffen sind. Erklären Sie nicht den gesamten Dienst für ausgefallen, wenn nur eine Funktion nachweislich gestört ist.

Die Atlassian-Anleitung zum Anlegen eines Statuspage-Vorfalls sieht die Auswahl betroffener Komponenten vor. Nutzen Sie das als Produktbeispiel, um wenige verständliche Dienstbereiche festzulegen. Die Einteilung soll Kunden den Umfang erklären, nicht Ihre interne Infrastruktur offenlegen.

Benennen Sie, wer die Auswirkungen bestätigt und wer veröffentlicht. In einem kleinen Team kann das dieselbe Person sein. Eine Vertretung bleibt trotzdem nötig. Vertrauliche Kundendetails, interne Protokolle und unbelegte Schuldzuweisungen gehören nicht in öffentliche Meldungen.

Kenntnisstand und Wiederherstellung auseinanderhalten

Atlassian unterscheidet Investigating, Identified, Monitoring und Resolved. Bei Investigating sind Symptome sichtbar, die Ursache aber noch unbekannt. Identified bedeutet, dass die Ursache gefunden wurde und an einer Lösung gearbeitet wird. Monitoring beschreibt eine vermutete Behebung, während beobachtet wird, ob die Symptome nachlassen.

Daraus folgt eine wichtige Frage für Ihr Briefing: Welche Nachweise erlauben in Ihrem eigenen Ablauf den jeweiligen Statuswechsel? Eine eingespielte Änderung beweist nicht, dass alle betroffenen Kundenabläufe wieder funktionieren. Vereinbaren Sie eine zum Dienst passende Prüfung, bevor eine uneingeschränkte Entwarnung veröffentlicht wird.

Ergänzen Sie Statusnamen durch klare Sprache. Was können Kunden versuchen, was sollten sie vermeiden und muss ein früherer Versuch nachgeprüft werden? Empfehlen Sie kein wiederholtes Absenden, wenn die erste Bestellung oder Zahlung bereits erfolgreich gewesen sein könnte. Der richtige nächste Schritt braucht technische Bestätigung statt einer beruhigenden Standardfloskel.

Die nächste Meldung braucht eine verantwortliche Person

Vereinbaren Sie, wer den Vorfall pflegt und welchen Aktualisierungsrhythmus Ihre tatsächliche Betreuung leisten kann. Eine angekündigte nächste Meldung ist eine Kommunikationszusage, keine garantierte Reparaturzeit. Bleibt die Ursache unbekannt, sollte das offen benannt werden.

Zeigen Sie Zeit und Zeitzone verständlich an. Frühere Meldungen müssen als Vergangenheit erkennbar bleiben. War eine Aussage falsch, korrigieren Sie sie ausdrücklich, statt den Verlauf nachträglich so aussehen zu lassen, als sei er immer richtig gewesen.

Klären Sie außerdem, wie Kunden die Statusinformation erreichen, wenn die App selbst nicht zugänglich ist. Proben Sie diesen Weg isoliert. Ein Link innerhalb eines ausgefallenen Anmeldebereichs ist möglicherweise keine ausreichende Lösung.

Veröffentlichen heißt nicht automatisch benachrichtigen

Beim Anlegen eines Vorfalls fragt Atlassian ausdrücklich, ob Abonnenten benachrichtigt werden sollen. Laut Anleitung muss dafür mindestens eine betroffene Komponente angegeben sein. Das beschreibt dieses Produkt, nicht einen allgemeinen Automatismus, durch den jede Änderung sämtliche Kunden erreicht.

Bestimmen Sie Empfängerkreis und Freigabeschritt Ihrer eigenen Benachrichtigungen. Testmeldungen dürfen nur kontrollierte Testempfänger erreichen. Importieren Sie keine Kundenkontakte in Abonnentenlisten und aktivieren Sie keine externen Kanäle allein deshalb, weil eine Schnittstelle vorhanden ist.

Proben Sie zur Abnahme einen Teilausfall, eine unbekannte Ursache, eine beobachtete Behebung und die bestätigte Rückkehr zum Normalbetrieb. Prüfen Sie öffentlichen Umfang, Zeitangaben, Ersatz-Zugangsweg und Testbenachrichtigung getrennt. Nehmen Sie diese Probe in die Übergabe Ihrer Website oder App auf. Das Ergebnis ist ein ehrlicher Informationsweg durch eine Störung, nicht nur eine grüne Statusanzeige.