Should I use Jev for support ticket routing?
Verdict for the sample idea
Run it on
Jev
A bounded judgment over text, made many times. A System One model fits.
Sample idea
Read each incoming support email and route it to one of five teams: billing, technical, account access, sales or abuse. We receive about 3,000 emails a day, and a wrong route costs a few hours of delay.
Explanation
Ticket routing is the example that TypeSafe itself uses, and with good reason. The input is text. The output is one team from a fixed list. Each ticket needs one judgment. The volume is high, so the price per decision matters. A wrong route costs some hours and not money. All the conditions for Jev are present.
Shape it as one Choice question with one option per team. Write each option as a small definition with three fields: what belongs here, what it includes, and what it is not for. The not_for field does most of the work. "Billing" and "account access" overlap when a customer cannot log in to pay. Decide where that ticket goes, and write the decision into both options. Add an other option. Without it, Jev must put a job application or a press request in one of your five queues.
Ask the side questions in the same call. Does the message convey urgency? Does it mention legal action? They cost almost nothing, and they run in parallel.
Rules that you already have stay in code. If the sender's domain belongs to a key account, route by lookup, not by Jev.
The common trap is to route on the verdict and ignore the confidence. A flat distribution means the ticket sits between two teams. Send those to a person, and count them. If the unclear share is large, your team definitions overlap, and no model can fix that.
A second trap is to test with ten tickets that you remember. Label 200 real tickets first, and measure against them before Jev routes anything.
Related tasks
Verdict produced by Jev on 2026-09-19, rubric version 2. Text written by a person. How the tool works: the report.