Tickets klassifizieren mit KI: Service-Triage im technischen Kundendienst

Tickets klassifizieren mit KI heißt, dass ein KI-Agent jede eingehende E-Mail, Portalmeldung und Telefonnotiz nach einem festen Schema einordnet, zu jeder Einordnung eine Konfidenz angibt und den Fall mit Kontext an das zuständige Team leitet. Der Kunde schreibt weiter an das Service-Postfach, und Ihre Servicekräfte antworten weiter selbst; der Agent arbeitet zwischen Posteingang und Ticketsystem.

Dabei folgt er derselben Mechanik wie jeder Workflow mit Agenten, also Eingang, Kontext, Vorschlag, Freigabe und Rückschreiben. Er liest Text und Anhänge, zieht Kunden-, Anlagen- und Vertragsdaten, setzt Kategorie, Priorität und Team und entwirft bei Routinefällen eine Antwort. Ein Mensch gibt frei, anschließend schreibt der Agent das Ergebnis ins Ticketsystem. Den ganzen Workflow mit Freigabestufen und Kennzahlen beschreibt die Seite zur Service-Triage.

Ein KI-Service-Desk in diesem Sinn ist kein Chatbot. Der Chatbot spricht mit Kunden, der Agent bereitet Arbeit für die Menschen vor, die mit Kunden sprechen. Deshalb verlässt keine Aussage zu Anlagen, Reaktionszeiten oder Haftung das Haus, ohne dass eine Servicekraft sie gelesen hat.

Schlagwortregeln reagieren auf einzelne Begriffe. Sie unterscheiden deshalb nicht zuverlässig zwischen einer dringenden Ersatzteilbestellung und dem Stillstand einer Fertigungslinie. Auch zitierte Nachrichten oder eine Signatur können eine falsche Zuordnung auslösen.

Ein Sprachmodell kann den gesamten Inhalt und die verfügbaren Anlagendaten für einen Zuordnungsvorschlag berücksichtigen. Ob es die Fälle korrekt einordnet, muss an einer repräsentativen Stichprobe geprüft werden. Besonders anspruchsvoll sind folgende Muster:

Ein Schema für die Ticket-Klassifikation braucht fünf Felder, jedes mit einer geschlossenen Werteliste und einer festgelegten Quelle: Art, Dringlichkeit, Produkt oder Anlage, Kunde und Vertrag sowie Sprache. Geschlossen heißt, dass der Agent nur Werte aus der Liste vergibt und „Sonstiges“ ein ausdrücklicher Wert ist, kein Fehler.

Am deutlichsten zeigt sich der Unterschied zu Schlagwortregeln bei der Dringlichkeit. Der Agent leitet sie aus dem beschriebenen Anlagenzustand und der Reaktionszeit im Servicevertrag ab, sodass ein Stillstand bei einem Vertragskunden vor einer Planungsanfrage landet, auch wenn nur die Planungsanfrage „dringend“ im Betreff trägt.

Die Werte folgen den Teams, die handeln, nicht dem Organigramm. Landen Ersatzteilanfragen und Wartungstermine im selben Team, reicht für das Routing eine Kategorie, auch wenn die Auswertung zwei sehen will. Testen Sie das Schema, bevor der Agent es bekommt: Zwei erfahrene Disponenten ordnen unabhängig voneinander dieselbe Stichprobe historischer Tickets ein. Wo die beiden sich uneinig sind, ist das Schema unklar, und kein Modell wird es klarer machen.

Das Sprachmodell erhält die Anfrage mit Anhängen, die Definitionen des Schemas und Beispiele je Kategorie und gibt für jedes Feld einen Wert aus der Liste und eine Konfidenz zurück, als strukturierte Ausgabe, die das Ticketsystem direkt übernimmt. Was danach passiert, entscheidet ein Schwellenwert je Kategorie, nicht das Modell.

Die Konfidenz ist nur so viel wert wie ihre Kalibrierung. Eine Angabe von 0,9 bedeutet erst dann etwas, wenn im Testset neun von zehn Tickets mit diesem Wert richtig eingeordnet waren; deshalb wird jede Konfidenz gegen echte, von Menschen eingeordnete Tickets geprüft. Die Schwellenwerte unterscheiden sich je Kategorie, denn eine Dokumentationsanfrage darf bei niedrigerer Konfidenz automatisch geroutet werden als eine Störung an einer Anlage, für die der Vertrag etwa vier Stunden Reaktionszeit zusichert.

Unter dem Schwellenwert entsteht kein Antwortentwurf. Der Fall landet in der Warteschlange eines Disponenten, mit den beiden Kategorien, zwischen denen der Agent geschwankt hat, und dem bereits gezogenen Kontext, sodass der Mensch nur noch entscheidet und nicht mehr sucht. Wie Sie solche Freigabepunkte schneiden, beschreibt der Leitfaden zu Human in the Loop.

Vor dem Go-live läuft der Agent einige Wochen im Schattenbetrieb. Er klassifiziert jedes Ticket parallel, die Disponenten routen wie bisher, und der Vergleich zeigt die Fehlzuordnung je Kategorie. Aus diesem Vergleich werden die Schwellenwerte gesetzt, nicht aus einer Schätzung. Weil das Modell den Inhalt liest, statt Wörter abzugleichen, gilt dieselbe Klassifikation für deutsche, englische und italienische Anfragen, sofern das Testset alle drei Sprachen enthält.

Die Klassifikation entscheidet, wer das Ticket bekommt; die Anreicherung entscheidet, wie schnell diese Person antworten kann. Der Agent hängt Anlagenhistorie, Vertrag und offene Aufträge an das Ticket, bevor ein Mensch es öffnet, und ersetzt damit die Suche in CRM, ERP und Archiv, die sonst vor der Antwort steht.

Einen Antwortentwurf legt er nur über dem Schwellenwert an und nur in Kategorien, die für Entwürfe freigegeben sind. Jede Aussage darin verweist auf ihre Quelle, etwa den Servicebericht vom letzten Einsatz oder das Kapitel der Betriebsanleitung. Fehlt eine Angabe wie die Seriennummer, entwirft der Agent statt einer Antwort eine Rückfrage an den Kunden, die ebenfalls ein Mensch freigibt. Für ein technisches Service-Ticket zieht der Agent typischerweise vier Arten von Kontext:

Für ein Ticketsystem mit KI-Unterstützung müssen Sie das System nicht wechseln. Sie brauchen einen Agenten, der über die vorhandene Schnittstelle liest und eng begrenzt zurückschreibt. ServiceNow, Jira Service Management, Zendesk und SAP Service Cloud dokumentieren Programmierschnittstellen, über die sich Tickets lesen und aktualisieren lassen; welche Rechte ein technischer Benutzer dabei hat, regeln Rollen und Berechtigungen im jeweiligen System.

Der Agent setzt Kategorie, Priorität und Zuweisungsgruppe, legt eine interne Notiz mit seinen Quellen an und hinterlegt bei freigegebenen Kategorien einen Antwortentwurf. Versenden, schließen oder andere Felder ändern kann er nicht, weil die Rechte seines technischen Kontos und die Integrationsschicht, die nur die freigegebenen Felder durchreicht, es verhindern. Kommt eine Anfrage per E-Mail, liest er das Ticket, das das System aus der Nachricht angelegt hat, samt Fotos, PDF-Serviceberichten und Tabellen im Anhang.

Im Workflow Build entsteht diese Integration in Ihrer eigenen Cloud-Umgebung und Ihrer Versionsverwaltung, mit Testset, Schattenbetrieb und Protokollierung, ohne zusätzliche Cortaris-Plattformlizenz.

Reklamationen, Sicherheitsthemen und Vertragsfragen gehen immer an einen Menschen, unabhängig von der Konfidenz. Der Agent klassifiziert und reichert auch diese Fälle an, entwirft aber keine Antwort, und das Routing auf die benannte Rolle ist fest verdrahtet statt vom Schwellenwert abhängig. Reklamationen landen mit vorbereiteter Fallakte im Reklamationsteam; wie dieser Prozess aufgebaut ist, beschreibt der Leitfaden zum Reklamationsmanagement.

Der übrige Kontrollrahmen regelt Berechtigungen, Protokollierung und Eskalation. Der Agent liest CRM, ERP und Dokumentation und schreibt nur ins Ticketsystem, dort nur in die freigegebenen Felder. Je Fall werden Eingang, gezogene Quellen, Vorschlag, Konfidenz und Freigabe mit Name und Zeitpunkt protokolliert. Eskaliert der Agent, nennt er den Grund in der internen Notiz, etwa „Sicherheitsthema erkannt“ oder „Absender unbekannt“, damit die monatliche Auswertung zeigt, welche Regel wie oft greift. Diese Fälle laufen nie automatisch:

Ob die Triage funktioniert, zeigen vier Kennzahlen, gemessen gegen einen Basiswert aus der Zeit vor dem Agenten: Fehlzuordnungsquote, Zeit bis zur ersten Antwort, Anteil ohne Änderung freigegebener Entwürfe und Wiedereröffnungsquote. Den Basiswert liefert die Ticket-Historie der letzten Monate; im Workflow Assessment erheben wir genau diese Werte, bevor gebaut wird. Ob sich Ihr Service-Postfach als erster Workflow eignet, prüft der Workflow-Check mit zehn Fragen.

Messen Sie den Workflow, nicht einzelne Servicekräfte. Sobald Kennzahlen je Person ausgewertet werden, berührt das die Mitbestimmung des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG über technische Einrichtungen, die Verhalten oder Leistung überwachen. Anhang III Nr. 4 Buchstabe b der KI-Verordnung nennt zudem KI-Systeme als hochriskant, die Aufgaben nach individuellem Verhalten zuweisen oder die Leistung von Beschäftigten bewerten. Ein Agent, der Tickets nach Inhalt an Teams routet, ist dafür nicht gebaut; die Einstufung bleibt trotzdem bei Ihrer Compliance.