So übergibst Du Tickets, damit der nächste Schritt wirklich klar ist

Eine Ticketübergabe wirkt im Tool oft erledigt, sobald ein Ticket an eine andere Gruppe geschoben wurde. Für den Service Desk beginnt dort aber der riskante Teil: Jemand muss erkennen, welche Entscheidung als Nächstes fällig ist.

Mit Ticketübergabe ist hier nicht nur der technische Besitzerwechsel in einem ITSM-Tool gemeint. Gemeint ist die fachliche Übergabe einer offenen Störung, Anfrage oder Eskalation von einer Person, Gruppe oder Schicht an die nächste. Für ITSM-Generalisten ist das wichtig, weil Kunden meist nicht sehen, welche interne Gruppe gerade zuständig ist. Sie sehen nur, ob die nächste Antwort, Prüfung oder Entscheidung rechtzeitig kommt.

Der häufigste Fehler liegt deshalb nicht im fehlenden Klick auf „Zuweisen“. Er liegt in einer Übergabe ohne Entscheidungsauftrag. Das Ticket enthält dann Historie, Screenshots, Rückfragen und vielleicht eine Priorität. Was fehlt, ist die kurze Antwort auf die Frage, was der nächste Bearbeiter jetzt entscheiden oder auslösen soll.

Ein Besitzerwechsel ist noch keine Übergabe

Viele ITSM-Tools machen den Wechsel der Zuständigkeit sichtbar. Sie zeigen Gruppe, Bearbeiter, Status und Zeitstempel. Diese Felder sind nötig, aber sie erklären noch nicht, warum der Wechsel passiert und welcher nächste Schritt erwartet wird. Ein Ticket kann formal korrekt bei der richtigen Gruppe liegen und trotzdem operativ hängen bleiben.

Eine belastbare Übergabe braucht daher drei kurze Informationen. Erstens: Was ist der aktuelle Befund? Zweitens: Welche Entscheidung steht jetzt an? Drittens: Welche Zusage oder Frist ist gegenüber Kunde, Fachbereich oder Betrieb bereits aktiv? Fehlt einer dieser Punkte, muss der nächste Bearbeiter die Lage neu lesen. Genau dort entstehen Verzögerungen, doppelte Rückfragen und widersprüchliche Antworten.

Der nächste Schritt muss als Entscheidung formuliert sein

Ein guter Übergabesatz klingt nicht wie ein Protokoll. Er klingt wie ein Arbeitsauftrag. Statt „Bitte prüfen“ hilft zum Beispiel: „Bitte entscheiden, ob der Dienst neu gestartet werden darf, weil drei Fachanwender betroffen sind und der Kunde bis 10:30 Uhr eine Rückmeldung erwartet.“ Damit wird aus einer unklaren Weitergabe ein konkreter Entscheidungspunkt.

Das gilt auch für kleinere Tickets. Wenn ein Passwortproblem an den Fachsupport geht, sollte klar sein, ob es um Berechtigungen, Identitätsprüfung, eine technische Sperre oder eine Kundenkommunikation geht. Wenn eine Störung an den Infrastruktur-Betrieb geht, muss sichtbar sein, ob der nächste Schritt Diagnose, Freigabe, Rücknahme einer Änderung oder Eskalation zum Provider ist.

Übergaben brauchen eine Rückkehrregel

Viele Tickets bleiben liegen, weil niemand definiert, wann sie zum Service Desk zurückkehren. Der Fachsupport prüft, der Provider analysiert, die Anwendungsteams warten auf Logs. In der Zwischenzeit bleibt unklar, wer die Kundenerwartung schützt. Eine Rückkehrregel verhindert, dass aus einer Übergabe ein offener Wartestatus wird.

Praktisch reicht oft ein einfacher Satz: „Wenn bis 11:00 Uhr keine technische Bestätigung vorliegt, informiert der Service Desk den Fachbereich mit Zwischenstand und eskaliert an die Bereitschaft.“ So bleibt die Verantwortung nicht vollständig beim Empfänger hängen. Der Service Desk behält die Kommunikationsrolle, ohne die technische Entscheidung vorwegzunehmen.

Priorität allein löst den Konflikt nicht

Prioritäten helfen, Arbeit zu sortieren. Sie ersetzen aber nicht die Entscheidung, die in einem Ticket steckt. Zwei Tickets mit gleicher Priorität können völlig unterschiedliche nächste Schritte brauchen. Eines erfordert Kundenkommunikation, eines eine technische Freigabe, eines eine Sicherheitsentscheidung und eines nur eine saubere Dokumentation. Wer nur die Priorität übergibt, überlässt dem Empfänger die ganze Einordnung.

Das ist besonders gefährlich bei Schichtwechseln, geteilten Providerrollen und Tickets mit mehreren beteiligten Teams. Dort steigt die Wahrscheinlichkeit, dass jeder nur den eigenen Ausschnitt liest. Eine gute Übergabe reduziert diese Reibung, indem sie den nächsten Engpass benennt und nicht nur die letzte Aktivität beschreibt.

Die kleine Checkliste für den Service Desk

• Ist der aktuelle Befund in einem kurzen Satz verständlich?
• Steht im Ticket, welche Entscheidung oder Folgehandlung jetzt fällig ist?
• Sind Kundenzusage, interne Frist oder Eskalationszeit sichtbar?
• Ist klar, wer die nächste Kundeninformation gibt?
• Gibt es eine Rückkehrregel, falls der Empfänger nicht rechtzeitig reagiert?

ITIL 4 beschreibt Incident Management als Praxis, die Services nach Störungen möglichst schnell wiederherstellen und negative Auswirkungen begrenzen soll. Atlassian ordnet Incident Management ebenfalls als koordinierten Ablauf aus Erkennen, Reagieren und Lernen ein. Für itsm.news folgt daraus eine einfache Betriebsregel: Ein Ticket ist erst dann sauber übergeben, wenn die nächste Entscheidung sichtbar ist. Der Toolstatus ist der Nachweis, aber nicht die eigentliche Arbeit.

Quellen und Einordnung: AXELOS zur ITIL-4-Praxis Incident Management, Atlassian Incident Management Guide. Stand der Quellenprüfung: 21.07.2026. Bildquelle: Pexels, Foto-ID 3184465, C00 Lizenz.