Support-Tickets automatisch klassifizieren, priorisieren und routen

Das Wichtigste in Kürze: Support-Tickets automatisch klassifizieren: Kategorien, Beispieldaten, Umgang mit geringer Sicherheit, Fehlrouting messen und Ticketsystem-Integration.

Ein Kunde schreibt „Rechnung falsch, bitte dringend prüfen“. Das Ticket landet in der allgemeinen Posteingangs-Queue. Dort wird es zwischen 50 anderen Anfragen erst am nächsten Tag gesehen und dann manuell an die Buchhaltung weitergeleitet. 2 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. Der Grund: Die Zuordnung von Kategorie und Priorität passiert heute meist manuell und nach Bauchgefühl.

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. Diese 3 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. Deshalb ist Klassifikation für viele KMU der naheliegendere erste Schritt, 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 meisten Support-Organisationen wiederholt. 2 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 3 bis 4 Stufen: kritisch (Betrieb steht, Sicherheitsproblem), hoch (spürbare Beeinträchtigung, Fristen), normal (Standardanfrage), niedrig (kann warten). Mehr Stufen klingen präziser. Sie 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 3 bis 6 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 2 oder 3 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. Ein gut instruiertes Sprachmodell funktioniert bereits mit wenigen hundert Beispielen gut.

Wie behandelt man geringe Sicherheit?

Jedes Klassifikationssystem liefert nicht nur eine Kategorie. Im Idealfall liefert es 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. 3 Punkte sind dabei praktisch wichtig:

• Schwelle testweise festlegen, nicht raten. Starte mit einer eher hohen Schwelle, also lieber mehr Fälle an Menschen geben. 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 Kategorie, deutet das auf eine unscharfe Kategoriengrenze oder eine untypische Formulierung hin. Das ist 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 3 Dinge ab. Erstens die Trefferquote je Kategorie (Diagonale geteilt durch Zeilensumme). Zweitens die am häufigsten verwechselten Kategorien-Paare, hier zum Beispiel wird „Produktfrage“ auffällig oft als „Störung“ eingeordnet, ein Hinweis, dass die Abgrenzung 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. Voraussetzung: Das bestehende Ticketsystem bietet eine API oder Automatisierungsanbindung, was bei gängigen Systemen im KMU-Umfeld heute Standard ist. Der typische Ablauf besteht aus 4 Schritten:

1. Trigger: Ein neues Ticket entsteht (per E-Mail, Formular, Chat) und löst einen Aufruf an die Klassifikationslogik aus. Das läuft 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, zum Beispiel 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, gegebenenfalls 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):

1. Ein neues Ticket entsteht.
2. Die Klassifikation vergibt Kategorie, Dringlichkeit und Konfidenz.
3. Bei hoher Konfidenz setzt das System Kategorie und Queue automatisch und leitet an das zuständige Team weiter.
4. Bei niedriger Konfidenz geht das Ticket mit Systemvorschlag in die Prüf-Warteschlange, ein Mensch entscheidet.
5. Jede Korrektur wird protokolliert, auch bei automatischer Zuordnung.
6. Eine regelmäßige Stichprobe fließt in die Konfusionsmatrix ein.

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 wöchentlicher Stichprobenmessung aus dem Fehlrouting-Abschnitt.

4. Ausrollen, wenn die Trefferquote im Pilot stabil über der des bisherigen manuellen Prozesses liegt. 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 bestehendem Ticketsystem, überschaubarer Kategorienzahl (5 bis 10) und vorhandenem API-Zugang: Aufbau und Pilot lassen sich häufig in 4 bis 10 Wochen durchlaufen. Die größte Schwankung liegt dabei nicht an der Technik. Sie liegt 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 RAG-Systemen darauf hin: Eine datenschutzkonforme Gestaltung ist von Anfang an nötig, mit Einzelfallbewertung 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 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.

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: Ein Unternehmen mit rund 1.800 Beschäftigten und monatlich etwa 1.100 Tickets ließ in einem KI-gestützten Workflow einen Teil seiner Tickets automatisch bearbeiten. 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. Arbeitet zu wenig Personal im Support oder ist die Produktdokumentation lückenhaft, 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.

Willst du diesen Weg nicht allein gehen? Unser Beratungsangebot unterstützt bei Kategorienlogik, Pilotaufbau und Integration. 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.