Route Support Tickets with Jev

The decision boundary

This pattern chooses the team that should first review a request. It does not approve refunds, decide eligibility, or execute account changes. Define overlapping responsibilities explicitly and add an Other option for cases that need triage.

Try your own context

Edit the example below. Selecting a preset does not use an allowance; only a successful run does.

What to expect

For the duplicate-charge example, Billing is a plausible routing label. This is an illustrative expectation, not a recorded model response. Run the example to inspect the actual probabilities and returned decision.

Use it in your application

{
  "playground": "https://aijev.net",
  "language": "JavaScript",
  "request": {
    "model": "typesafe/jev-1.13",
    "state": "Customer says: \"I was charged twice for my subscription and need a refund.\"",
    "questions": {
      "decision": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
          "Billing": "Billing",
          "Technical Support": "Technical Support",
          "Sales": "Sales",
          "Other": "Other"
        }
      }
    },
    "provider": {
      "allow_fallbacks": false
    }
  },
  "note": "AIJev Playground request shape only. For application integration, visit https://docs.typesafe.ai."
}

When this pattern is useful

This works best when departments have well-defined scopes and representative historical tickets are available for evaluation. Measure misroutes and escalation rate, not just whether the API returned a valid label.

When a human should review

Escalate requests involving threats, sensitive account access, financial disputes, or ambiguous ownership. Human review is also appropriate when probabilities are spread across teams. Calibrate thresholds on your own data.

Frequently asked questions

Next: Agent tool selection · API integration guide · All examples.