E-Mails und Support-Tickets mit Jev routen: Von der Klassifizierungsdemo zum vollständigen Geschäftsprozess

500 E-Mails schnell in einige Kategorien einzuteilen, ist eine leicht verständliche Jev-Demonstration.

Der Autor eines Community-Beispiels berichtete, dass Jev 500 E-Mails innerhalb weniger Sekunden im Batch klassifizieren könne – zu Kosten von etwa 0.035 US-Dollar. Die Demonstration veröffentlichte jedoch weder die Zusammensetzung der E-Mails noch die Kategoriedefinitionen, menschliche Labels, Genauigkeit oder Konfusionsmatrix. Sie eignet sich daher eher als Illustration eines möglichen Aufrufmusters als als Beleg dafür, dass dieser Ansatz das Routing im Kundensupport bereits produktiv ersetzen kann.

In einem echten E-Mail- und Ticketsystem besteht die Schwierigkeit nicht nur in der Frage: „An welche Abteilung soll diese Nachricht gehen?“

Ein einzelnes Ticket kann gleichzeitig eine Doppelbelastung, eine Rückerstattungsforderung, eine Chargeback-Drohung und mehrere ungelöste Beschwerden enthalten. Die Zuordnung zur Queue billing kann als Klassifikation korrekt sein, während das System trotzdem genau jene Risikosignale übersieht, die höchste Priorität verdienen.

Jev eignet sich daher weniger dazu, „den gesamten Support-Prozess mit einer einzigen Klassifikation zu lösen“, sondern vielmehr als Entscheidungsschicht: Eine E-Mail wird in mehrere klar abgegrenzte Fragen zerlegt, deren strukturierte Ergebnisse anschließend an den Geschäfts-Code übergeben werden, damit dieser sie kombiniert, routet und Aktionen ausführt.

E-Mail oder Support-Ticket
   ↓
Vorverarbeitung: Betreff, Inhalt und notwendigen historischen Kontext extrahieren
   ↓
Jev: Queue-Auswahl, Rückerstattungserkennung, Risikoerkennung, Dringlichkeitsbewertung
   ↓
Geschäftsregeln: Wahrscheinlichkeiten, Schwellenwerte, Kundendaten und Unternehmensrichtlinien kombinieren
   ↓
Automatisches Routing / menschliche Prüfung / Eskalation hoher Risiken / Erstellung eines Antwortentwurfs

Die wichtigste Aufgabenteilung lautet: Jev trifft semantische Entscheidungen, der Code kontrolliert den Ablauf, und Support-Mitarbeitende oder ein generatives Modell verfassen die endgültige Antwort.

Warum Jev für diese Entscheidungsschicht geeignet ist

Jev ist kein Chatmodell, das auf die Erzeugung langer Texte ausgelegt ist. Es erhält einen state und beantwortet vom Entwickler im Voraus definierte typed questions. Diese Fragen treten hauptsächlich in drei Formen auf:

Typ	Geeignete Frage	Rückgabewert
Choice	Welche Queue ist für dieses Ticket am besten geeignet?	Eine Option, die Wahrscheinlichkeiten aller Optionen und confidence
Noul	Verlangt der Nutzer ausdrücklich eine Rückerstattung?	Eine „Ja“-Wahrscheinlichkeit zwischen 0 und 1
Score	In welche Dringlichkeitsstufe fällt dieses Ticket?	Ein Score, Wahrscheinlichkeiten der einzelnen Stufen und confidence

Mehrere Fragen können innerhalb einer Anfrage parallel bewertet werden. Statt das Modell ein Ticket lesen und eine Analyse formulieren zu lassen, die anschließend vom Programm wieder aus Text herausgeparst werden muss, ist es meist klarer, mehrere atomare Fragen direkt zu stellen, deren Ergebnisse bereits für nachgelagerten Code geeignet sind.

Eine typisierte Antwort garantiert jedoch nur, dass das Ergebnis einer vorab definierten Schnittstelle entspricht. Sie garantiert nicht, dass die Geschäftsentscheidung korrekt ist. Das System benötigt weiterhin Schwellenwerte, Fallbacks, menschliche Prüfung und Offline-Evaluation.

Ein Ticket sollte nicht auf eine einzige Frage reduziert werden

Angenommen, ein Nutzer sendet folgende E-Mail:

Nach dem Upgrade auf den Pro-Tarif wurde mir der Betrag zweimal berechnet. Ich habe Sie vor drei Tagen kontaktiert, aber bis heute hat niemand das Problem gelöst. Erstatten Sie mir das Geld noch heute, sonst werde ich bei meiner Bank einen Chargeback einreichen.

Wenn die einzige Frage lautet „Zu welcher Abteilung gehört diese E-Mail?“, wird die Antwort wahrscheinlich billing sein. Ein Produktionssystem muss jedoch mindestens vier weitere Dinge wissen:

Entscheidung	Fragetyp	Empfohlene Optionen oder Kriterien	Zweck
Welche Haupt-Queue soll das Ticket erhalten?	Choice	billing / shipping / technical / account / sales / legal / none	Erstes Routing
Liegt eine Rückerstattungsforderung vor?	Noul	Eine ausdrückliche Forderung nach Rückzahlung, Rückbuchung oder Erstattung gilt als „Ja“	Rückerstattungs-Workflow auslösen
Besteht ein Chargeback-, regulatorisches oder rechtliches Risiko?	Noul	Erwähnung von chargeback, Bankbeschwerde, Aufsichtsbehörde oder rechtlichen Schritten	Eskalation hohen Risikos
Dringlichkeit	Score	Allgemeine Anfrage ohne Frist / Nutzung bereits beeinträchtigt oder wiederholter Kontakt / finanzieller Verlust, Chargeback oder ausdrückliche Frist	Priorität innerhalb der Queue
Ist eine menschliche Bearbeitung erforderlich?	Noul	Geld, rechtliche Themen, wiederholt ungelöste Beschwerden oder unsichere Modellentscheidung	Entscheiden, ob automatische Bearbeitung erlaubt ist

Diese Fragen hängen zusammen, sollten aber nicht zu einer einzigen Aufforderung wie „Entscheide insgesamt, wie dieses Ticket behandelt werden soll“ zusammengefasst werden.

Die offiziellen Designempfehlungen für Jev sehen vor, komplexe Aufgaben in atomare Entscheidungen zu zerlegen. Nach der Trennung der Fragen kann der Geschäfts-Code unabhängig entscheiden, welche Queue verwendet wird, ob die Priorität erhöht, eine automatische Antwort angehalten oder die Rufbereitschaft informiert werden soll.

Eine Choice-Frage sollte außerdem eine Option wie none, other oder unclear enthalten. Fehlt die richtige Antwort in der Auswahlliste, kann das Modell keine neue Queue erfinden; es kann das Ticket nur in die nächstliegende vorhandene Option zwingen.

Zwischen Modellausgabe und Geschäftsaktion bleibt eine Regelschicht erforderlich

Der folgende Kontrollfluss-Pseudocode zeigt die Aufgabenteilung zwischen Jev und dem umgebenden System. Es handelt sich nicht um eine wörtliche Anfrage des offiziellen SDK:

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

Konstanten wie T_ROUTE und T_REFUND sind keine universellen Jev-Standardwerte, sondern Geschäftsregeln. Sie müssen anhand der eigenen Ticketdaten kalibriert werden und können sich mit Risikostufe, Sprache, Modellversion und Queue-Definition verändern.

Für gewöhnliche, risikoarme Anfragen kann das System relativ großzügige Schwellenwerte für automatisches Routing akzeptieren. Für Rückerstattungen, Chargebacks, Kontosperrungen oder rechtliche Beschwerden sollten strengere Schwellenwerte gelten und eine menschliche Prüfung erhalten bleiben.

Batch-Aufrufe eignen sich für Routing, doch Hochrisiko-Gates erfordern mehr Vorsicht

Eine offizielle Schnittstelleneigenschaft von Jev ist, dass eine einzelne Anfrage mehrere Fragen parallel beantworten kann. Werden mehrere Tickets in einem Aufruf gebündelt, sollte man jedoch nicht davon ausgehen, dass die Ergebnisse mit separaten Einzelaufrufen übereinstimmen. Stattdessen sollten Teams das Verhalten von Batch- gegenüber Einzelaufrufen anhand der eigenen Daten benchmarken.

Damit eignet sich Batch-Verarbeitung gut für die Klassifizierung großer E-Mail-Mengen, insbesondere für Queue-Auswahl, Themenlabels und gewöhnliche Prioritätsentscheidungen. Im Vergleich zum Muster „eine Anfrage pro E-Mail und eine weitere pro Frage“ reduziert das Bündeln der benötigten Entscheidungen in möglichst wenigen Aufrufen in der Regel Netzwerk-Roundtrips und erleichtert die Steuerung des Durchsatzes.

Ebenso sollte man bei Noul-Wahrscheinlichkeiten für Grenzfälle keine Äquivalenz zwischen Batch- und Einzelaufrufen voraussetzen, sondern diese gezielt validieren. Tickets mit hohem Risiko oder unklaren Wahrscheinlichkeiten sollten separat behandelt werden.

Ein vorsichtigeres zweistufiges Design wäre daher:

1. In der ersten Stufe risikoarme Entscheidungen wie Haupt-Queue, Thema und offensichtlichen Spam im Batch ausführen.
2. Tickets zu Rückerstattungen, Chargebacks, rechtlichen Risiken oder mit Wahrscheinlichkeiten im Unsicherheitsbereich einzeln prüfen oder direkt an eine menschliche Queue weiterleiten.

Dabei geht es nicht darum, das Modell wiederholt abstimmen zu lassen, sondern Hochrisiko-Aktionen einen klareren Kontext und einen strengeren Bearbeitungspfad zu geben.

confidence nicht als „Trefferwahrscheinlichkeit“ behandeln

Choice und Score geben confidence zurück. Dieses Feld beschreibt jedoch, wie stark sich die Wahrscheinlichkeitsverteilung konzentriert. Es kann nicht direkt als „Wahrscheinlichkeit, dass diese Antwort korrekt ist“ interpretiert werden.

Konzeptionell ist confidence keine für das eigene Geschäft direkt validierte Wahrscheinlichkeit der inhaltlichen Korrektheit. Da dieser Wert anhand eigener Ticketdaten kalibriert und überprüft werden muss, ist eine pauschale Regel wie die folgende unsicher:

confidence = 1.0 → automatisch ausführen

Ein reales System sollte mehrere Signale gleichzeitig berücksichtigen:

• die probability der erstplatzierten Option;
• den probability-Abstand zwischen erster und zweiter Option;
• ein unabhängiges Noul, das dem jeweiligen Geschäftsrisiko entspricht;
• ob das Ticket aus einer Verteilung stammt, die durch Trainings- oder Validierungsdaten nicht abgedeckt ist;
• ob sich Modellversion oder Frageformulierung verändert haben.

Auch „In welche Queue gehört das Ticket?“ und „Darf es automatisch bearbeitet werden?“ sollten nicht mit nur einem Choice gelöst werden. Verwende Choice zur Queue-Auswahl und ein separates Noul, um zu prüfen, ob die Bedingungen für automatische Bearbeitung erfüllt sind.

Frageformulierungen müssen wie Code verwaltet werden

In einem Jev-Workflow sind Frageformulierungen kein gewöhnlicher Prompt-Text, sondern Teil der Geschäftslogik.

Wenn sich die Bedeutung von instructions und criteria widerspricht, können Antworten strukturell gültig, aber semantisch unpassend ausfallen, ohne dass ein technischer Fehler ausgelöst wird. Eine systematische Prüfung auf solche Definitionskonflikte ist daher unerlässlich.

Ein E-Mail-Routing-Projekt sollte Fragedefinitionen daher mindestens wie folgt verwalten:

Verwaltungsaspekt	Konkrete Praxis
Versionierung	Bei jeder Änderung von Formulierung, Optionen oder Kriterien eine neue Version erstellen
Code-Review	Fragedefinitionen und Routingregeln im Repository für review ablegen, statt sie über Admin-Textfelder zu verteilen
Testbeispiele	Für jede Frage positive, negative, grenzwertige und mehrdeutige Tickets aufbewahren
Widerspruchsprüfung	Sicherstellen, dass instruction und true/false criteria semantisch in dieselbe Richtung zeigen
Modellversion fixieren	Nach der Kalibrierung der Schwellenwerte eine konkrete Version festlegen, statt direkt von einem driftenden latest alias abhängig zu sein

Jede Stufe eines Score sollte eine beobachtbare Geschäftssituation beschreiben, statt nur „niedrig, mittel, hoch“ zu verwenden. „Der Nutzer fragt nur nach dem Preis“ und „der Nutzer hat mehrfach Kontakt aufgenommen und der Dienst ist nicht verfügbar“ lassen sich konsistenter bewerten als „mittlere Dringlichkeit“.

Das System muss wissen, was bei Netzwerkausfällen zu tun ist

Eine fehlgeschlagene Antwort des Klassifikationsmodells darf nicht als „kein Risiko“ oder „standardmäßig zulassen“ interpretiert werden.

In Produktionsumgebungen können unter Last oder bei Netzwerkvolatilität jederzeit Transportfehler auftreten, und Latenzen können variieren. Ein Produktionssystem darf daher nicht nur für den Idealpfad ausgelegt sein.

Mindestens vier Schutzebenen sind erforderlich:

1. Wiederholung und Backoff: Bevorzuge ein SDK, das Wiederholungen und retry-after unterstützt, damit ein vorübergehender Netzwerkfehler kein Ticket verloren gehen lässt.
2. Explizite Fallback-Semantik: Vorab festlegen, ob die Nichtverfügbarkeit des Entscheidungsdienstes das Ticket an menschliche Triage schickt, die Bearbeitung verzögert oder nur deterministische Regeln ausführt.
3. Idempotenz und Deduplizierung: Erneute E-Mail-Zustellung, Queue-Retries oder Wiederholungen nach Timeout dürfen keine doppelten Tickets erzeugen.
4. Vollständige Protokollierung: Modellversion, Frageversion, probabilities, Aufruflatenz, Nutzung und abschließendes menschliches Ergebnis erfassen.

Bei finanziellen, kontobezogenen oder rechtlichen Tickets ist der sicherste Standard-Fallback meist nicht „automatisch genehmigen“, sondern „automatische Aktion anhalten und an einen Menschen übergeben“.

Mehrsprachige Queues können nicht dieselben Score-Schwellenwerte verwenden

Gehen Sie bei der Arbeit mit mehreren Sprachen nicht davon aus, dass Schwellenwerte und Entscheidungsregeln zwischen den Sprachen übertragbar sind.

Schwellenwerte für Score und Niveaus von confidence sind nicht universell: Validieren Sie diese separat für jede unterstützte Sprache, selbst wenn das grundlegende Routing-Label identisch aussieht.

Ein mehrsprachiges Support-System sollte daher mindestens:

• für jede Sprache ein separates Validierungsset aufbauen;
• Dringlichkeits- und Eskalationsschwellen je Sprache separat kalibrieren;
• Score-Bereiche aus englischen Daten nicht direkt auf Chinesisch oder andere Sprachen übertragen;
• eine konsistente Regel dafür anwenden, wie Übersetzung, Originaltext und Gesprächsverlauf genutzt werden.

Was vor dem Start bewertet werden sollte

Ein E-Mail-Routing-System kann nicht allein nach seiner Gesamtgenauigkeit beurteilt werden. Verschiedene Fehler haben sehr unterschiedliche Kosten. Eine Pre-Sales-Anfrage in die Support-Queue zu senden verursacht möglicherweise nur eine zusätzliche Übergabe; eine Chargeback-Drohung oder rechtliche Beschwerde zu übersehen kann direkten finanziellen und regulatorischen Schaden verursachen.

Mindestens folgende Kennzahlen sollten getrennt betrachtet werden:

Kennzahl	Zu beantwortende Frage
Genauigkeit der Haupt-Queue	Ist das Ticket in der richtigen ersten Bearbeitungs-Queue angekommen?
Recall bei Hochrisiko-Fällen	Wie viele Chargeback-, Rechts-, Regulierungs- oder Kontosicherheits-Tickets wurden übersehen?
Abdeckung durch automatisches Routing	Welcher Anteil der Tickets benötigte keine manuelle Erstsortierung?
Rate falscher automatischer Bearbeitung	Wie viele Tickets, die menschliche Bearbeitung erfordert hätten, wurden automatisch durchgelassen?
Anteil menschlicher Prüfung	Sind die Schwellenwerte so konservativ, dass die menschliche Queue ihren Nutzen verliert?
Latenz und Fehlerrate	Ist das System unter realer Parallelität, E-Mail-Länge und Netzwerkbedingungen stabil?
Vollkosten pro Ticket	Bleibt der Workflow nach Entscheidungen, Wiederholungen, nachgelagerten Modellen und menschlicher Prüfung wirtschaftlich?

Bei der Wahl von Vergleichsbaselines sollte Jev nicht nur mit teuren Frontier-Chatmodellen verglichen werden. Regelbasierte Systeme, Flash-Modelle mit strukturierten Ausgaben, Embeddings plus Klassifikator sowie kleine Modelle, die auf eigenen gelabelten Daten trainiert wurden, können ebenfalls sinnvolle Alternativen sein.

Sobald ausreichend gelabelte Daten vorliegen, empfiehlt es sich, für spezifische Aufgaben einen spezialisierten Klassifikator zu benchmarken. Ein sinnvoller Entwicklungspfad ist daher, Jev beim Kaltstart und bei häufig wechselnden Labels einzusetzen und später zu prüfen, ob eine stark frequentierte Queue nach ausreichender Datensammlung gegen einen spezialisierten Klassifikator gebenchmarkt und evaluiert werden sollte.

Jev schreibt nicht die endgültige Support-Antwort

Nach dem Routing muss das System möglicherweise weiterhin das Problem zusammenfassen, die Bestellung abrufen, die Rückerstattungsberechtigung prüfen oder einen Antwortentwurf erstellen. Diese Aufgaben sollten nicht alle Jev zugewiesen werden.

Eine klarere Aufgabenteilung ist:

Schritt	Besser geeigneter Ausführer
Exakte Bestellabfrage, Betragsberechnung und Datumsvergleich	Geschäfts-Code und Datenbanken
Beurteilung von Queue, Risiko, Absicht und Dringlichkeit	Jev oder ein anderes Klassifikationsmodell
Wissensdatenbank-Suche	Such- und RAG-Systeme
Antwortentwurf, Erklärung und natürlichsprachliche Kommunikation	Ein generatives LLM
Genehmigung von Rückerstattungen, Kontosperrung und rechtliche Bearbeitung	Menschen und Unternehmensrichtlinien

Diese Architektur macht Jev nicht zu einem „automatisierten Support-Agenten“. Sie fügt lediglich eine kostengünstige, strukturierte Entscheidungsschicht hinzu, die Code direkt verarbeiten kann, bevor eine E-Mail ein teures Modell oder eine menschliche Queue erreicht.

Fazit: Nicht die Klassifikation ist das Produkt, sondern der Kontrollfluss

Jev zeigt eine nützliche Richtung: Wenn Software nur eine Queue, eine Wahrscheinlichkeit oder eine Stufe benötigt, ist es nicht nötig, jedes Mal ein generatives Modell Text schreiben zu lassen und den Code anschließend dessen Bedeutung erraten zu lassen.

Der Schritt von einer E-Mail-Klassifizierungsdemo zu einem vollständigen Geschäftsprozess erfordert jedoch die Gestaltung des Kontrollflusses nach der Klassifikation: Welche Tickets dürfen automatisch geroutet werden? Welche Signale müssen unabhängig erkannt werden? Wann muss ein Mensch übernehmen? Wie degradiert das System bei einem Dienstausfall? Und wie werden Schwellenwerte fortlaufend mit tatsächlich gelabelten Daten überprüft?

Ein Jev-Ticketsystem sollte daher nicht nur mit der Frage bewertet werden: „Wie schnell hat es 500 E-Mails klassifiziert?“ Die bessere Frage lautet:

Reduziert es zuverlässig unnötige Übergaben, Modellaufrufe und die erste manuelle Sortierung, ohne Hochrisiko-Tickets zu übersehen?

Erst wenn diese Frage anhand der eigenen Geschäftsdaten positiv beantwortet werden kann, wird E-Mail-Routing von einer Modelldemonstration zu einem tatsächlich nutzbaren Geschäftsprozess.