Support-Tickets automatisch klassifizieren, priorisieren und routen

Ein Kunde schreibt „Rechnung falsch, bitte dringend prüfen” – das Ticket landet in der allgemeinen Posteingangs-Queue, wird dort zwischen fünfzig anderen Anfragen erst am nächsten Tag gesehen und dann manuell an die Buchhaltung weitergeleitet. Zwei Tage Reaktionszeit für etwas, das in Minuten hätte erkannt werden können. Das ist das Alltagsproblem, um das es hier geht: Tickets landen in falschen Queues oder werden zu spät als dringend erkannt, weil die Zuordnung von Kategorie und Priorität heute meist manuell und nach Bauchgefühl passiert.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die eine bestehende Ticketflut strukturieren wollen – nicht an Unternehmen, die noch kein Ticketsystem oder keine wiederkehrenden Supportanfragen haben. Er beantwortet, welche Kategorien sinnvoll sind, wie man Beispieldaten aufbaut, wie man mit unsicheren Fällen umgeht, wie man Fehlrouting misst und wie die Integration ins bestehende Ticketsystem technisch funktioniert. Grundlegenderes zur Automatisierung im Kundenservice insgesamt behandelt der Cluster-Artikel Kundenservice automatisieren, auf den dieser Text aufbaut.

Begriffe kurz geklärt

Klassifikation heißt hier: einem eingehenden Ticket automatisch eine oder mehrere Kategorien zuweisen – Thema, Dringlichkeit, manchmal Sprache oder Kundensegment. Priorisierung ist die Ableitung einer Reihenfolge aus dieser Klassifikation plus zusätzlichen Signalen (Kundenwert, SLA, Formulierung). Routing ist der letzte Schritt: das Ticket landet in der passenden Warteschlange oder bei der zuständigen Person. Alle drei Schritte hängen zusammen, sind aber technisch trennbar – du kannst mit reiner Klassifikation anfangen und Priorisierung/Routing später ergänzen.

Wichtig ist die Abgrenzung nach oben: Automatische Klassifikation ist kein Chatbot und kein automatisches Beantworten. Das System liest ein Ticket und entscheidet, wohin es gehört – es schreibt keine Antwort an den Kunden. Das reduziert Risiko und Komplexität gegenüber einem antwortenden System deutlich, weshalb Klassifikation für viele KMU der naheliegendere erste Schritt ist, bevor sie an automatisierte Antworten überhaupt denken.

Welche Kategorien gibt es?

Die kurze Antwort: Es gibt keine universelle Kategorienliste, die für jedes Unternehmen passt – aber es gibt ein Muster, das sich in den allermeisten Support-Organisationen wiederholt. Zwei Ebenen haben sich in meiner Arbeit bewährt:

Ebene 1 – Thema. Typische Grundkategorien sind Rechnung/Zahlung, technische Störung, Produktfrage, Vertrag/Konditionen, Reklamation, Lieferung/Versand und Sonstiges. Die genaue Liste ergibt sich aus deinem Geschäft: Ein SaaS-Unternehmen braucht „Bug-Report” und „Feature-Anfrage”, ein Händler braucht „Retoure” und „Lieferstatus”. Sonstiges sollte es geben, aber klein bleiben – wenn mehr als 15 % der Tickets dort landen, ist die Kategorienliste unvollständig.

Ebene 2 – Dringlichkeit. Meist reichen drei bis vier Stufen: kritisch (Betrieb steht, Sicherheitsproblem), hoch (spürbare Beeinträchtigung, Fristen), normal (Standardanfrage), niedrig (kann warten). Mehr Stufen klingen präziser, sind in der Praxis aber schwer zu unterscheiden und verwässern die Priorisierung eher, als dass sie sie schärfen.

Zusätzliche Labels wie Sprache oder Kundensegment sind nur sinnvoll, wenn danach tatsächlich unterschiedlich geroutet wird – zum Beispiel weil es ein separates Team für Enterprise-Kunden oder für englischsprachigen Support gibt. Jedes Label, das keine Konsequenz im Routing hat, ist zusätzlicher Aufwand ohne Nutzen.

Die Methode, um zur eigenen Liste zu kommen: die letzten drei bis sechs Monate Tickets exportieren, eine Stichprobe von 100 bis 150 durchsehen und die tatsächlich vorkommenden Themen clustern, statt eine Liste am Reißbrett zu entwerfen. In den Projekten, die ich begleitet habe, weicht die reale Verteilung fast immer von dem ab, was die Beteiligten aus dem Gedächtnis schätzen – meist gibt es zwei oder drei Themen, die einen viel größeren Anteil ausmachen als angenommen, und die genau deshalb zuerst automatisiert werden sollten.

Wie erstellt man Beispieldaten?

Für den Einstieg brauchst du kein eigenes trainiertes Modell und keinen großen Datensatz – die meisten aktuellen Sprachmodelle klassifizieren Text zuverlässig genug, wenn die Kategorien im Prompt klar beschrieben sind. Was du trotzdem brauchst, ist ein Testdatensatz, um zu prüfen, ob das funktioniert, bevor du live gehst.

Praktisches Vorgehen:

1. 200 bis 500 abgeschlossene Tickets exportieren, quer über die letzten Monate, damit saisonale und thematische Schwankungen abgedeckt sind.
2. Von ein bis zwei erfahrenen Support-Personen labeln lassen – nach der finalen Kategorienliste aus dem vorherigen Schritt, nicht nach Bauchgefühl währenddessen.
3. Uneindeutige Fälle gemeinsam klären. Wenn zwei Personen ein Ticket unterschiedlich einordnen, ist das kein Fehler der Personen, sondern ein Hinweis auf eine unscharfe Kategoriengrenze. Diese Fälle notierst du – sie werden später zu den Beispielen im Prompt oder zu Grenzfällen in der Konfusionsmatrix.
4. Set aufteilen: einen Teil zum Prompt-Entwickeln und -Testen nutzen, einen Teil zurückhalten für die spätere Messung (dazu mehr im Abschnitt Fehlrouting).

Ein Hinweis zur Erwartungshaltung: Dieses Set ist ein Testdatensatz für ein vortrainiertes Modell, kein Trainingsdatensatz für ein eigenes Klassifikationsmodell. Ein eigenes Modell zu trainieren lohnt sich für die meisten KMU nicht – der Aufwand für Datenmenge, Infrastruktur und Wartung steht in keinem Verhältnis zum Nutzen gegenüber einem gut instruierten Sprachmodell, das mit wenigen hundert Beispielen bereits gut funktioniert.

Wie behandelt man geringe Sicherheit?

Jedes Klassifikationssystem liefert nicht nur eine Kategorie, sondern im Idealfall auch eine Einschätzung, wie sicher es sich ist – bei Sprachmodellen lässt sich das über eine explizite Selbsteinschätzung im Prompt abfragen oder über strukturierte Ausgabeformate mit Wahrscheinlichkeitswerten. Diese Konfidenz ist der Hebel, mit dem du Automatisierung und menschliche Prüfung sauber trennst.

Das Grundprinzip: Tickets oberhalb einer Sicherheitsschwelle werden automatisch weitergeleitet, Tickets darunter landen in einer Warteschlange zur manuellen Einordnung – nicht als Fehler, sondern als regulärer Teil des Prozesses. Praktisch heißt das:

• Schwelle testweise festlegen, nicht raten. Starte mit einer eher hohen Schwelle (also: lieber mehr Fälle an Menschen geben) und senke sie erst, wenn die Messung aus dem nächsten Abschnitt zeigt, dass auch die unsicheren Fälle meist richtig eingeordnet werden.
• Geringe Sicherheit ist ein Signal, kein Rauschen. Häufen sich unsichere Fälle in einer bestimmten Kategorie, deutet das auf eine unscharfe Kategoriengrenze oder eine untypische Formulierungsweise hin – ein Grund, die Kategorienbeschreibung im Prompt nachzuschärfen, nicht die Schwelle einfach herunterzudrehen.
• Die Warteschlange braucht einen Owner. Ungeprüfte Tickets in einer Konfidenz-Warteschlange, die niemand regelmäßig abarbeitet, sind schlechter als gar keine Automatisierung – dann warten Kunden womöglich länger als vorher.

Der Fehler, den ich am häufigsten sehe: Unternehmen wollen von Anfang an einen möglichst hohen Automatisierungsanteil und setzen die Schwelle entsprechend niedrig. Das Ergebnis sind mehr falsch geroutete Tickets, mehr Frust im Team – und am Ende ein Vertrauensverlust in das gesamte System, der schwerer wiegt als eine anfangs konservativere Automatisierungsquote.

Wie misst man Fehlrouting?

Ohne Messung weißt du nicht, ob die Automatisierung besser oder schlechter ist als die vorherige manuelle Zuordnung – du hast nur ein Gefühl. Das eigene Werkzeug dafür ist die Konfusionsmatrix: eine Tabelle, die für eine Stichprobe manuell geprüfter Tickets zeigt, welche Kategorie das System vergeben hat gegenüber der tatsächlich richtigen Kategorie.

Beispielhafte Konfusionsmatrix (Ausschnitt, Zahlen sind ein illustratives Rechenbeispiel, keine echten Werte):

Tatsächlich \ Vom System vergeben	Rechnung	Störung	Produktfrage	Reklamation
Rechnung	42	1	2	3
Störung	0	55	4	1
Produktfrage	2	6	38	0
Reklamation	5	0	1	33

Eigenes Auswertungsschema Philogic Labs. Zeilen = tatsächliche Kategorie laut manueller Prüfung, Spalten = vom System vergebene Kategorie. Die Diagonale zeigt korrekte Zuordnungen, alles außerhalb zeigt Verwechslungen.

Aus so einer Matrix liest du drei Dinge ab: erstens die Trefferquote je Kategorie (Diagonale geteilt durch Zeilensumme), zweitens die am häufigsten verwechselten Kategorien-Paare (hier zum Beispiel „Produktfrage” wird auffällig oft als „Störung” eingeordnet – ein Hinweis, dass die Abgrenzung zwischen beiden im Prompt geschärft werden muss), drittens ob Fehler gleichmäßig verteilt sind oder sich auf wenige Kategorien konzentrieren.

Praktisches Vorgehen für die laufende Messung:

1. Feste Stichprobe pro Woche oder Monat manuell nachprüfen – zum Beispiel 50 zufällig gezogene Tickets, unabhängig davon, ob sie automatisiert oder manuell geroutet wurden.
2. Konfusionsmatrix aktualisieren und mit der Vorwoche/dem Vormonat vergleichen.
3. Schwellenwert und Kategorienbeschreibungen nachjustieren, wenn sich systematische Muster zeigen – nicht bei jedem Einzelfehler, sondern bei wiederkehrenden Mustern.
4. Baseline nicht vergessen: Miss vor der Umstellung auch die Fehlerquote des bisherigen manuellen Routings, sonst fehlt der Vergleichsmaßstab. In den meisten Support-Teams, die ich kenne, wird diese Zahl nie erhoben – Fehlrouting durch Menschen fällt schlicht seltener auf, weil niemand systematisch nachprüft.

Diese Messlogik lässt sich auch auf andere Kundenservice-Kennzahlen übertragen; eine breitere Einordnung, welche KPIs für Automatisierung im Kundenservice insgesamt sinnvoll sind, findet sich im entsprechenden Cluster-Artikel.

Wie integriert man das Ticketsystem?

Die technische Integration ist in den meisten Fällen der unkritischste Teil des Projekts – vorausgesetzt, das bestehende Ticketsystem bietet eine API oder Automatisierungsanbindung, was bei den gängigen Systemen im KMU-Umfeld heute Standard ist. Der typische Ablauf:

1. Trigger: Ein neues Ticket entsteht (per E-Mail, Formular, Chat) und löst einen Aufruf an die Klassifikationslogik aus – entweder über einen Webhook des Ticketsystems oder über eine Automatisierungsplattform, die zwischen Ticketsystem und Sprachmodell vermittelt.
2. Klassifikation: Das Sprachmodell erhält Ticketinhalt plus Kategorienbeschreibung im Prompt und gibt Kategorie, Dringlichkeit und Konfidenzwert strukturiert zurück (z. B. als JSON).
3. Entscheidung: Liegt die Konfidenz über der Schwelle, setzt das System die Felder im Ticketsystem automatisch und weist die passende Warteschlange zu. Liegt sie darunter, geht das Ticket in die Prüf-Warteschlange, ggf. mit einem Vorschlag als Hilfestellung für die Person, die es manuell einordnet.
4. Rückmeldeschleife: Korrekturen, die Menschen an automatisch vergebenen Kategorien vornehmen, werden protokolliert – diese Daten sind die Grundlage für die Konfusionsmatrix und für spätere Anpassungen der Kategorienbeschreibung.

Ein Routing-Flow lässt sich als einfaches eigenes Schema zusammenfassen:

Routing-Flow (eigenes Modell Philogic Labs):

Neues Ticket
   → Klassifikation (Kategorie, Dringlichkeit, Konfidenz)
      → Konfidenz ≥ Schwelle?
         → Ja: automatisches Setzen von Kategorie/Queue → zuständiges Team
         → Nein: Prüf-Warteschlange mit Systemvorschlag → Mensch entscheidet
   → Korrektur protokollieren (auch bei automatischer Zuordnung, falls später korrigiert)
   → Regelmäßige Stichprobe in Konfusionsmatrix einspeisen

Was du dabei technisch nicht brauchst: eine Ablösung des bestehenden Ticketsystems. Fast jedes verbreitete System (klassische Helpdesk-Software wie auch generische Ticket-/CRM-Lösungen) bietet Felder für Kategorie und Priorität sowie eine Schnittstelle, über die sich diese Felder automatisiert setzen lassen. Die Klassifikationslogik ist eine vorgeschaltete Komponente, kein Ersatz für das System, in dem dein Team ohnehin arbeitet.

Umsetzung: Vorgehen Schritt für Schritt

Zusammengeführt ergibt sich ein Vorgehen in vier Schritten, das sich in der Praxis bewährt hat:

1. Kategorien und Beispieldaten erarbeiten (siehe oben) – typischer Aufwand: wenige Tage bis zwei Wochen, abhängig davon, wie schnell Zugriff auf historische Tickets besteht und wie viele Personen am Labeling beteiligt sind.
2. Prompt und Schwellenwert entwickeln und gegen den zurückgehaltenen Testdatensatz prüfen, bevor irgendetwas live geht. Hier zeigt sich meist schon, welche Kategorien im ersten Anlauf schlecht funktionieren.
3. Pilot mit einem Teilbereich – zum Beispiel nur eine Produktlinie oder nur ein Kanal (etwa E-Mail, nicht Chat) – über mehrere Wochen parallel zum bestehenden Prozess laufen lassen, mit der wöchentlichen Stichprobenmessung aus dem Fehlrouting-Abschnitt.
4. Ausrollen, wenn die Trefferquote im Pilot stabil über der des bisherigen manuellen Prozesses liegt, und danach kontinuierlich nachjustieren – ein Klassifikationssystem ist nie endgültig fertig, weil sich Produkte, Formulierungen und Themen im Zeitverlauf ändern.

Als grobe Bandbreite für ein KMU mit einem bestehenden Ticketsystem, überschaubarer Kategorienzahl (fünf bis zehn) und vorhandenem API-Zugang: Aufbau und Pilot lassen sich häufig in vier bis zehn Wochen durchlaufen, wobei die größte Schwankung nicht an der Technik liegt, sondern daran, wie schnell historische Daten verfügbar sind und wie viel Zeit die Support-Leitung fürs Labeling und die Auswertung der Stichproben aufbringen kann. Das ist eine Einschätzung aus eigenen Projekten, keine allgemeingültige Zusage.

Risiken & Grenzen

Falsch klassifizierte kritische Tickets. Der teuerste Fehler ist nicht die Verwechslung zwischen zwei ähnlichen Themenkategorien, sondern wenn ein tatsächlich kritisches Ticket als niedrig priorisiert wird. Deshalb lohnt es sich, für die Dringlichkeitsstufe „kritisch” eine bewusst niedrigere Konfidenzschwelle zu setzen als für Themenkategorien – im Zweifel lieber ein normales Ticket als dringend behandeln als umgekehrt.

Datenschutz bei der Verarbeitung von Ticketinhalten. Support-Tickets enthalten häufig personenbezogene und teils sensible Daten (Namen, Vertragsdaten, manchmal Gesundheits- oder Zahlungsinformationen). Die Datenschutzkonferenz weist in ihrer Orientierungshilfe zu KI-Systemen mit Retrieval Augmented Generation darauf hin, dass eine datenschutzkonforme Gestaltung von Anfang an nötig ist, mit einer Einzelfallbewertung der jeweiligen Datenverarbeitung und laufend aktualisierten technisch-organisatorischen Maßnahmen. Praktisch heißt das für ein Klassifikationssystem: prüfen, welcher Anbieter die Ticketinhalte verarbeitet, ob und wie lange sie gespeichert werden, und ob ein Auftragsverarbeitungsvertrag vorliegt. Das BSI empfiehlt in seinem Management Blitzlicht zu generativer KI zusätzlich, den Datenschutzbeauftragten von Anfang an einzubinden und eine schriftliche KI-Richtlinie zu haben, die festlegt, wer welche Systeme mit welchen Daten nutzen darf. Stand Juli 2026 – keine Rechtsberatung; im Zweifel gehört die konkrete Prüfung zu deinem Datenschutzbeauftragten oder einer entsprechenden Beratung.

Verzerrte oder unvollständige Trainingsbasis. Wenn deine Beispieldaten nur aus einem Kanal oder einer Kundengruppe stammen, funktioniert die Klassifikation für andere Kanäle oder Gruppen schlechter. Deshalb der Hinweis oben, Beispieldaten über mehrere Monate und – wo vorhanden – über verschiedene Kanäle zu ziehen.

Automatisierungsquoten sind kein Versprechen. Wie viele Tickets sich am Ende automatisch korrekt einordnen lassen, hängt stark von der Ticketstruktur deines Unternehmens ab. Ein im Zapier-Blog beschriebenes Beispiel zeigt, dass ein Unternehmen mit rund 1.800 Beschäftigten und monatlich etwa 1.100 Tickets in einem KI-gestützten Workflow einen Teil seiner Tickets automatisch bearbeiten ließ – das ist ein einzelnes Fallbeispiel eines Anbieters, keine belastbare Quote für dein Unternehmen. Verlass dich auf deine eigene Konfusionsmatrix, nicht auf fremde Kennzahlen.

Grenze: Klassifikation ersetzt kein Prozessproblem. Wenn dein eigentliches Problem ist, dass zu wenig Personal im Support arbeitet oder die Produktdokumentation lückenhaft ist, löst eine bessere Zuordnung der Tickets dieses Problem nicht – sie sorgt nur dafür, dass die vorhandene Kapazität die richtigen Tickets zuerst sieht.

Checkliste: Support-Tickets automatisch klassifizieren

1. Kategorienliste aus realen Tickets der letzten drei bis sechs Monate abgeleitet, nicht am Reißbrett entworfen.
2. Dringlichkeitsstufen auf drei bis vier begrenzt, mit klarer Definition je Stufe.
3. Testdatensatz von 200 bis 500 gelabelten Tickets vorhanden, von erfahrenen Support-Personen erstellt.
4. Konfidenzschwelle testweise festgelegt, für „kritisch” bewusst niedriger als für Themenkategorien.
5. Prüf-Warteschlange für unsichere Fälle eingerichtet und mit einem Owner versehen.
6. Konfusionsmatrix als regelmäßige Stichprobenmessung etabliert, inklusive Baseline des bisherigen manuellen Prozesses.
7. Integration über bestehende API/Webhooks des Ticketsystems geprüft – keine Systemablösung nötig.
8. Datenschutz geklärt: Anbieterprüfung, Auftragsverarbeitung, Einbindung des Datenschutzbeauftragten.
9. Pilot auf einen Teilbereich (Kanal oder Produktlinie) begrenzt, bevor unternehmensweit ausgerollt wird.
10. Rückmeldeschleife für manuelle Korrekturen eingerichtet, um Kategorienbeschreibung laufend nachzuschärfen.

Wenn du diesen Weg nicht allein gehen willst: Unser Beratungsangebot unterstützt bei Kategorienlogik, Pilotaufbau und Integration, und ein kostenloses Erstgespräch klärt, ob eine Klassifikationslösung für euer Ticketaufkommen der richtige nächste Schritt ist. Weitere Grundlagen zur Automatisierung im Kundenservice findest du im Themen-Cluster Kundenservice.