Textklassifikation & Weiterleitung (E-Mails, Tickets, Anfragen)

Gemeinsame Postfächer, Service Desks und Bürgerportale erhalten Tausende Freitextanfragen in vielen Sprachen. Jemand muss jede einzelne lesen, erkennen, worum es geht und wie dringend sie ist, und sie an das richtige Team weitergeben. Ein Klassifikator erledigt diese erste Sichtung in Millisekunden. Er sagt Thema, Absicht, Priorität und Sprache voraus, hängt einen Konfidenzwert an und leitet die Nachricht entweder automatisch weiter oder legt sie in eine kurze Prüfwarteschlange. Das Ergebnis sind weniger fehlgeleitete Tickets, schnellere Erstantworten und Disponenten, die für echte Arbeit frei werden. Das ist das Rückgrat, auf dem Antwort-Agenten (AGENT-001) und Chatbots (CONV-001) aufbauen.

Problem & Nutzen

• Heute: Disponenten oder Mitarbeitende der ersten Ebene sortieren von Hand, oft mit brüchigen Schlagwortregeln im Helpdesk- oder Mailsystem. Fehlgeleitete Tickets wandern zwischen Teams hin und her, was die SLAs belastet. Dringende Vorgänge wie Beschwerden, Kündigungen, Rechtsdrohungen und DSGVO-Anfragen gehen unter. Mehrsprachige Eingaben verschärfen das.
• KI-Nutzen: einheitliche Kennzeichnungen rund um die Uhr, Weiterleitung nahezu in Echtzeit, Priorisierung nach Dringlichkeit und Kundenwert, strukturierte Daten für Berichte (welche Themen das Volumen treiben) und ein sauberer Auslöser für nachgelagerte Automatisierung.
• Belege: Helpdesk-Anbieter liefern Klassifikation inzwischen serienmäßig aus. Die intelligente Triage von Zendesk sagt Thema, Stimmung und Sprache (etwa 150 Sprachen) mit einem Konfidenzwert voraus, und diese Felder speisen Workflows für Weiterleitung und Priorisierung [1]. ServiceNow Predictive Intelligence sagt die Kategorie von Störungen voraus und berichtet Präzision und Abdeckung je Lösung [2]. In einer Masterarbeit der JKU von 2024 zu IT-Tickets beim österreichischen Schalungshersteller Doka schlugen feingetunte GPT-Modelle feingetunte BERT-Modelle bei 4 von 5 Ticketattributen, und Datenaugmentierung verringerte den Abstand [3]. Veröffentlichte Angaben von Herstellern zur "Weiterleitungsgenauigkeit" sind selten vergleichbar, messen Sie daher mit Ihren eigenen Daten.

Varianten

• Kundenservice (B2C/B2B): Klassifikation von Absicht und Priorität in Zendesk, Freshdesk, Salesforce Service Cloud, HubSpot oder Microsoft Dynamics. Typische Kennzeichnungen sind Bestellstatus, Retoure, Rechnungsfrage, Kündigung, Beschwerde und technische Störung.
• IT-Service-Management: Kategorie, Zuweisungsgruppe und Priorität für Störungen und Anfragen (ServiceNow, Jira Service Management, TOPdesk). Die autonome Lösung ist in AGENT-016 behandelt.
• Gemeinsame Postfächer im Backoffice: info@, buchhaltung@ und einkauf@ werden aufgeteilt in Bestellung, Rechnung, Mahnung, Lieferschein und Spam. Anhänge laufen durch die Eingangsverarbeitung DOC-008.
• Versicherer, Versorger, Telekommunikation: hohes Volumen schriftlicher Kundenkommunikation (Adressänderung, Zählerstand, Schadenmeldung, Kündigung) mit gesetzlichen Fristen. Die Klassifikation speist das Fallmanagement.
• Öffentlicher Sektor: Bürgeranfragen, die über OZG-Portale, E-Mail und Briefe eingehen, werden an die zuständige Stelle weitergeleitet (Logik eines Zuständigkeitsfinders). Der Front-End-Chatbot ist CONV-011, und die Triage von Notrufen ist der eigene Hochrisiko-Anwendungsfall CONV-021.
• Hinweisgeber- und Ethik-Hotline (regulierte Variante): Meldungen über einen Kanal nach HinSchG / EU-Richtlinie 2019/1937 werden übersetzt, zusammengefasst, von Dubletten befreit, klassifiziert (Betrug, Belästigung, Datenschutz, Wettbewerbsrecht) und an die zuständige Fallbearbeitung weitergeleitet. Die besonderen Anforderungen sind die Vertraulichkeit der Identität der meldenden Person, Verarbeitung ausschließlich in der EU, Anonymisierung vor weiterer Verteilung (DOC-018), strikte rollenbasierte Zugriffe und die gesetzlichen Fristen: Eingangsbestätigung innerhalb von 7 Tagen und Rückmeldung innerhalb von 3 Monaten (§ 17 HinSchG) [4]. Anbieter (z. B. EQS Integrity Line, Hintbox, LegalTegrity, alle mit Sitz in der EU) bewerben KI-gestützte Triage, doch gemessene Ergebnisse wurden nicht unabhängig veröffentlicht. Setzen Sie KI nur zur Vorbereitung ein und belassen Sie die Fallentscheidung beim Menschen.
• Entwickler / Open-Source-Maintainer: Kennzeichnen von GitHub-Issues und Pull Requests. Das Nachstellen und Beheben von Fehlern ist CODE-014.
• Private Nutzung: Mail-Sortierung aus Regeln plus KI in Add-ons für Gmail, Outlook oder Thunderbird. Braucht selten eine eigene Lösung.

So funktioniert es

1. Eingang (IMAP/Graph API, Helpdesk-Webhook, Portalformular, Chat)
2. Vorverarbeitung (Signaturen/zitierten Verlauf entfernen, Sprache erkennen, PII-Maskierung bei Bedarf)
3. optional: in Pivot-Sprache übersetzen (LANG-009)
4. Klassifikation ├─ Schnellpfad: feingetunter Encoder (ModernBERT / mmBERT / XLM-R) oder SetFit-Modell └─ schwierige/neue Fälle: LLM mit Kennzeichnungsdefinitionen + Few-Shot-Beispielen, abgerufen aus ähnlichen früheren Tickets (kNN über Embeddings), strukturierte JSON-Ausgabe
5. Konfidenzkalibrierung & Geschäftsregeln (VIP, SLA, Schlüsselwörter für Recht/DSGVO)
6. Weiterleitung: Warteschlange/Zuweisungsgruppe/Priorität setzen, Workflow auslösen (n8n, Power Automate)
7. Prüfung durch Menschen bei Fällen mit geringer Konfidenz
8. Korrekturen fließen als Trainingslabels zurück

• Das Design der Kennzeichnungen ist wichtiger als das Modell. Halten Sie Kennzeichnungen gegenseitig ausschließend oder ausdrücklich mehrfach vergebbar, schreiben Sie zu jeder eine einzeilige Definition plus Beispiele und ergänzen Sie eine Klasse "Sonstiges/unklar".
• Hybride Kaskade: Ein kleiner Encoder verarbeitet die große Masse günstig. Ein LLM übernimmt den langen Schwanz, neue Kategorien und Nachrichten, die Schlussfolgern erfordern (z. B. "Ist das eine Beschwerde oder eine Kündigung?"). Kleine LLMs (3–8B) können auch direkt als Weiterleiter dienen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Schwellenwerte je Kennzeichnung; alles darunter geht an eine Disponentin oder einen Disponenten. Mitarbeitende können Kennzeichnungen im Helpdesk korrigieren, und diese Korrekturen werden zum nächsten Trainingsdatensatz. Regelmäßige Stichproben automatisch weitergeleiteter Vorgänge fangen schleichende Abweichungen (Drift) ab.

Datenaufbereitung

Die Daten stammen aus dem gemeinsamen Postfach (Exchange, IMAP), dem Helpdesk- oder ITSM-System, Webformularen und Chat-Protokollen. Das zentrale Gut ist die Historie: frühere Tickets mit ihrer endgültigen Warteschlange, Kategorie und Priorität. Das Wissen über Weiterleitungsregeln steckt oft nur in den Köpfen des Service-Teams.

Typische Lücken sind uneinheitliche oder zu viele Kategorien, Kennzeichnungen, die die erste Vermutung statt des Endergebnisses abbilden, mehrfach umgeleitete Tickets, Signaturen, zitierte Verläufe und Haftungsausschlüsse im Text, Dubletten und personenbezogene Daten im Freitext. Mehrere Sprachen und Anhänge bringen zusätzliches Rauschen.

Aufbereitungsschritte: 1. Ein Kategorienschema mit 10 bis 30 Klassen und klaren Definitionen festlegen (PREP-019). 2. Tickets über API oder Mail-Export exportieren (PREP-005) und Kennzeichnungen aus der endgültigen Warteschlange und der Lösung gewinnen (PREP-020). 3. Text bereinigen: Signaturen und zitierte Antworten entfernen, Dubletten löschen, Namen und IBANs maskieren (PREP-022). 4. Von Fachleuten eine Testmenge von 300 bis 500 Tickets kennzeichnen lassen (PREP-018). 5. Die Korrekturen der Mitarbeitenden an KI-Kennzeichnungen fortlaufend erfassen (PREP-021).

Aufwand: hoch, etwa 40 bis 50 Prozent des Projekts, vor allem für Kategoriedesign und Bereinigung der Kennzeichnungen. Ohne diesen Schritt bleibt die Genauigkeit deutlich unter dem, was das Modell leisten könnte.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil Helpdesk- und Shared-Inbox-Produkte bereits in der EU gehostete automatische Triage anbieten und die Weiterleitungsregeln Standard sind.
• Großunternehmen: Weg B, weil Volumen, mehrere Sprachen und die Anbindung an ITSM oder CRM einen eigenen Klassifikator auf Cloud-APIs begünstigen, der mit historischen Tickets trainiert wird.
• Entwickler: Weg B, weil LLM- oder Embedding-APIs mit einer gekennzeichneten Testmenge Entwicklern erlauben, schnell einen Weiterleitungsdienst zu bauen.
• Öffentlicher Sektor: Weg C, weil Bürgeranfragen personenbezogene Daten enthalten und ein selbst betriebener Klassifikator auf EU-Infrastruktur die Kontrolle erhält und die Vergaberegeln erfüllt.

Weg A — Kaufen (Standardsoftware, für die meisten KMU empfohlen)

• In Helpdesk/ITSM eingebaut: Zendesk intelligente Triage (Copilot-Add-on) [1], Freshdesk Freddy AI, Salesforce Einstein for Service, HubSpot Service Hub, Microsoft Dynamics 365 Contact Center, ServiceNow Predictive Intelligence / Now Assist [2], Jira Service Management, TOPdesk (NL).
• EU-/deutsche Suiten für E-Mail-Beantwortung und Eingangsverarbeitung: novomind iAGENT (Hamburg) [5], Insiders Technologies Response Management / OvAItion (Kaiserslautern, Teil von Proalpha) [6], ITyX (Köln), Userlike / Cognigy für chatzentrierte Abläufe. Prüfen Sie EU-Hosting, eine On-Premises-Option, die Qualität im Deutschen und Anbindungen an SAP, DMS und CRM.
• A wählen, wenn: Ihr Helpdesk es bereits anbietet, die Kennzeichnungen Standard sind und das Volumen mäßig ist. Rechnen Sie mit Konfiguration (eigene Themen, Weiterleitungsregeln) statt Entwicklung.

Weg B — Auf Cloud-KI-Diensten aufbauen

• LLM-Klassifikation: Ein führendes oder mittelgroßes Modell mit Definitionen der Kennzeichnungen und Beispielen ansprechen und die Ausgabe auf ein JSON-Schema festlegen. Optionen sind Mistral (EU-Anbieter, z. B. Mistral Small/Medium), Claude über AWS Bedrock oder Google Vertex in EU-Regionen, GPT über die Azure OpenAI EU Data Zone und Gemini auf Vertex AI EU. Der Leitfaden von Anthropic zur Ticket-Weiterleitung ist eine nützliche Referenz für Prompt-Design und Bewertung [7].
• Klassische verwaltete Klassifikatoren: Azure AI Language mit eigener Textklassifikation (Einzel-/Mehrfachlabel) funktioniert weiterhin. Microsoft hat die Abkündigung zum 31. März 2029 angekündigt und verweist neue Projekte auf Foundry-Modelle, starten Sie darauf also keine neuen langlebigen Projekte [8]. Das frühere Feintuning über Mistrals Classifier Factory ist als veraltet gekennzeichnet [9].
• Kostenkontrolle: Mit einem kleinen/günstigen Modell klassifizieren, nur bei niedriger Konfidenz an ein größeres eskalieren und nach Verlauf zwischenspeichern. Prompt-Caching der langen Definitionen der Kennzeichnungen hilft.
• Integration: Helpdesk-Webhooks oder Microsoft Graph für Postfächer, dazu n8n / Power Automate / Camunda für Weiterleitungsaktionen.

Weg C — Selbst betreiben (Open Source)

• Encoder-Klassifikatoren: ModernBERT (Answer.AI/LightOn, 8k Kontext) [10] für Englisch sowie mmBERT (mehrsprachig, 1.800+ Sprachen, 8k Kontext) [11] oder XLM-RoBERTa / deutsche BERT-Varianten für Deutsch und gemischte Eingaben. Feintuning mit Hugging Face Transformers.
• Few-Shot / Zero-Shot: SetFit (wenige gekennzeichnete Beispiele je Klasse, in den Tests der Autoren konkurrenzfähig zum vollständigen Feintuning) [12]. GLiClass (Apache-2.0, Zero-Shot-Labels zur Inferenzzeit, laut den Autoren etwa 10-mal schneller als Cross-Encoder) [13].
• Kleine LLMs als Weiterleiter: Qwen3 (4B/8B), Gemma 3, Mistral Small oder Llama 3.x, betrieben über vLLM oder Ollama mit eingeschränkter JSON-Dekodierung (Outlines / strukturierte Ausgaben von vLLM).
• Werkzeuge: Argilla oder Label Studio zum Kennzeichnen; Embeddings (z. B. multilingual-e5, BGE-M3) mit Qdrant/pgvector für kNN-Few-Shot-Abruf; selbst betriebenes n8n für die Weiterleitung.
• Hardware: Encoder laufen auf der CPU, mit Hunderten Nachrichten pro Sekunde auf einem Standardserver (HW1). Ein kleiner LLM-Weiterleiter braucht HW2 (eine GPU mit 16–32 GB). Der Betriebsaufwand ist gering bis mäßig: Überwachung, regelmäßiges Nachtrainieren.

Weg D — Eigenes Training

Lohnt sich bei Tausenden historischer Tickets mit verlässlichen endgültigen Kennzeichnungen (der Warteschlange, die sie tatsächlich gelöst hat, nicht der ersten Vermutung) und hohem Volumen. Dann ist ein feingetunter Encoder meist die günstigste und schnellste Option und bei stabilem Label-Set oft mindestens so genau wie ein per Prompt gesteuertes LLM. LoRA-Feintuning eines kleinen LLMs ist die Alternative für Ausgaben mit mehreren Attributen. Bereinigen Sie zuerst die Kennzeichnungen. Doppelte Kategorien zusammenführen und eine geschichtete Stichprobe neu kennzeichnen. Vierteljährlich oder bei Drift neu trainieren.

Stand der Technik (2026)

• Encoder sind zurück. ModernBERT (Dez. 2024) und mmBERT (Sep. 2025) brachten 8k Kontext und höheren Durchsatz in die BERT-Klasse [10][11]. Lange E-Mails mit zitiertem Verlauf müssen nicht mehr auf 512 Tokens gekürzt werden.
• LLMs für den langen Schwanz: Zero-/Few-Shot-Klassifikation mit LLMs beseitigt das Kaltstartproblem und bewältigt Änderungen der Kennzeichnungen ohne Nachtraining [7]. Feingetunte Modelle gewinnen bei stabilen Label-Sets mit hohem Volumen weiterhin tendenziell [3].
• Retrieval-gestützte Klassifikation: Ähnliche gekennzeichnete Tickets als Beispiele im Kontext abzurufen (oder kNN-Abstimmung über Embeddings) ist eine günstige, starke Basislösung und passt sich an, wenn neue Kennzeichnungen hinzukommen.
• Helpdesk-eigene Triage ist in den großen Plattformen Standard [1][2]. Die Abgrenzung verschiebt sich zur Optimierung der Weiterleitung (OPT-035) und zur autonomen Lösung (AGENT-001, AGENT-016).
• Grenzen: mehrdeutige oder mehrthemige Nachrichten, Sarkasmus, gemischtsprachige Verläufe, Drift der Kennzeichnungen nach Produkteinführungen, Überzuversicht von LLMs (selbst berichtete Konfidenz ist schlecht kalibriert, nutzen Sie daher Log-Wahrscheinlichkeiten oder Übereinstimmungsprüfungen) und Prompt Injection im Text eingehender E-Mails. Lassen Sie den Inhalt einer E-Mail niemals Weiterleitungsregeln ändern oder privilegierte Aktionen auslösen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack aus Encoder/kleinem LLM (text-classifier, llm-small, embedding-text): LANG-013 Stimmungsanalyse, LANG-014 Moderation, LANG-015 Entitätsextraktion, LANG-024 Compliance-Prüfung und DOC-008 Dokumentklassifikation können sich einen CPU-/HW2-Inferenzserver, ein Kennzeichnungswerkzeug und eine Bewertungsumgebung teilen.
• Nachbarn in der Pipeline: DOC-008 (Anhänge, gescannte Post) → LANG-012 → AGENT-001 (Antwort entwerfen oder senden), AGENT-016 (IT-Lösung), CONV-007 (Agentenunterstützung), LANG-008 (Zusammenfassung des Verlaufs für die Bearbeitung), OPT-035 (welcher Agent den Kontakt erhält).
• Übersetzung & Datenschutz: LANG-009 für die Pivot-Übersetzung und DOC-018 für die Anonymisierung, die in der Variante für Hinweisgeber zwingend ist.
• Wissen: Derselbe Embedding-Index kann die Antwortvorschläge von KNOW-002 stützen.
• Workflow-Engine, gemeinsam genutzt mit AGENT-002.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis wenige Wochen Konfiguration. Meist eine Add-on-Lizenz pro Agent.
• Weg B: 4–8 Wochen einschließlich Bewertungsmenge, Prompt-Abstimmung und Integration. Die API-Kosten pro Nachricht sind bei kurzen E-Mails gering. Kostentreiber sind lange Verläufe und Aufrufe großer Modelle.
• Weg C/D: 1–3 Monate einschließlich Kennzeichnung und MLOps. Die Inferenzkosten sind auf der CPU vernachlässigbar.
• Kennzahlen: Weiterleitungsgenauigkeit / Makro-F1 je Kennzeichnung auf einer zurückgehaltenen Menge, Quote der automatischen Weiterleitung bei Zielpräzision, Quote der Umleitungen (Bounce), Zeit bis zur ersten Zuweisung, SLA-Verletzungsrate für dringende Klassen, Größe der Prüfwarteschlange, Drift-Warnungen.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsleitung und die Fachbereichsleitung (Service, IT-Desk) ein: Sie verantworten Kategorien, SLAs und Eskalationsregeln. Endanwender (Agenten) müssen helfen, Klassen zu definieren und Fälle mit niedriger Konfidenz zu prüfen, sonst vertraut niemand den Kennzeichnungen. IT bindet Postfach und Ticketsystem an; Datenverantwortliche geben die Historie frei. Die Datenschutzbeauftragte(r) wird gebraucht, weil E-Mails und Tickets personenbezogene Daten enthalten: Rechtsgrundlage, AVV mit jedem Auftragsverarbeiter und eine Datenschutz-Folgenabschätzung (DSFA, Art. 35 DSGVO) prüfen, wenn die Mengen groß sind oder besondere Kategorien vorkommen (GUIDE-005).

Betriebsrat: ja. Weiterleitungssysteme protokollieren, wer was wie schnell bearbeitet hat, und sind daher objektiv zur Leistungsüberwachung geeignet und lösen § 87 Abs. 1 Nr. 6 BetrVG aus (BAG). Vereinbaren Sie, dass Klassifikationsdaten nicht zur individuellen Leistungsbewertung verwendet werden (GUIDE-004). § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Information; im öffentlichen Sektor der Personalrat.

KI-Kompetenz: Unterstützen Sie das Team mit Schulungen zu Konfidenzwerten, Verzerrungen und der Gewohnheit, Fälle mit niedriger Konfidenz zu prüfen, siehe GUIDE-006. Kommunizieren Sie, dass die Weiterleitung Sortierarbeit abnimmt und keine Stellen (GUIDE-008). Fahren Sie einen Pilot im Schattenbetrieb mit einem Team: Die KI schlägt vor, die Agenten entscheiden, und Sie vergleichen (GUIDE-009). Behalten Sie den Menschen in der Kontrolle bei Beschwerden, Rechtsdrohungen und Anfragen betroffener Personen, die immer an eine Person eskaliert werden.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die typische Weiterleitung nach Thema/Warteschlange hat minimales Risiko, nur die Pflicht zur KI-Kompetenz (Art. 4) gilt. Es kommt auf den Kontext an:
• Entscheidet die Klassifikation über den Zugang zu wesentlichen öffentlichen Diensten oder Leistungen (Anhang III 5(a)), über Versicherung oder Kredit oder priorisiert sie Notrufe (Anhang III 5(d), siehe CONV-021), kann das System hochriskant sein. Ein rein vorbereitender oder eng begrenzter verfahrensbezogener Weiterleitungsschritt kann unter die Ausnahme nach Art. 6 Abs. 3 fallen, jedoch nie, wenn er natürliche Personen profiliert [14].
• Das Klassifizieren von Nachrichten Beschäftigter nach Leistung oder Verhalten nähert sich Anhang III 4 (siehe LANG-032).
• Das Ableiten von Emotionen Beschäftigter ist nach Art. 5 Abs. 1 Buchst. f verboten. Stimmungskennzeichnungen von Kunden sind keine Emotionserkennung im Sinne von Art. 5, halten Sie sie aber von der Mitarbeiterbewertung fern.
• DSGVO: E-Mails und Tickets enthalten personenbezogene Daten und mitunter besondere Kategorien (Gesundheit, Gewerkschaftszugehörigkeit). Sie brauchen eine Rechtsgrundlage (meist Vertrag oder berechtigtes Interesse), einen AVV mit dem Anbieter, EU-Hosting, Aufbewahrungsgrenzen für Trainingsdaten und Zweckbindung, wenn historische Tickets für das Training wiederverwendet werden. Automatische Weiterleitung allein ist keine Entscheidung nach Art. 22, eine automatische Ablehnung oder Zurückstufung mit erheblicher Wirkung kann es aber sein.
• Hinweisgeberschutz: Vertraulichkeit nach § 8 HinSchG, Fristen nach § 17 HinSchG [4] und Protokollierung des Zugriffs. Keine Verarbeitung in der US-Cloud ohne Transferprüfung.
• Gegenmaßnahmen: Konfidenzschwellen, eine verpflichtende Warteschlange "unklar", Schlagwort-Sicherungen für rechtliche und DSGVO-Anfragen, eine monatliche Audit-Stichprobe, eine Prüfung auf Verzerrungen über Sprachen und Kundengruppen hinweg und Filter gegen Prompt Injection.

Erste Schritte

1. Tickets/E-Mails der letzten 3–12 Monate mit ihrer endgültigen Warteschlange und Kategorie exportieren. Das Volumen je Kennzeichnung zählen und die heutige Umleitungsquote messen.
2. Den Satz der Kennzeichnungen bereinigen: 10–30 gut definierte Klassen, eine Klasse "Sonstiges" und schriftliche Definitionen. Eine geschichtete Stichprobe von etwa 500 Einträgen als Goldstandard- Testmenge neu kennzeichnen.
3. Hat Ihr Helpdesk eine eigene Triage (Weg A), diese zuerst an der Goldmenge testen. Andernfalls ein per Prompt gesteuertes LLM mit Few-Shot-Beispielen (Weg B) als Basislinie laufen lassen.
4. Sind das Volumen hoch und die Kennzeichnungen stabil, ein ModernBERT-/mmBERT- oder SetFit-Modell trainieren (Weg C/D) und Genauigkeit, Latenz und Kosten vergleichen.
5. Im Modus "Vorschlag" in Betrieb gehen und die automatische Weiterleitung je Kennzeichnung aktivieren, sobald die Präzision das Ziel erreicht. Korrekturen monatlich zurückführen.

Quellen

1. Zendesk — Automatically classifying tickets with intelligent triage — https://support.zendesk.com/hc/en-us/articles/4550640560538
2. ServiceNow — Predictive Intelligence (incident categorisation, precision & coverage) — https://www.servicenow.com/docs/bundle/zurich-intelligent-experiences/page/administer/predictive-intelligence/concept/predictive-intelligence.html
3. Engelbrechtsmüller, S. (2024): Fine-Tuning Large Language Models for Ticket Classification at Doka GmbH, JKU Linz — https://research.jku.at/en/publications/fine-tuning-large-language-models-for-ticket-classi%EF%AC%81cation-at-dok/
4. Hinweisgeberschutzgesetz §17 (deadlines) — https://www.gesetze-im-internet.de/hinschg/__17.html
5. novomind — iAGENT customer service software — https://www.novomind.com/en/
6. Insiders Technologies — Response Management, OvAItion — https://insiders-technologies.com/en/
7. Anthropic — Ticket routing use-case guide — https://platform.claude.com/docs/en/about-claude/use-case-guides/ticket-routing
8. Microsoft Learn — Custom text classification overview (retirement notice) — https://learn.microsoft.com/en-us/azure/ai-services/language-service/custom-text-classification/overview
9. Mistral AI — Classifier Factory (deprecated) — https://docs.mistral.ai/capabilities/finetuning/classifier_factory/
10. Hugging Face — Finally, a replacement for BERT: ModernBERT — https://huggingface.co/blog/modernbert
11. Hugging Face — mmBERT: a modern multilingual encoder — https://huggingface.co/blog/mmbert
12. SetFit — efficient few-shot learning with Sentence Transformers — https://github.com/huggingface/setfit
13. Knowledgator — GLiClass zero-shot classification — https://github.com/Knowledgator/GLiClass
14. EU AI Act Article 6 (classification rules, Art. 6(3) derogation) — https://artificialintelligenceact.eu/article/6/
15. TeleDoCTR: domain-specific ticket routing with BERT and LLMs (arXiv 2601.00691) — https://arxiv.org/abs/2601.00691