KI-Ticket-Klassifizierung und -Routing: Triage, die Prioritäten nicht verwechselt

Eine IT-Support-Abteilung bearbeitet täglich 200 Tickets über drei Kanäle: E-Mail, Formular und Chat. Die Hälfte geht zwischen 16:00 und 9:00 Uhr ein, wenn das Team nicht vollständig besetzt ist. Eine historische Analyse von drei Monaten zeigt, dass 12 als „standard“ markierte Fälle innerhalb von 48 Stunden zu schweren Vorfällen eskalierten. Jede Eskalation kostete zwischen 4 und 8 zusätzliche Arbeitsstunden. Ein KI-Klassifikator, der in einem 6- bis 8-wöchigen Pilotprojekt implementiert wird, kann solche Verzögerungen um 60-75 % reduzieren, wenn er gut auf die Asymmetrie der Fehlerkosten kalibriert ist.

Ein gut konzipierter Ticket-Klassifikator liest gleichzeitig mehrere Dimensionen.

Thematische Kategorie ist die einfachste Dimension. Das Modell lernt, Abrechnung von technischen Problemen, kommerzielle Anfragen von Beschwerden, Onboarding von Fragen zur Geschäftsordnung zu unterscheiden. Trainingsdaten sind historische Tickets mit von Teams vergebenen Labels. Bei 500+ Beispielen pro Kategorie erreicht das Modell eine Genauigkeit von 85-92 % im eigenen Test. Unter 200 Beispielen sollte Few-Shot-Prompting mit einem Basismodell statt Fine-Tuning verwendet werden.

Dringlichkeit ist eine schwierigere Dimension, da sie asymmetrisch ist. Ein falscher Eskalationsalarm kostet Minuten an Koordinatorenarbeit. Ein übersehener dringender Fall kostet Kundenverlust oder SLA-Vorfall. Daher sollte der Dringlichkeitsklassifikator ein separates Modell (oder ein separater Klassifizierungskopf) mit deutlich höherer Sensitivität für die Klassen „hoch“ und „kritisch“ sein. Signale: Krisen-Keywords (Ausfall, kein Zugriff, unmöglich, sofort, Verlust), Anzahl vorheriger Tickets desselben Kunden innerhalb von 7 Tagen, Kundentier aus dem CRM, Eingangszeit relativ zum SLA-Fenster.

Sprache und Sentiment ergänzen das Bild. Ein mehrsprachiges Unternehmen benötigt eine automatische Spracherkennung vor der Klassifizierung, um zu vermeiden, dass ein polnisches Ticket in eine englischsprachige Warteschlange geleitet wird. Negatives Sentiment ändert die Priorität nicht direkt, ist aber ein Eskalationssignal: Ein Kunde, der in vier Sätzen zweimal das Wort „Skandal“ verwendet und mit Ausrufezeichen schreibt, erfordert einen anderen Ton in der Auto-Antwort und schnelleren menschlichen Kontakt.

Kanal und Format beeinflussen ebenfalls das Routing. Ein Ticket über Chat hat eine kürzere erwartete Antwortzeit als eine E-Mail. Ein PDF-Anhang, der OCR erfordert, landet in einer anderen Warteschlange als eine Textfrage. Ein Formular mit einem vom Kunden angegebenen „Prioritäts“-Feld ist ein starkes Signal, das das Modell im Text selbst übersehen könnte.

Ein Muster, das sich bei 100-500 Tickets pro Tag bewährt, ist eine Pipeline für strukturierten Output mit schichtweisem Fallback.

Schritt 1: Eingangsnormalisierung. Jedes Ticket aus jedem Kanal wird in eine gemeinsame Struktur überführt: Betreff + Inhalt + Metadaten (Kanal, Uhrzeit, Kunden-ID). Anhänge werden separat durch OCR oder PDF-Extraktor verarbeitet, bevor sie an den Klassifikator übergeben werden.

Schritt 2: Klassifizierung. Das Modell (oder ein LLM-Prompt mit Few-Shot-Beispielen) gibt ein JSON mit der Struktur zurück: { "category": "...", "urgency": "high|standard|low", "language": "pl|en|de", "sentiment": "negative|neutral|positive", "keywords": [...] }. Strukturierter Output mit Schema-Validierung eliminiert halluzinierte Felder. Wenn das Modell urgency: null oder einen niedrigen Confidence-Score zurückgibt, landet das Ticket in der manuellen Klassifizierungs-Warteschlange, nicht im Auto-Routing.

Schritt 3: Routing. Basierend auf der Kreuzung von Kategorie und Dringlichkeit leiten Regeln das Ticket in die entsprechende Warteschlange. Kritische Dringlichkeit landet immer in einer dedizierten Bereitschaftswarteschlange, unabhängig von der Kategorie. Hohe Dringlichkeit außerhalb der Arbeitszeiten löst eine Push-Benachrichtigung oder SMS an den designierten Bereitschaftsdienst aus. Standard-Tickets mit niedrigem Sentiment können eine Auto-Antwort mit RAG aus der Wissensdatenbank erhalten.

Schritt 4: Human-Handoff. Der Agent beendet seine Arbeit nicht mit dem Routing. Er übergibt Kontext: warum das Ticket in diese Warteschlange kam, welche Signale entschieden haben, die Kundenhistorie der letzten 30 Tage, ähnliche gelöste Fälle. Der Berater sieht einen fertigen Briefing statt des rohen Tickets.

Auto-Antwort per RAG funktioniert gut in einem engen Bereich: Fragen zu Bestellstatus, Öffnungszeiten, Rückgabeverfahren, standardmäßige Konfigurationsanleitungen aus der Dokumentation. Bedingung: Die Antwort muss durch das System verifizierbar sein (z. B. Status aus der Datenbank) oder wörtlich aus einem genehmigten Dokument stammen. Eine halluzinierte oder ungenaue Auto-Antwort kostet mehr Vertrauen als keine Antwort.

Ein Mensch greift in jedem dieser Szenarien ein: kritische oder hohe Dringlichkeit, Retentionseskalation, rechtliche oder regulatorische Tickets (RODO, finanzielle Beschwerden), unbekanntes Thema für das Modell (neues Produkt, Vorfall ohne Präzedenzfall in den Trainingsdaten), sehr negatives Sentiment mit Churn-Signalen. Eine gute Regel ist auch: Wenn ein Berater die Auto-Antwort in über 15 % der Fälle einer Kategorie korrigieren müsste, fällt diese Kategorie aus dem Auto-Routing und geht zurück in die menschliche Warteschlange.

Pilotmuster: In den ersten 4-6 Wochen arbeitet der Klassifikator im Shadow-Modus. Er klassifiziert, aber das endgültige Routing übernimmt ein Mensch. Der Vergleich von KI- und Beraterentscheidungen baut Ground Truth für die Modellbewertung auf und zeigt Kategorien, in denen sich das Modell systematisch irrt.

Observability für ein Routing-System basiert auf mehreren Metriken, die ab dem ersten Tag gesammelt werden.

Precision und Recall pro Warteschlange. Precision: Wie viele Tickets sind zu Recht in der Warteschlange gelandet. Recall: Wie viele Tickets, die in die Warteschlange hätten kommen sollen, tatsächlich dort gelandet sind. Besonders wichtig ist der Recall für die kritische Warteschlange: Ein übersehenes dringendes Ticket ist ein Vorfall.

Escalation Rate. Anteil der Tickets, die vom Berater nach dem Routing in eine höhere Warteschlange verschoben wurden. Eine hohe Escalation Rate (über 10-15 %) signalisiert, dass der Klassifikator die Dringlichkeit unterschätzt. Dies ist der Hauptindikator für falsche Depriorisierung.

Re-Classification Rate. Anteil der Tickets, bei denen der Berater die vom Modell vergebene Kategorie geändert hat. Über 20 % für eine bestimmte Kategorie ist ein Signal für Nachschulung oder Überarbeitung der Trainingslabels.

Time-to-First-Response pro Warteschlange vs. SLA. Beschleunigt das Routing tatsächlich die Bearbeitung? Gemessene Zeit vom Eingang des Tickets bis zur ersten Antwort des Beraters, verglichen mit dem SLA für die jeweilige Priorität.

Confidence-Score-Verteilung. Monitoring der Verteilung der Modell-Sicherheit pro Kategorie. Wenn die Kategorie „Billing“ regelmäßig mit einem Confidence von 0,55-0,65 zurückkommt, ist das Modell unsicher und benötigt mehr Trainingsbeispiele oder eine Umformulierung des Prompts.

Ein Pilot im Shadow-Modus mit einem Klassifikator auf Basis von Few-Shot-Prompting kann in 2-4 Wochen gestartet werden, wenn historische Ticketdaten mit Labels vorliegen. Die vollständige Implementierung mit Integration in das Helpdesk-System, Metriken und Eskalationsverfahren dauert 6-12 Wochen. Der Großteil der Zeit entfällt auf das Sammeln und Prüfen von Trainingsdaten sowie die Kalibrierung der Dringlichkeitsschwellen, nicht auf die Programmierung selbst.

Bei thematischen Kategorien und einfachen Dringlichkeitsfällen erreicht KI eine Genauigkeit von 85-92 % bei gut aufbereiteten Daten. Automatisches Routing ohne menschliche Aufsicht ist jedoch nur für risikoarme Klassen sinnvoll (Standardfragen, niedriges Sentiment, bekannte Kategorie). Kritische, rechtliche und Retentions-Tickets erfordern eine menschliche Prüfung. Ziel ist nicht null Berater, sondern die Freisetzung von 60-70 % ihrer Zeit von routinemäßiger Klassifizierung.

Sammeln Sie Tickets dieser Kategorie aus den letzten 30-60 Tagen, prüfen Sie sie mit einem Berater und überprüfen Sie, ob die Labels konsistent waren. Häufige Ursachen: zu enge oder zu breite Kategoriendefinition, überlappende Kategorien (z. B. „Billing“ vs. „Rückerstattung“), zu wenige Trainingsbeispiele (unter 200). Lösung: Präzisierung der Definition, Zusammenführung oder Aufteilung von Kategorien, Hinzufügen weiterer Beispiele, ggf. Ergänzung um negative Beispiele (was diese Kategorie NICHT ist).

Automatische Spracherkennung funktioniert mit über 98 % Genauigkeit für Sprachen mit ausreichend Daten. Die Klassifizierung von Kategorie und Dringlichkeit funktioniert unabhängig von der Sprache, wenn das Basismodell mehrsprachig ist (z. B. BGE-M3 für Embeddings). Das Routing in eine sprachspezifische Warteschlange ist eine einfache Regel basierend auf dem Klassifikator-Output. Probleme treten bei gemischten Sprachen in einem Ticket oder Dialekten auf. Lösung: Flagging zur manuellen Prüfung bei einer Sprach-Confidence unter 0,85.

Für das Training benötigen Sie historische Tickets mit Labels: mindestens 200-500 Beispiele pro Kategorie, mindestens 100-200 pro Dringlichkeitsklasse. Ticket-Daten enthalten oft PII (Name, E-Mail, Kontonummer). Vor dem Training: Anonymisierung oder Pseudonymisierung der Daten, Entfernung personenbezogener Daten aus den Trainingsbeispielen oder deren Maskierung. Wenn Tickets sensible Finanz- oder Gesundheitsdaten enthalten, erwägen Sie Self-Hosting des Modells und führen Sie vor der Implementierung eine DPIA durch.

Verwandte Artikel: KI im Callcenter, Automatisierung des Kundenservice mit KI, Mehrstufige KI-Agenten-Planung, KI zur Content-Moderation. Probieren Sie auch das Tool Agenten-Blueprint aus, um die Architektur Ihres Routing-Systems zu entwerfen.