Wer bei einer Serviceunterbrechung Kunden informieren muss, verliert die Linie meist in dem Moment, in dem drei Teammitglieder dieselbe Störung mit drei verschiedenen Sätzen beantworten. Eine schreibt „das ist nur kurz“, einer „bis Mittag ist es behoben“, die dritte bittet um einen Screenshot. Kunden vergleichen diese Antworten, und jedes gebrochene Versprechen kommt als neue Nachricht zurück. Das Problem ist nicht die Zahl der Anfragen, sondern das Fehlen einer einzigen Faktenquelle.
Dieser Leitfaden behandelt eine plötzliche Unterbrechung oder Störung, die viele Menschen gleichzeitig trifft: Der Login schlägt fehl, Kartenzahlungen brechen ab, eine Ansicht lädt nicht. Angekündigte Wartungsarbeiten und die längere Suche nach der Ursache wiederkehrender Fälle gehören nicht dazu; dafür gibt es den Leitfaden zu wiederkehrenden Kundenanfragen. Hier legst du fest, was das Team sagt, wer es ändert und wann der Kunde Neues erfährt.
Erst den Umfang bestätigen, dann die erste Antwort schreiben
Bevor jemand antwortet, kläre das Minimum: Was funktioniert nicht, seit wann sieht das Team es, wen betrifft es und was ist noch unbekannt. „Ein Teil der Kunden kann sich nicht in der mobilen App anmelden, die Browserversion läuft“ ist ein brauchbarer Umfang. „Wir haben ein Systemproblem“ hilft weder Kunden noch Team. Kennst du den Umfang noch nicht, schreib das offen, statt zu raten.
Bestimme eine Person, die für den Wortlaut der Meldung verantwortlich ist. Sie muss die Störung nicht beheben; sie sammelt bestätigte Informationen bei den technischen Kolleginnen und Kollegen und gibt sie an den Kundenservice weiter. Das Team antwortet weiterhin den Kunden, ergänzt aber keine eigenen Vermutungen zu Ursache oder Reparaturdauer. So hat jede Änderung der Meldung eine Urheberin und eine Uhrzeit.
Das Google-SRE-Buch beschreibt im Incident-Management eine eigene Kommunikationsrolle, die regelmäßig Updates an das Einsatzteam und an Beteiligte verschickt. Es richtet sich an Technikteams; die Übertragung auf einen kleinen Kundenservice ist unsere Anpassung. Google SRE Book, Managing Incidents.
Das Faktenblatt: eine Quelle für jede Antwort
Das Faktenblatt ist eine kurze Notiz, mit der alle im Team arbeiten. Es enthält nur Bestätigtes und zeigt sichtbar, wann es zuletzt geändert wurde. Es ist kein technischer Bericht; interne Details bleiben draußen, solange der Kunde sie nicht für eine Entscheidung braucht. Die Tabelle zeigt die Felder für einen fiktiven Onlineshop, in dem Kartenzahlungen mit einer Fehlermeldung abbrechen.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Feld | Beispieleintrag | Was nicht hineingehört |
|---|---|---|
| Symptom | Kartenzahlung endet mit Fehlermeldung | Vermutungen zur Ursache |
| Umfang | Karten betroffen, Überweisung funktioniert | „Alle Kunden“, ohne Prüfung |
| Ausweichweg | Bestellung per Überweisung bezahlbar | Ein ungetesteter Ausweichweg |
| Verantwortlich | Schichtleitung im Kundenservice | Mehrere Personen gleichzeitig |
| Nächstes Update | Um 14:30 Uhr, auch ohne Neuigkeiten | Eine Reparaturzeit ohne Grundlage |
Das wichtigste Feld ist die Uhrzeit des nächsten Updates. Du versprichst damit eine Information, keine Reparatur, und kannst das Versprechen halten, auch wenn die Ursache noch offen ist. Ist es so weit, aktualisiert die verantwortliche Person das Blatt und trägt die nächste Uhrzeit ein. Auch „keine neuen Erkenntnisse“ ist eine Nachricht wert: „Wir prüfen weiter, der Ausweichweg funktioniert noch.“
Die erste Antwort an alle, die sich melden
Jeder Kunde schreibt über seinen eigenen Fall, deshalb verbindet die Antwort den gemeinsamen Fakt mit seiner Situation. Bestätige zuerst, dass das Problem bekannt ist, nenne dann Umfang und Ausweichweg und zum Schluss die Uhrzeit der nächsten Information. Beschreibt jemand etwas anderes als das Symptom auf dem Blatt, ordne ihn nicht automatisch der Störung zu; stell eine Frage, die das klärt.
„Danke für deine Meldung. Seit etwa 12:40 Uhr brechen Kartenzahlungen mit einer Fehlermeldung ab; Überweisungen funktionieren normal. Wenn du deine Bestellung jetzt abschließen willst, wähle die Überweisung. Eine Uhrzeit für die Behebung können wir noch nicht nennen, weil die Ursache geprüft wird. Das nächste Update schicken wir dir bis 14:30 Uhr in diesem Gespräch, auch wenn sich nichts geändert hat.“
Speichere die Vorlage als Schnellantwort und aktualisiere sie zusammen mit dem Blatt, nicht als Kopie auf dem Rechner einer einzelnen Person. Wie solche Gerüste aufgebaut werden, zeigt der Leitfaden zu Antwortvorlagen im Kundenservice. Dauert die Störung länger, ergänze einen kurzen Hilfeartikel mit derselben Beschreibung; wie du ihn schreibst, erklärt der Beitrag zu Wissensdatenbank und FAQ auf der Website.
Ein Update-Rhythmus ohne zugesagte Reparaturzeit
Kunden brauchen keine technischen Details, wollen aber wissen, in welcher Phase die Sache steckt. Benenne die Phasen in einfachen Worten und verwende sie in allen Antworten gleich. Wechsle die Phase erst, wenn die verantwortliche Person sie bestätigt. Den Abstand zwischen den Updates wählst du nach Schwere des Problems und hältst ihn auf dem Blatt fest, statt ihn in jedem Gespräch neu zu erfinden.
- Wir prüfen.Das Problem ist bekannt, der Umfang teilweise bestätigt. Nenne einen Ausweichweg, falls vorhanden, und die Uhrzeit der nächsten Information.
- Ursache gefunden.Das Team weiß, was passiert ist, und arbeitet an der Korrektur. Einen Zeitrahmen nennst du nur, wenn die reparierende Person ihn bestätigt hat.
- Korrektur aktiv, wir beobachten.Die Änderung ist eingespielt, das Team prüft aber, ob das Problem zurückkehrt. Bitte den Kunden, es erneut zu versuchen und Bescheid zu geben.
- Behoben.Das Symptom ist im geprüften Umfang verschwunden. Jeder verknüpfte Fall bekommt eine eigene Bestätigung und den nächsten Schritt.
Atlassian verwendet in der Dokumentation zu Incident Insights vier Status: Untersuchung, Ursache identifiziert, Beobachtung nach der Korrektur und behoben. Die Quelle beschreibt den Status der eigenen Dienste; sie sagt nicht, wie oft Kunden ein Update bekommen sollten. Atlassian Support.
Die Beobachtungsphase schützt davor, den Erfolg zu früh zu verkünden. Wurde die Korrektur nur in einer Variante geprüft, sag, in welcher. Dieselbe Regel gilt für den Projektstatus für Kunden: Statt ein Datum zu raten, nennst du den nächsten Prüfpunkt und die Bedingung, von der der weitere Plan abhängt.
Verknüpfte Fälle, einzelne Antworten
Eine gemeinsame Ursache bedeutet kein gemeinsames Gespräch. Jeder Kunde hat seine eigene Vorgeschichte: Einer hat eine Bestellung verloren, eine andere will nur wissen, ob sie es erneut versuchen soll, ein dritter wurde vielleicht doppelt belastet. Führe diese Fälle nicht zusammen und verschicke keine Sammelnachricht, die die Unterschiede ignoriert. Markiere sie gemeinsam, antworte aber jedem einzeln und beginne mit den Fakten vom Blatt.
Im Kundenservice von Meetlead kannst du die Fälle mit einem Tag markieren, das Faktenblatt in einer internen Notiz festhalten, eine Schnellantwort vorbereiten und einen Hilfeartikel in der Wissensdatenbank des Widgets veröffentlichen. Schnellantwort und Artikel aktualisierst du von Hand, und jede Antwort schickt ein Teammitglied im Gespräch mit dem jeweiligen Kunden. Wie du einen solchen Tag benennst, damit er zwischen anderen Kategorien nicht untergeht, erklärt der Leitfaden zum Taggen von Gesprächen und Tickets.
Der gemeinsame Tag hilft auch nach der Störung. Er zeigt, wie viele Menschen sich gemeldet haben, über welche Kanäle und wie viele noch auf eine Bestätigung warten. Lies diese Zahl nicht als volles Ausmaß des Problems: Viele Betroffene haben einfach nicht geschrieben. Hat jemand vorher eine falsche Auskunft bekommen, korrigiere sie gesondert, wie im Leitfaden zur Korrektur einer falschen Antwort beschrieben.
Störung abschließen: jeden Fall einzeln prüfen
Das letzte Update sagt, was behoben wurde, seit wann es funktioniert und was der Kunde tun soll, falls das Problem weiter besteht. Vermeide ein pauschales „alles läuft wieder“, wenn die Korrektur nur in begrenztem Umfang geprüft wurde. Behandle Kunden mit Folgeschäden gesondert, etwa mit einer unbezahlten Bestellung oder einer doppelten Belastung. Diese Fälle brauchen eine Entscheidung, nicht nur eine Erledigt-Meldung.
- Jeder Fall mit dem Störungs-Tag hat eine abschließende Antwort oder eine verantwortliche Person mit Frist.
- Kunden mit Folgen der Störung haben einen eigenen nächsten Schritt, nicht nur eine Erledigt-Meldung.
- Das Faktenblatt zeigt den Endstatus und die Uhrzeit des Abschlusses.
- Schnellantwort und Hilfeartikel zur Störung sind zurückgezogen oder aktualisiert.
- Das Team hat notiert, welche Information Kunden in der ersten Stunde gefehlt hat.
Prüfe nach dem Abschluss die getaggten Gespräche und vergleiche die ersten Antworten mit dem Blatt. Haben Teammitglieder Reparaturzeiten versprochen oder unterschiedliche Umfänge genannt, korrigiere die Vorlage und die Reihenfolge der Schritte, nicht nur einzelne Gespräche. Lösche den alten Tag nicht; ohne ihn kannst du bei der nächsten Störung nicht vergleichen, ob die Kommunikation schneller und einheitlicher war.
Fragen, die bei einer Störung auftauchen
Soll ich Kunden eine voraussichtliche Reparaturzeit nennen? Nur wenn die Person, die die Störung behebt, sie bestätigt hat und weiß, wovon sie abhängt. Andernfalls nenne die Uhrzeit des nächsten Updates und halte sie ein. Eine verpasste Reparaturzeit erzeugt meist mehr Nachrichten als ein ehrliches „Wir wissen es noch nicht“. Ändert sich die Schätzung, sag, was sie verändert hat.
Was antworte ich, wenn das Problem eines Kunden der Störung nur ähnelt? Ordne ihn nicht ungeprüft dem gemeinsamen Fall zu. Frag nach einem entscheidenden Detail, etwa Kanal, Gerät oder Fehlermeldung. Ist das Symptom ein anderes, bearbeite den Fall separat und biete nicht den Ausweichweg vom Blatt an. Eine falsche Zuordnung lässt den Kunden auf eine Korrektur warten, die sein Problem gar nicht betrifft.
