Ticket Ping-Pong: Ursachen erkennen und gezielt abstellen

Ein Incident-Ticket wird vom 1st Level an den 2nd Level eskaliert. Der 2nd Level schickt es zurück — fehlende Informationen. Der 1st Level ergänzt, eskaliert erneut. Der 2nd Level prüft, stellt fest: falsches Team. Weiterleitung an Network Ops. Network Ops prüft, stellt fest: doch 2nd Level. Zurück. Vier Zuweisungen, drei Tage Durchlaufzeit — für ein Ticket, das in 45 Minuten lösbar gewesen wäre.

Dieses Muster hat einen Namen: Ticket Ping-Pong. Und es ist eines der teuersten Probleme im IT-Service-Management, weil es in keinem Standard-Report auftaucht.

Was Ticket Ping-Pong wirklich kostet

Die offensichtlichen Kosten sind die verlängerte Durchlaufzeit. Tickets mit vier oder mehr Zuweisungen brauchen im Durchschnitt die dreifache Zeit bis zur Lösung. Aber die versteckten Kosten sind gravierender.

Jede Weiterleitung erzeugt Kontextwechsel-Kosten: Das empfangende Team muss das Ticket lesen, den bisherigen Verlauf verstehen, die eigene Zuständigkeit prüfen und eine Entscheidung treffen. Selbst wenn die Entscheidung "nicht zuständig" lautet, kostet sie 10 bis 15 Minuten pro Ticket. Bei hundert Ping-Pong-Tickets pro Woche sind das 25 bis 40 Stunden reine Reibung — verteilt auf mehrere Teams, unsichtbar in jeder Einzelstatistik.

Dazu kommt der Vertrauensschaden beim Endnutzer. Wer drei Tage auf die Lösung eines Standard-Incidents wartet und dabei vier verschiedene Bearbeiter-Namen in seiner Ticket-Historie sieht, verliert das Vertrauen in die IT-Organisation. Nicht weil jemand schlecht arbeitet, sondern weil der Prozess versagt.

Drei Ursachen, die sich in den Daten zeigen

Ticket Ping-Pong ist selten ein Einzelproblem. In der Analyse zeigen sich drei wiederkehrende Ursachen, die oft zusammenwirken.

1. Unklare Eskalationskriterien

Die häufigste Ursache. Für bestimmte Ticket-Kategorien existieren keine eindeutigen Regeln, wann ein Ticket eskaliert werden soll und an wen. Besonders betroffen sind Kategorien an der Grenze zwischen Verantwortungsbereichen: Ist ein VPN-Problem ein Netzwerk-Incident oder ein Arbeitsplatz-Incident? Gehört eine SAP-Berechtigungsanfrage zum Identity Management oder zum SAP-Team?

Ohne klare Kriterien entscheidet der einzelne Agent nach Erfahrung und Bauchgefühl. Das führt zu inkonsistenten Entscheidungen — und zu Tickets, die zwischen Teams pendeln, weil jedes Team eine andere Interpretation hat.

In der Praxis zeigt sich das als erhöhte Reassignment-Rate bei spezifischen Kategorien. Nicht alle Tickets einer Kategorie sind betroffen — nur die, die in die Grauzone fallen. Aber diese Grauzone kann 20 bis 30 Prozent des Gesamtvolumens ausmachen.

2. Fehlende Informationen bei der Ersterfassung

Ein Ticket wird eskaliert, aber dem empfangenden Team fehlen Informationen, um es zu bearbeiten. Die Reaktion: Zurück an den 1st Level mit der Bitte um Ergänzung. Der 1st Level ergänzt, eskaliert erneut. Zwei Zuweisungen, die durch ein besseres Ersterfassungs-Template vermeidbar gewesen wären.

Dieses Muster ist trickreich, weil es auf den ersten Blick nach einem Kommunikationsproblem aussieht. Aber es ist ein Prozessproblem: Die Pflichtfelder bei der Ticket-Erstellung decken nicht die Informationsbedürfnisse der Bearbeitungsteams ab.

In den Daten erkennt man dieses Muster an einer hohen Rate von Rückweisungen innerhalb der ersten zwei Stunden nach Eskalation. Das empfangende Team prüft das Ticket, stellt fest, dass Informationen fehlen, und schickt es zurück — oft schneller als es inhaltlich bearbeiten könnte.

3. Mehrdeutige Kategorisierung

Team A versteht unter "Netzwerk" physische Infrastruktur. Team B versteht darunter auch VPN und WLAN. Das Ticket-System hat eine Kategorie "Netzwerk" ohne weitere Differenzierung. Beide Teams halten sich abwechselnd für zuständig und nicht zuständig — je nachdem, was der konkrete Ticket-Inhalt beschreibt.

Die Kategorisierung im ITSM-System ist oft historisch gewachsen und spiegelt nicht die aktuelle Teamstruktur wider. Neue Teams entstehen, Verantwortlichkeiten verschieben sich, aber die Kategorien bleiben gleich. Das Ergebnis: Eine Kategorie, die früher eindeutig einem Team zugeordnet war, fällt jetzt in den Verantwortungsbereich von zwei oder drei Teams.

Warum Standard-Reports das Problem nicht zeigen

Standard-ITSM-Reports messen pro Team: durchschnittliche Bearbeitungszeit, Anzahl geschlossener Tickets, SLA-Quote. Diese Metriken zeigen die Leistung innerhalb eines Teams — aber nicht die Übergänge zwischen Teams.

Team A sieht in seinem Report: "Wir haben 30 Prozent der Netzwerk-Tickets weitergeleitet." Team B sieht dasselbe. Beide halten ihre Weiterleitungsrate für normal. Was keiner sieht: Es sind teilweise dieselben Tickets, die mehrfach zwischen beiden Teams hin- und hergehen.

Das Problem wird erst sichtbar, wenn man nicht die Team-Perspektive, sondern die Ticket-Perspektive einnimmt: Wie viele Zuweisungen hat ein einzelnes Ticket durchlaufen? Zwischen welchen Teams bewegen sich die Tickets? Gibt es bidirektionale Muster — Team A leitet an Team B weiter und Team B leitet an Team A zurück?

Ein Praxis-Szenario

Ein mittelständisches Unternehmen mit rund 200 IT-Tickets pro Woche bemerkt steigende Durchlaufzeiten bei Incidents. Der Service-Desk-Leiter prüft die üblichen KPIs: Bearbeitungszeit pro Team sieht normal aus. SLA-Quote ist leicht gesunken, aber nicht dramatisch. Backlog wächst moderat.

Erst die Analyse der Ticket-Pfade zeigt das Problem: 18 Prozent aller Incidents durchlaufen drei oder mehr Zuweisungen. Konzentriert auf zwei Kategorien — "Netzwerk" und "Arbeitsplatz" — die zusammen 40 Prozent des Gesamtvolumens ausmachen. Die Durchlaufzeit dieser Tickets liegt bei dem 3.2-fachen im Vergleich zu direkt bearbeiteten Tickets derselben Kategorie.

Im Briefing-View von Process Radar erscheint dieses Muster als priorisiertes Handlungsfeld: "Überdurchschnittliche Reassignment-Rate bei Netzwerk-Incidents — Team X hat 3.2x höhere Weiterleitungsrate als vergleichbare Teams." Die Ursache: Die Eskalationskriterien für VPN-bezogene Incidents waren nicht definiert. Jedes Team, das ein VPN-Ticket erhielt, prüfte nach eigenem Ermessen — und leitete im Zweifel weiter.

Die Lösung: Ein dreizeiliges Update der Eskalationsmatrix. VPN-Tickets mit bestimmten Symptomen gehen direkt an Network Ops, alle anderen an den Arbeitsplatz-Support. Aufwand: Eine Stunde Abstimmung. Effekt: Ping-Pong-Rate in dieser Kategorie sinkt innerhalb von zwei Wochen um 60 Prozent.

Drei Schritte, die du jetzt umsetzen kannst

Schritt 1: Reassignment-Häufigkeit messen. Exportiere deine Ticket-Historie der letzten sechs Monate und zähle die Zuweisungen pro Ticket. Bilde zwei Gruppen: Tickets mit einer oder zwei Zuweisungen und Tickets mit drei oder mehr. Vergleiche die Durchlaufzeiten. Wenn der Unterschied Faktor 2 oder mehr beträgt, hast du ein strukturelles Routing-Problem.

Schritt 2: Muster automatisch erkennen lassen. Lade deine Ticket-Daten als CSV in Process Radar hoch — kostenlos und ohne API-Anbindung. Das Tool erkennt Reassignment-Muster automatisch und zeigt im Briefing-View, welche Kategorien und Team-Kombinationen betroffen sind. Ergebnis in wenigen Minuten.

Schritt 3: Eskalationsmatrix aktualisieren. Nimm die identifizierten Problemkategorien und definiere eindeutige Eskalationskriterien. Besprich die Ergebnisse im nächsten Team-Meeting mit den beteiligten Teamleitern. Oft reicht eine einfache Wenn-Dann-Regel, um die Grauzone aufzulösen.

Fazit

Ticket Ping-Pong ist kein Kommunikationsproblem — es ist ein Prozessproblem mit messbaren Ursachen. Wer die Reassignment-Muster in seinen Ticket-Daten sichtbar macht, findet die Hebel, die den größten Effekt haben.

Häufig gestellte Fragen

Was ist Ticket Ping-Pong im ITSM? Ticket Ping-Pong bezeichnet das wiederholte Weiterleiten eines Tickets zwischen zwei oder mehr Teams, ohne dass die Bearbeitung wesentlich vorankommt. Typisch sind drei oder mehr Zuweisungen, die die Durchlaufzeit auf ein Vielfaches erhöhen. Die Ursachen liegen meist in unklaren Zuständigkeiten, fehlenden Informationen oder mehrdeutigen Kategorien.

Wie misst man Ticket Ping-Pong? Die einfachste Messung ist die Anzahl der Zuweisungen pro Ticket. Exportiere die Ticket-Historie aus deinem ITSM-System und zähle die Zuweisungsereignisse pro Ticket-ID. Tickets mit drei oder mehr Zuweisungen sind Kandidaten. Ergänzend hilft eine Quell-Ziel-Matrix: Welches Team leitet wie oft an welches andere Team weiter — und wie oft kommt das Ticket zurück?

Welche Tools erkennen Ticket Ping-Pong automatisch? Spezialisierte ITSM-Analyse-Tools wie Process Radar erkennen Reassignment-Muster automatisch aus CSV-Exporten. Im Unterschied zu manueller Analyse identifizieren sie nicht nur die Häufigkeit, sondern auch die spezifischen Kategorie-Team-Kombinationen, die das Problem treiben. Eine API-Anbindung an das Quellsystem ist dabei nicht nötig — ein CSV-Export genügt.