Ticket-Routing optimieren: Wie Umwege den IT-Support ausbremsen
Jedes fünfte Ticket nimmt Umwege. Nicht weil Teams langsam arbeiten, sondern weil Zuständigkeiten unklar sind. Diese Umwege kosten IT-Organisationen Hunderte Stunden pro Monat – und kein Standard-Dashboard zeigt sie.
Routing-Schleifen kosten mehr als Bearbeitungszeit
Ein Ticket wird erstellt, landet bei Team A, wird an Team B weitergeleitet, dort als "nicht zuständig" erkannt und zurück an Team A geschoben. Oder weiter an Team C. Dieses Muster heißt im ITSM-Alltag Ping-Pong. Es klingt harmlos. Die Zahlen sind es nicht.
In einer typischen IT-Organisation mit 4.000 Tickets pro Monat nehmen 15–25 Prozent aller Tickets mindestens eine Umleitung. Bei Tickets mit drei oder mehr Zuweisungen steigt die Durchlaufzeit drastisch. In gemessenen Fällen: von 4 Stunden Median auf 75 Stunden. Nicht weil die Bearbeitung länger dauert, sondern weil das Ticket zwischen Teams wartet.
Diese Umwege erzeugen drei Kostenarten. Erstens: direkte Wartezeit – das Ticket liegt in einer Queue und niemand bearbeitet es. Zweitens: doppelte Einarbeitung – jedes Team liest sich neu ein, prüft, entscheidet, dass es nicht zuständig ist, und leitet weiter. Drittens: Vertrauensverlust – der Melder wartet, fragt nach, eskaliert. Die IT wirkt unkoordiniert, obwohl jedes Team korrekt arbeitet.
Standard-Reports zeigen Weiterleitungen nicht als Problem
Die meisten ITSM-Tools erfassen Weiterleitungen. Sie zeigen: Ticket X wurde von Team A an Team B übergeben. Was sie nicht zeigen: Wie viele Tickets nehmen Umwege? Welche Team-Kombinationen sind betroffen? Und was kostet das in Stunden?
Ein typisches Dashboard zeigt Durchlaufzeiten pro Team und SLA-Erfüllung insgesamt. 92 Prozent SLA – alles grün. Aber unter den 92 Prozent verstecken sich Tickets, die drei Tage zwischen Teams kreisten. Die schnellen Tickets kompensieren die langsamen im Durchschnitt. Wer nur den Durchschnitt sieht, übersieht die Umwege.
Noch problematischer: Weiterleitungen werden oft als normaler Workflow betrachtet. "Das Ticket musste halt an Netzwerk" – klingt logisch. Dass dasselbe Muster bei 200 Tickets pro Monat auftritt und jedes Mal drei Tage kostet, wird erst sichtbar, wenn jemand die Übergänge zwischen Teams zählt. Nicht die Tickets innerhalb eines Teams.
Drei Ursachen für Routing-Schleifen
Mehrdeutige Kategorie-Zuordnung. Wenn eine Ticket-Kategorie keiner klaren Erstrouting-Regel folgt, entscheidet der Service Desk nach Bauchgefühl. Bei "Drucker funktioniert nicht" – ist das Hardware, Netzwerk oder Arbeitsplatz? Jede Interpretation führt zu einem anderen Team. Das Ticket landet bei dem Team, das gerade am naheliegendsten scheint. Oft dem falschen.
Fehlende Rückruf-Regel. Ein Team erkennt: "Das ist nicht meins." Es leitet weiter – aber wohin? Ohne definierte Regel wählt der Agent ein Team nach Erfahrung. Oder schickt es zurück an den Absender. Zurücksenden erzeugt immer Umwege.
Ein typisches Beispiel: Ein Netzwerk-Ticket landet beim Arbeitsplatz-Support. Der Agent sieht "VPN-Problem", hält sich für nicht zuständig und leitet an Network Operations weiter. Network Operations sieht "Laptop kann keine Verbindung aufbauen" und schickt es zurück an Arbeitsplatz-Support. Das Ticket hat zwei Tage verloren – und keiner der beiden Agents hat falsch gehandelt. Beide folgten ihrer lokalen Logik. Das Problem liegt in der fehlenden Regel für den Graubereich dazwischen.
Organisatorische Graubereiche. Zwischen zwei Teams gibt es Ticket-Typen, die beide oder keines der Teams als "ihr Thema" betrachten. Typisch bei Schnittstellen: SAP + Netzwerk, Identity + Arbeitsplatz, Cloud + Security. Diese Graubereiche erzeugen die häufigsten Routing-Schleifen.
Was Routing-Daten tatsächlich zeigen
Die Informationen für eine Routing-Analyse stecken in den Ticket-Daten, die jede IT-Organisation bereits sammelt. Jede Zuweisung wird als Event protokolliert: Ticket X wurde um 14:23 von Team A an Team B übergeben. Aus diesen Events lässt sich rekonstruieren, welchen Weg ein Ticket durch die Organisation nimmt.
Drei Kennzahlen machen Umwege sichtbar:
Zuweisungsrate. Wie viele Tickets durchlaufen drei oder mehr Teams? In gesunden Organisationen liegt dieser Wert unter 10 Prozent. Bei 20 Prozent oder mehr liegt ein strukturelles Routing-Problem vor.
Häufigste Quell-Ziel-Paare. Welche Team-Kombinationen erzeugen die meisten Weiterleitungen? Oft konzentrieren sich 80 Prozent der Umwege auf zwei oder drei Paare. Ein typisches Beispiel: 1st Level Support und Network Operations schieben Tickets der Kategorie "Konnektivität" hin und her. Beide Teams halten sich für nicht zuständig.
Durchlaufzeit-Differenz. Wie viel länger brauchen umgeleitete Tickets im Vergleich zu direkt bearbeiteten? Wenn Tickets ohne Umwege 4 Stunden brauchen und mit Umwegen 75 Stunden, liegt der Hebel nicht in schnellerer Bearbeitung, sondern in weniger Umwegen.
Diese Analyse zeigt auch, welche Kategorien und Standorte betroffen sind. Routing ist selten organisationsweit defekt. Es hakt in spezifischen Kombinationen: "Netzwerk-Tickets am Standort München" oder "SAP-Tickets der Kategorie Berechtigung". Das macht die Lösung gezielt – und machbar.
Ein häufig übersehener Indikator: Die Tageszeit. Wenn Umwege verstärkt am Freitagnachmittag oder nach 17 Uhr auftreten, liegt die Ursache bei der Schichtplanung. Die Routing-Regel ist an sich korrekt – aber das zuständige Team ist nicht besetzt. Das Ticket landet beim Bereitschaftsdienst, der es nicht bearbeiten kann und weiterleitet. Die Lösung ist keine neue Routing-Regel. Die Lösung ist eine angepasste Schichtplanung oder eine Hold-Regel für Off-Hours.
Auch die Reihenfolge der Stationen sagt etwas aus. Wenn Tickets überwiegend auf dem Rückweg scheitern (A → B → A), liegt die Ursache bei der Erstbewertung. Wenn sie auf dem Weiterweg scheitern (A → B → C → B), fehlt Transparenz über die Zuständigkeiten zwischen B und C.
Drei Hebel gegen Routing-Schleifen
Erstrouting-Regeln verschärfen
Der wirkungsvollste Hebel: Für die drei häufigsten Umweg-Kategorien eine eindeutige Erstrouting-Regel definieren. Nicht abstrakt ("Netzwerk-Tickets an Network Operations"), sondern spezifisch: "Tickets der Kategorie Konnektivität mit Keyword VPN gehen an Network Operations. Alle anderen Konnektivität-Tickets gehen an Arbeitsplatz-Support."
Spezifische Regeln brauchen Daten als Grundlage. Welche Keywords tauchen in den umgeleiteten Tickets auf? Welches Team hat sie am Ende tatsächlich gelöst? Wenn Team B in 70 Prozent der Fälle das Ticket löst, obwohl Team A es initial bekommt, muss Team B die Erstroute sein.
Graubereich-Owner definieren
Für jede Team-Kombination mit hoher Umleitungsrate einen Owner bestimmen: Welches Team bearbeitet Tickets im Graubereich zuerst? Das ist keine permanente Zuordnung – es ist eine Eskalationsregel: "Im Zweifel geht es an Team B. Nicht zurück."
Routing-Qualität messen
Eine Kennzahl ins monatliche Reporting aufnehmen: Anteil der Tickets mit drei oder mehr Zuweisungen. Zielwert: unter 10 Prozent. Diese Kennzahl macht Routing-Qualität sichtbar.
Ohne Messung kehren Umwege schleichend zurück. Neue Kategorien entstehen, Teams werden umorganisiert, Zuständigkeiten verschieben sich. Innerhalb von sechs Monaten kann der Umweg-Anteil von 8 auf 20 Prozent steigen – ohne dass es jemand bemerkt. Die monatliche Messung ist kein Aufwand. Sie ist Versicherung.
Ergänzend hilft ein Blick auf die Durchlaufzeit-Differenz: Wie viel länger brauchen umgeleitete Tickets? Wenn diese Differenz trotz sinkender Umleitungsrate steigt, werden die verbleibenden Umwege komplexer. Das deutet auf neue Graubereiche hin, die noch nicht adressiert sind.
Routing-Optimierung hat oft einen Kapazitätseffekt: Teams, die bisher mit umgeleiteten Tickets beschäftigt waren, gewinnen Kapazität zurück. Ein geringerer Anteil an Umwegen senkt die Queue-Tiefe bei allen beteiligten Teams.
Wie Process Radar Routing-Schleifen erkennt
Process Radar analysiert die Ticket-Pfade automatisch aus den exportierten Daten. Das Tool identifiziert Ping-Pong-Muster, misst die Durchlaufzeit-Differenz zwischen umgeleiteten und direkt bearbeiteten Tickets und zeigt die häufigsten Quell-Ziel-Paare. Im Briefing erscheint die Routing-Schleife als Handlungsfeld mit konkretem Impact: betroffene Tickets, verlorene Stunden, beteiligte Teams. Die Delegation an den zuständigen Teamleiter erfolgt mit einem Klick – inklusive Fakten-Briefing.
Laden Sie Ihre Ticket-Daten hoch. Die erste Analyse ist kostenlos.