Use case
Support ticket routing
Classify urgency, team and tone on every inbound ticket before it hits a queue.
The problem
Routing rules miss sarcasm, multi-intent tickets and silent VIP accounts.
What your code does with the answer
If urgency is high and confidence is low, page a human. Otherwise enqueue to the chosen team.
How the decision comes back
Three questions ride into one request over the ticket text: is_urgent (yes/no), department (choice of billing, technical or sales) and frustration (a three-level score). Each answer carries its own probability, so a ticket that reads as two intents at once — a refund complaint hiding a bug report — still lands somewhere, with a distribution that shows how contested the call was. The curl sample below is the full request; your server sends the same JSON with a Bearer key.
What production code does with it
Route on department. If is_urgent is above 0.8 and frustration sits in the top level, page a person instead of queueing. If is_urgent is high but the department probability is split under 0.6, the distribution is telling you the intent is mixed — send it to the senior queue with both candidate teams attached. The threshold numbers are yours; what makes it stable is the shape: act on the level, review when contested.
Pitfalls specific to triage
The classic failure is criteria written for humans, not for a model: "billing stuff" routes invoices and refunds inconsistently — name concrete examples in each option's description. Second: do not bury urgency inside the same question as routing; mixed-intent tickets read as low urgency when one question carries both. Third: keep commercial context (accounts with revenue fields) in state so urgency can weight them without hard-coding a VIP tier.
The request shape
This is the full request the playground sends for this preset — the same JSON your server sends to /v1/systemone with a Bearer key.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Help! My payouts have been failing for 3 days and my customers are asking where their money is.",
"questions": {
"is_urgent": {
"type": "noul",
"instructions": "Does this convey urgency?",
"criteria": {
"true": "Explicitly time-sensitive or business-critical",
"false": "No urgency expressed"
}
},
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, payouts, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated is the customer?",
"criteria": [
"Calm",
"Frustrated",
"Very angry"
]
}
}
}'FAQ about this use case
- Do I need one Jev request per ticket?
- No — every routing signal is a question in one request. Eight questions max per call: enough for urgency, department, sentiment, VIP status and language at once. A typical triage call is 400–600 tokens and costs 1 credit.
- What about tickets in other languages?
- Write the instructions and criteria in the language your act-on path is written in; the state can stay in the customer's language. Jev's answer space is typed either way — test five recent tickets per language before turning it on.
- What happens when the queue is wrong but confidence is high?
- Wrong with confidence is a criteria-wording fix, not a threshold issue. Pull three misrouted tickets, rewrite the department criteria with concrete examples (payments, invoicing — not "money things"), and re-run them free in the playground before touching production.