Zum Inhalt springen
← Impulse

Was Sie bei einer digitalen Störung kommunizieren sollten: klar informieren, ohne zu spekulieren

Dieser Leitfaden zeigt, wann Sie informieren sollten, welche Angaben hilfreich sind und wie Sie Nutzer bei einer Störung auf dem Laufenden halten, ohne interne Vermutungen als Fakten darzustellen.

Team stimmt eine Statusmeldung ab, um Nutzer während einer digitalen Störung zu informieren

Wenn eine Website, eine App oder eine Integration ausfällt, ist das Problem nicht nur technischer Art. Nutzer können möglicherweise keinen Kauf abschließen, Informationen abrufen oder eine benötigte Funktion verwenden. In diesem Moment ist eine klare Kommunikation Teil der Störungsbehebung: Sie macht die Auswirkungen verständlicher, verringert Unsicherheit und hilft dabei, eine Alternative zu wählen, sofern es eine gibt.

Zu kommunizieren bedeutet nicht, jeden Verdacht des Teams zu veröffentlichen oder auf die Kenntnis der Ursache zu warten. Es bedeutet, den bekannten Zustand des Dienstes zu erläutern und die Informationen zu aktualisieren, wenn sich die Lage ändert. Dieser Leitfaden bietet Kriterien dafür, wann Sie informieren, welche Angaben Sie aufnehmen, wer die Mitteilung verantwortet und wie Sie den Vorfall abschließen, ohne mehr zu versprechen, als sich bestätigen lässt.

Kommunikation ist Teil der Störungsbehebung

Kommunikation ist Teil der Störungsbehebung

Eine Störung kann technisch teilweise behoben sein und bei den Nutzern dennoch für Verwirrung sorgen. Ebenso kann es noch keine Lösung geben, während eine wichtige Aufgabe bereits beeinträchtigt ist. In beiden Fällen lässt Schweigen die Betroffenen ohne Einordnung zurück und kann die Zahl der Anfragen beim Kundenservice erhöhen.

Das erste Ziel ist nicht, die gesamte interne Untersuchung zu erklären. Es geht darum, praktische Fragen zu beantworten: Welcher Dienst oder welche Funktion ist betroffen, wen könnte das betreffen, welche Alternative gibt es und wann folgt die nächste Aktualisierung? Die Ursache kann später genannt werden, wenn sie ausreichend geprüft ist und einen Mehrwert bietet.

Unterscheiden Sie zwischen einer betrieblichen Meldung und einer Mitteilung für Nutzer. Eine interne Meldung kann Messwerte, Warnungen und technische Komponenten enthalten. Eine nutzerorientierte Mitteilung sollte den Zustand des Dienstes hingegen in verständliche Auswirkungen übersetzen. So vermeiden Sie, Details weiterzugeben, die das Publikum nicht einordnen kann oder die sich noch ändern können.

Informieren Sie nach Auswirkung, nicht nur nach Dauer

Es gibt keinen allgemeinen Schwellenwert in Minuten, der für jede Störung gilt. Ein kurzer Ausfall kann relevant sein, wenn er eine wichtige Handlung verhindert. Eine begrenzte Beeinträchtigung erfordert dagegen vielleicht keine allgemeine Meldung, wenn es eine klare Alternative gibt und nur wenige Menschen betroffen sind. Bewerten Sie Auswirkungen, Umfang und Handlungsmöglichkeiten.

  • Auswirkungen: Welche Aufgabe können Nutzer nicht erledigen? Gibt es Zugriffsverluste, Fehlermeldungen, Verzögerungen oder Informationen, die nicht korrekt angezeigt werden?
  • Umfang: Sind alle Nutzer betroffen, eine Region, ein Kontotyp oder eine bestimmte Funktion? Falls Sie es noch nicht wissen, beschreiben Sie genau, was bekannt ist.
  • Dauer und Entwicklung: Besteht das Problem fort, tritt es wiederholt auf oder verschlimmert es sich? Eine länger andauernde Störung oder eine Änderung ihres Umfangs kann eine Meldung rechtfertigen, auch wenn das Problem zunächst geringfügig schien.
  • Alternativen: Gibt es einen verfügbaren Kanal, ein Verfahren oder eine Funktion, mit der sich die Aufgabe erledigen lässt? Stellen Sie eine Alternative nicht als Lösung dar, wenn sie nicht geprüft wurde.

Als Faustregel gilt: Informieren Sie, wenn Nutzer eine Entscheidung treffen müssen, eine wichtige Aufgabe betroffen ist oder Schweigen dazu führen könnte, dass jemand eine Handlung mit möglichen Folgen wiederholt. Bei einer begrenzten Störung kann eine gezielte Benachrichtigung geeigneter sein als eine Meldung an die gesamte Nutzerschaft. Ist der Umfang noch unklar, benennen Sie den betroffenen Bereich und behaupten Sie nicht ohne Prüfung, der übrige Dienst funktioniere normal.

Bestätigte Fakten, Unsicherheit und interne Details trennen

Eine hilfreiche Aktualisierung unterscheidet zwischen bestätigten Informationen und dem, was das Team noch untersucht. Sie können beispielsweise bestätigen, dass manche Nutzer einen Vorgang nicht abschließen können, auch wenn die Ursache noch unbekannt ist. Für die Beschreibung der Auswirkungen ist die technische Ursache nicht erforderlich.

Formulieren Sie konkret: „Wir untersuchen Fehler bei der Anmeldung“ sagt mehr aus als „Wir prüfen eine Unregelmäßigkeit“. Wenn die Informationen unvollständig sind, grenzen Sie sie ein: „Das Problem betrifft das Laden des Verlaufs in der mobilen App. Wir prüfen, ob auch andere Kanäle betroffen sind.“ Vermeiden Sie absolute Aussagen wie „alle“, „niemand“ oder „vollständig behoben“, sofern die Daten sie nicht belegen.

Interne Vermutungen, Systemnamen und Gesprächsausschnitte des Teams bieten Nutzern meist wenig Mehrwert. Außerdem können sie Verwirrung stiften oder Informationen preisgeben, die nicht veröffentlicht werden sollten. Ändert sich eine Vermutung, müssen Sie nicht jeden Schritt der Untersuchung schildern. Aktualisieren Sie stattdessen die bestätigten Angaben zu Auswirkungen und Status.

Eine gute Meldung kann Unsicherheit einräumen, ohne ausweichend zu wirken: „Wir haben die Ursache noch nicht bestätigt. Das Team arbeitet daran, den Dienst wiederherzustellen. Die nächste Aktualisierung veröffentlichen wir um 15:30 Uhr.“

Kanal, Zielgruppe und Verantwortliche festlegen

Der Kanal sollte es den betroffenen Personen ermöglichen, die Meldung zu finden. Je nach Art des Problems und den verfügbaren Kontaktmöglichkeiten kommen ein Banner im Produkt, eine Statusseite, eine E-Mail oder eine Benachrichtigung infrage. Gehen Sie nicht davon aus, dass ein einziger Kanal alle erreicht: Ist das Produkt nicht zugänglich, reicht eine Meldung innerhalb der App nicht aus.

Richten Sie die Zielgruppe nach den Auswirkungen aus. Eine allgemeine Nachricht zu einem Fehler, der nur eine bestimmte Funktion betrifft, kann unnötige Unruhe verursachen. Eine gezielte Mitteilung hilft jeder Person, relevante Informationen zu erhalten. Besteht dagegen das Risiko, dass mehr Nutzer betroffen sind als zunächst angenommen, sollten Sie den Kreis erweitern und erklären, dass die Prüfung noch läuft.

Legen Sie im Voraus fest, wer den Text erstellt, wer ihn prüft und wer ihn veröffentlicht. Bei der Prüfung sollten die beschriebenen Auswirkungen, mögliche Alternativen und der Zeitpunkt der nächsten Aktualisierung im Mittelpunkt stehen. Sie sollte nicht zu einem langwierigen Verfahren werden, das die Meldung verzögert. Kundenservice und technische Teams benötigen einen einheitlichen Status, auch wenn sie je nach Kanal unterschiedlich viele Details nennen. Eine verantwortliche Person für die Veröffentlichung verringert Widersprüche und doppelte Meldungen.

Regelmäßig und bei wichtigen Änderungen aktualisieren

Eine erste Mitteilung reicht nicht, wenn die Störung andauert. Legen Sie einen Zeitpunkt für die nächste Information fest, auch wenn es bis dahin keine Neuigkeiten gibt. Eine solche Zusage einzuhalten ist hilfreicher, als einen Behebungszeitpunkt zu versprechen, der von noch unbekannten Faktoren abhängt. Ändert sich der geplante Zeitpunkt, teilen Sie das mit und nennen Sie einen neuen Termin.

Eine Aktualisierung ist angebracht, wenn sich der Umfang ändert, andere Auswirkungen auftreten, eine neue Alternative verfügbar wird, die Wiederherstellung beginnt oder bestätigt ist, dass eine Funktion wieder arbeitet. Auch zum angekündigten Zeitpunkt sollte es eine Meldung geben, selbst wenn der Stand weiterhin lautet: „Wir untersuchen das Problem.“ Machen Sie nicht jede kleine interne Veränderung zur Nachricht. Bevorzugen Sie Änderungen, die beeinflussen, was Nutzer wissen oder tun sollten.

Nennen Sie die Uhrzeit und, wenn es für eine vielfältige Zielgruppe wichtig ist, auch die Zeitzone. Wenn mehrere Kanäle genutzt werden, halten Sie den Status überall auf demselben Stand. Eine Statusseite sollte nicht bereits eine Wiederherstellung melden, während der Kundenservice weiterhin von einem vollständigen Ausfall spricht.

Ein kurzer Aufbau für handlungsorientierte Meldungen

Die meisten Mitteilungen lassen sich in vier Elemente gliedern. Diese Struktur erleichtert das Lesen und verhindert, dass sich der Text zu sehr um interne Untersuchungen dreht:

  1. Auswirkungen: Beschreiben Sie, welche Funktion ausfällt und welche Aufgabe betroffen sein könnte.
  2. Status: Geben Sie an, ob das Team das Problem untersucht, eine Lösung umsetzt oder die Wiederherstellung überprüft.
  3. Alternative: Nennen Sie einen sicheren, geprüften Schritt oder erklären Sie, dass es derzeit keine Alternative gibt.
  4. Nächste Aktualisierung: Geben Sie an, wann und wo Sie wieder informieren, auch wenn der Zeitpunkt der Behebung noch nicht feststeht.

Ein Beispiel: „Einige Nutzer können ihre letzten Bestellungen nicht laden. Wir untersuchen das Problem. Bereits bestätigte Bestellungen müssen Sie nicht erneut absenden. Eine weitere Aktualisierung veröffentlichen wir um 16:00 Uhr auf der Statusseite.“ Jede Aussage muss überprüfbar sein. Können Sie die Auswirkungen auf bestehende Bestellungen nicht bestätigen, lassen Sie diese Aussage weg.

Die Wiederherstellung melden und veröffentlichte Angaben korrigieren

Wenn der Dienst wieder verfügbar zu sein scheint, verwechseln Sie die Umsetzung einer Änderung nicht mit einer bestätigten Wiederherstellung. Teilen Sie mit, dass das Team das Ergebnis noch prüft, wenn die Kontrollen andauern. Sobald die Wiederherstellung bestätigt ist, nennen Sie die wieder verfügbare Funktion und informieren Sie darüber, ob Nutzer noch etwas erledigen müssen.

War eine frühere Mitteilung falsch, korrigieren Sie sie sichtbar und direkt. Erklären Sie, welche Angabe sich ändert und welche Information jetzt gilt. Bearbeiten Sie eine wichtige Aussage nicht stillschweigend, wenn Nutzer bereits auf ihrer Grundlage gehandelt haben könnten. Weisen Sie niemandem die Schuld zu, bevor die Untersuchung abgeschlossen ist, und trennen Sie eine spätere Erklärung von den unmittelbaren Hinweisen für Nutzer.

Zum Abschluss muss nicht unbedingt eine ausführliche Ursachenanalyse gehören. Es kann genügen, die Wiederherstellung zu bestätigen, den betroffenen Zeitraum oder die betroffene Funktion zu nennen, sobald diese Angaben bekannt sind, und relevante nächste Schritte mitzuteilen. Wird die Ursache noch untersucht, sagen Sie das, statt den Vorfall als vollständig aufgeklärt darzustellen.

Checkliste für ein Kommunikationsprotokoll

Checkliste für ein Kommunikationsprotokoll
  • Ist die betroffene Aufgabe oder Funktion in verständlicher Sprache beschrieben?
  • Ist klar zwischen bestätigten Angaben und laufenden Untersuchungen unterschieden?
  • Passen Zielgruppe und Kanal zum bekannten Umfang der Störung?
  • Ist eine angebotene Alternative geprüft und sicher?
  • Gibt es eine verantwortliche Person für die Veröffentlichung und eine einheitliche Statusquelle?
  • Ist eine nächste Aktualisierung vorgesehen, auch wenn es keine Neuigkeiten gibt?
  • Vermeidet die Mitteilung Aussagen zu Ursache, Dauer oder Garantien, die sich nicht belegen lassen?
  • Ist festgelegt, wie die Wiederherstellung bestätigt und frühere Information korrigiert wird?

Ein hilfreiches Protokoll soll nicht dafür sorgen, dass jede Störung dieselbe Mitteilung erhält. Es gibt Kriterien an die Hand, um schnell und einheitlich zu entscheiden. Wenn das Team die bekannten Auswirkungen beschreibt, die Grenzen des verfügbaren Wissens offenlegt und regelmäßig informiert, können Nutzer handeln, ohne dass technische Unsicherheit zu unnötiger zusätzlicher Verunsicherung führt.

Fuentes y referencias

  1. Web standardsW3C
  2. OWASP Cheat Sheet SeriesOWASP Foundation
  3. Web performanceweb.dev