Bildquelle: Bildquelle: Pexels / Foto-ID 3184291 / https://www.pexels.com/photo/3184291/ / C00 Lizenz
Eine IT-Störung wechselt selten genau dann die Schicht, wenn alles geklärt ist. Oft bleibt eine technische Prüfung offen, ein Kunde wartet auf eine Antwort und der nächste Dienst übernimmt mit einer knappen Notiz. Genau dann entscheidet sich, ob der Service Desk weiter steuert oder nur noch nachfragt.
Ein Schichtwechsel ist mehr als die Übergabe eines technischen Status. Für ITSM-Generalisten zählt, ob die nächste Person sofort erkennt, was Nutzer wissen müssen, welche Entscheidung offen ist und wann wieder kommuniziert wird. Ein Ticket ist dafür der bessere Ort als ein Chat, weil es die Spur dauerhaft sichtbar hält.
Der technische Stand reicht nicht
In Störungen wird häufig zuerst über Systeme gesprochen. Anwendung langsam, Datenbank geprüft, Provider informiert, Neustart geplant. Diese Informationen sind wichtig, aber sie beantworten nicht automatisch die Kundenfrage. Nutzer wollen wissen, ob sie warten sollen, ob ein Ausweichweg gilt, ob Daten verloren sind oder wann die nächste Aktualisierung kommt.
Wenn diese Frage beim Schichtwechsel nur mündlich oder im Chat weitergegeben wird, entsteht ein Bruch. Die neue Schicht liest zwar den technischen Verlauf, muss aber die kommunikative Lage neu zusammensuchen. Dadurch entstehen doppelte Rückfragen, unklare Zusagen und manchmal widersprüchliche Antworten an Kunden oder Fachbereiche.
Das Ticket braucht eine Kommunikationsspur
Ein gutes Störungsticket sollte deshalb nicht nur Fehlerbild, Priorität und Maßnahmen enthalten. Es braucht eine kleine Kommunikationsspur. Darin stehen die letzte Aussage an Nutzer, die nächste geplante Aktualisierung, offene Kundenfragen, ein möglicher Workaround und die Person oder Rolle, die die nächste Antwort freigibt. Das klingt nach Zusatzarbeit, spart aber im laufenden Vorfall Zeit.
Atlassian beschreibt Incident Communication als eigenen Teil des Vorfallmanagements. Entscheidend ist nicht nur, dass kommuniziert wird, sondern dass Zielgruppen, Kanäle und Aktualisierungsrhythmus klar sind. Für den Schichtwechsel heißt das praktisch: Wer übernimmt, muss nicht erraten, welche Aussage zuletzt draußen war und welche Erwartung dadurch entstanden ist.
Offene Kundenfragen sind Betriebsrisiken
Eine offene Kundenfrage wirkt manchmal wie ein Randthema neben der technischen Lösung. In Wirklichkeit kann sie den Vorfall vergrößern. Wenn ein Kunde keine Orientierung bekommt, steigen Tickets, Anrufe und interne Eskalationen. Wenn der Service Desk eine falsche Entwarnung gibt, entsteht Vertrauensverlust. Wenn eine Zusage nicht im Ticket steht, kann die nächste Schicht sie nicht verlässlich einhalten.
PagerDuty ordnet Incident Response als koordinierten Ablauf mit Rollen, Kommunikation und Nachverfolgung ein. Diese Logik hilft auch ohne großes Spezialwerkzeug. Die Übergabe sollte immer klären, wer gerade entscheidet, wer informiert wird und welche nächste Aktion sichtbar geplant ist.
So sieht eine schlanke Übergabe aus
- Schreibe im Ticket die letzte Kunden- oder Nutzerinformation in normaler Sprache auf.
- Notiere die offene Kundenfrage getrennt vom technischen Fehlerbild.
- Setze einen Zeitpunkt für die nächste Aktualisierung, auch wenn die Ursache noch offen ist.
- Markiere, wer die nächste Antwort geben darf und welcher Kanal genutzt wird.
- Dokumentiere Workaround, Einschränkung und Rückkehr zur normalen Nutzung getrennt.
- Verknüpfe Chat- oder Konferenznotizen nicht nur als Link, sondern fasse die Entscheidung im Ticket zusammen.
BMC beschreibt Incident Management als Prozess, der Services möglichst schnell wieder nutzbar machen soll. Dazu gehört im Alltag nicht nur Technik. Ein Service gilt für Nutzer erst dann als steuerbar, wenn sie wissen, was gerade betroffen ist, was sie selbst tun können und wann sie wieder eine verlässliche Information bekommen.
Der Schichtwechsel ist der Qualitätstest
Ein einfacher Test reicht: Kann eine neue Person nach zwei Minuten im Ticket sagen, welche Kundenfrage offen ist und was als Nächstes kommuniziert wird? Wenn ja, trägt das Ticket den Vorfall. Wenn nein, hängt zu viel Wissen an Personen, Chats oder Erinnerungen.
Das Ziel ist nicht, jedes Gespräch zu protokollieren. Es geht um die wenigen Informationen, die eine Störung über eine Schichtgrenze tragen. Technischer Stand, Kundenwirkung, offene Frage, nächste Aktualisierung und Entscheidungsträger. Wer diese Punkte konsequent im Ticket hält, verhindert stille Übergabefehler und hält die Störung auch dann steuerbar, wenn Menschen wechseln.
Quellen und Einordnung: Atlassian Incident Communication, PagerDuty Incident Response, BMC ITIL Incident Management. Stand der Quellenprüfung: 23.07.2026. Bildquelle: Pexels, Foto-ID 3184291, C00 Lizenz.
