Jev routing scenario

Jev Ticket Routing: Route Support Tickets by Example

Ticket routing is the Jev scenario with the clearest unmet search demand: almost nobody has published a reusable routing template. This independent tutorial gives you one: a four-team criteria table, six worked synthetic cases, and explicit human-review rules. All cases are authored examples. Expected labels are the author's expectations, not observed model output.

When routing fits (and when it does not)

Routing fits when exactly one team owns the request and a wrong guess is cheap to catch. It does not fit multi-team requests, out-of-scope messages, or anything that triggers a real action such as refunds, access changes, or account closures. Those always need a human step, no matter what a classifier says.

The routing criteria table

The template below is support-ticket-routing version 1.0.0: one choice question named department with four options. Copy these definitions into your own request when you start; change the words only when your team ownership actually differs.

Six worked synthetic cases

Three normal cases show the happy path. Two edge cases show where vocabulary lies. One failure-mode case shows when to refuse to route. None of these have been run against the live API; treat them as a starting hypothesis for your own labeled sample.

Edge cases that should go to other

Billing words do not make a billing ticket. The webhook case above mentions payment but describes a 500 error, so it belongs with technical support. Mixed requests such as refund plus broken integration name two owners at once. Vague complaints with no artifact, no account context, and no reproduction steps have no safe team at all. All three patterns route to other.

Three failure postmortems: why a human would also pause

The payment-webhook case fails the naive keyword rule because the word payment points at billing while the verb fails with a 500 error points at technical. A human triager resolves this by asking which team can fix it: only technical can restart the integration, so billing ownership of the words does not matter. Encode that as a template rule: verbs describing breakage outrank nouns describing money.

The refund-plus-integration case names two owners in one sentence. Splitting it automatically would create two tickets with shared context and double handling cost. A human asks one clarifying question first: is the refund blocked by the broken integration, or are these independent? Until that answer exists, other is the only honest label. Never let a router invent the dependency.

The bare it-is-broken case has no artifact, no account, no steps to reproduce. A human would reply asking for the failing endpoint, a timestamp, and one example payload. A classifier that guesses technical here looks decisive and is wrong a third of the time. Route it to other with a request for specifics attached.

Human review rules

Keep a person in the loop for every ambiguous, high-impact, or multi-team decision. Concretely: low confidence answers, close probability splits, refund or access implications, and anything the template author marked failure-mode all go to a human queue with the original text attached. Never let a routing label trigger a side effect on its own.

Copy the request and run your own sample

The request below is the exact shape this site's code generator emits for the routing template. Save it as request.json, export your personal key, and run the cURL command from the API example page. Replace the state with five of your own de-identified tickets before you trust any pattern.

{
  "state": "Our payment webhook fails with a 500 error.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Route this support request to one team.",
      "criteria": {
        "billing": "Invoices, payments, refunds or existing charges",
        "technical": "Bugs, errors, outages or integrations",
        "sales": "Buying, demos, plans or presales questions",
        "other": "Unclear, multi-team or out-of-scope requests"
      }
    }
  }
}

Limits

Six synthetic English cases prove nothing about production traffic. This page reports no accuracy, no macro-F1, and no latency numbers because no live evaluation backs them. For how a honest small evaluation would be structured, read the method note. For request mechanics, read the API example.

Checklist before you trust any route

Run five of your own de-identified tickets through the request above, one per team plus one ambiguous case. Record the returned choice, the top-two probability gap, and whether a human agrees. Any gap below 0.15, any refund or access implication, and any mixed two-team request goes to the review queue regardless of the label. Keep that log for two weeks before wiring the router to anything beyond a suggestion column in your helpdesk.

Jev API example · What is Jev AI? · Evaluation method · All templates

FAQ

Are these real model results? No. Every label on this page is an authored expectation. The template has draft status and zero approved fixtures.

Can I use this for automatic refunds? No. Routing suggestions must never trigger money, access, or account changes without human approval.

What should I test first? Five de-identified tickets from your own queue, covering each team plus one ambiguous case, run locally with your own key.