Der Chat für IT-Störungen gehört vor dem Ausfall festgelegt. So bleibt der Service Desk handlungsfähig

Bei einer IT-Störung entsteht selten nur ein technisches Problem. Gleichzeitig laufen Chatnachrichten, Telefonate, Statusmeldungen, Freigaben und Kundenerwartungen durcheinander. Genau deshalb muss der wichtigste Kommunikationskanal feststehen, bevor der Ausfall beginnt.

Mit dem Chat für IT-Störungen ist hier nicht irgendein spontaner Gruppenchat gemeint. Gemeint ist der vorab definierte Kanal, in dem Service Desk, Betrieb, Fachbereich, Provider und verantwortliche Entscheider während einer Störung koordiniert arbeiten. Für ITSM-Generalisten ist das wichtig, weil ein Kanal ohne klare Rolle schnell selbst zum Risiko wird. Er beschleunigt dann nicht die Lösung, sondern verteilt Unsicherheit.

Ein schneller Chat ersetzt keine Steuerung

Wenn ein Dienst ausfällt, wirkt ein Chat zunächst praktisch. Alle können sofort schreiben, Screenshots teilen und neue Hinweise melden. Das hilft aber nur, wenn klar ist, wofür der Kanal da ist. Geht es um technische Diagnose, Kundenkommunikation, Freigaben, Eskalation oder nur um Status für Beobachter? Ohne diese Trennung entsteht ein einziger Nachrichtenstrom, in dem die wichtigste Entscheidung leicht untergeht.

Der Service Desk braucht in dieser Lage nicht möglichst viele Informationen, sondern verwertbare Orientierung. Wer meldet den aktuellen Befund? Wer bestätigt die Auswirkung auf den Service? Wer darf eine riskante Maßnahme freigeben? Wer sagt dem Kunden, was gerade passiert? Diese Fragen gehören nicht erst in den laufenden Ausfall. Sie gehören in den vorbereiteten Störungsablauf und in die Ticketvorlage.

Der Kanal braucht eine sichtbare Besitzerrolle

Ein Störungschat ohne Besitzer wird schnell laut, aber nicht zuverlässig. Eine Person oder Rolle muss den Kommunikationsfluss führen. Diese Rolle muss nicht jede technische Antwort kennen. Sie muss aber darauf achten, dass offene Entscheidungen, Kundenzusagen und nächste Schritte sichtbar bleiben. Im ITSM-Alltag kann das der Incident Manager, der Service Desk Lead oder eine Bereitschaftsrolle sein.

Wichtig ist die Trennung zwischen Moderation und Technik. Der technische Spezialist soll analysieren, nicht gleichzeitig den Chat sortieren, Kundenstatus formulieren und Freigaben einsammeln. Wenn beides bei derselben Person landet, werden entweder die technischen Arbeiten langsamer oder die Kommunikation unklar. Ein klarer Kanalbesitzer schützt deshalb nicht nur die Ordnung im Chat, sondern auch die Arbeitsfähigkeit der Fachleute.

Im Ticket muss stehen, welcher Chat zählt

Der Störungschat darf kein geheimes Nebenprotokoll werden. Im Ticket sollte sichtbar sein, welcher Kanal für die aktuelle Störung gilt, wer ihn führt und welche Entscheidungen dort gefallen sind. Sonst bleibt nach dem Ausfall eine Lücke: Im Tool steht ein knapper Statuswechsel, während die eigentlichen Absprachen in einem Chatverlauf verschwinden.

Praktisch hilft eine einfache Ticketzeile: „Kommunikationskanal: Incident-Chat Betrieb, Besitzer: Service Desk Lead, Entscheidungen werden als Ticketnotiz zusammengefasst.“ Damit ist nicht jede Nachricht automatisch dokumentationspflichtig. Aber jede relevante Freigabe, Kundeninformation, Rücknahme oder Eskalation wandert zurück in das Ticket. So bleibt der Nachweis auch dann verständlich, wenn der Chat später geschlossen, archiviert oder schwer auffindbar ist.

Beobachter brauchen einen anderen Status als Entscheider

Ein häufiger Fehler entsteht, wenn Entscheider, technische Bearbeiter und reine Beobachter im selben Strom arbeiten. Dann kommen Rückfragen von Personen, die informiert bleiben wollen, direkt zwischen technische Befunde und Freigaben. Für kritische Störungen ist deshalb oft eine zweistufige Kommunikation sinnvoll: ein Arbeitskanal für das Kernteam und ein separater Statuskanal für Stakeholder.

Der Statuskanal darf weniger Details enthalten, muss dafür aber verlässlich sein. Er beantwortet: Was ist betroffen? Was passiert gerade? Wann kommt die nächste Aktualisierung? Wer ist Ansprechpartner? Diese Trennung reduziert Druck im Arbeitskanal und verhindert, dass der Service Desk jede einzelne Nachfrage neu ausformulieren muss.

So prüfst Du Deinen Störungschat vor dem Ernstfall

• Ist der verbindliche Kanal im Störungsablauf und in der Ticketvorlage benannt?
• Gibt es eine Besitzerrolle, die Nachrichten, Entscheidungen und nächste Updates sichtbar hält?
• Ist geregelt, welche Entscheidungen aus dem Chat als Ticketnotiz dokumentiert werden?
• Gibt es einen getrennten Statusweg für Stakeholder, die nicht im Arbeitskanal mitentscheiden?
• Ist klar, wann der Service Desk Kunden oder Fachbereiche aktiv informiert?

Atlassian beschreibt Incident-Kommunikation als eigenen Teil des Störungsmanagements, weil abgestimmte Updates Vertrauen schaffen und Teams ausrichten. CISA betont bei Incident-Response-Plänen, dass Rollen, Verantwortlichkeiten und Kommunikationswege vorbereitet sein müssen. Auch das NIST Cybersecurity Framework 2.0 ordnet Reaktion und Kommunikation als Bausteine ein, die Organisationen vor dem Ereignis beherrschbar machen sollen. Für itsm.news folgt daraus eine einfache Betriebsregel: Der Chat darf nicht erst im Ausfall erfunden werden. Er muss vorher so festgelegt sein, dass der Service Desk im Ernstfall steuern kann.

Quellen und Einordnung: Atlassian zur Incident-Kommunikation, CISA zu Grundlagen eines Incident-Response-Plans, NIST Cybersecurity Framework 2.0. Stand der Quellenprüfung: 24.07.2026. Bildquelle: Pexels / Foto-ID 1181345 / C00 Lizenz.