Support Ticket Classifier: route requests to the right team
Sort shared-inbox tickets into Billing, Technical, Sales, or Fraud. Review ambiguous charges and mixed requests before assigning a team.
Free preview limits apply. Sign in to use your credits and keep a decision history.
Your next decision starts here.
Add context above, or try an example to get started.
A shared inbox needs shared rules
A billing complaint can mention a broken checkout, and an unauthorized payment can look like a duplicate charge. Routing works better when the team agrees on who owns each issue before inspecting a score. Use this classifier to propose an initial queue, then review the message against your support policy. It does not issue refunds, confirm fraud, or change an account. Keep the original ticket available so the receiving team can see details that a short routing summary may leave out.
Work through the cases
Illustrative inputs and review guidance, not recorded model outputs. Run your own context to inspect a decision.
A recognized purchase, charged twice
I renewed my plan yesterday. Both charges are for that renewal, but I only bought one subscription.
Billing is the intended category under a policy that assigns recognized purchase disputes to the billing team. The useful fact is that the customer recognizes the purchase. A request for money back alone does not establish fraud; the payment history still needs checking before anyone decides on a refund.
A payment the customer does not recognize
There are two charges from you on my card. I never opened an account or authorized either payment.
The denial of authorization makes this a candidate for the Fraud review queue. That label should mean specialist review, not a finding that fraud occurred. If Billing handles all payment investigations in your organization, change the routing policy rather than treating a different category as an automatic model error.
A bug and a refund in the same ticket
Export keeps failing and I missed my deadline. Can you fix it and refund this month?
This needs technical investigation and a commercial response. Choose a primary owner under your escalation rules, or split it into linked tasks. Add the account plan only when it changes queue ownership; an enterprise plan by itself is not evidence of a sales request.
Set the boundaries before you classify
Suggested review rules for these options. Include the rules relevant to your team in the question or context when you run a decision.
| Choice | Use it when | Check the boundary |
|---|---|---|
| Billing | Recognized purchases with invoice, amount, renewal, or refund questions. | A denied authorization needs a payment investigation, not just an invoice correction. |
| Technical | A product failure, access problem, or request for troubleshooting. | A related refund request may need a second owner. |
| Sales | Pre-purchase pricing, procurement, or expansion discussions. | Existing paid customers can still need technical support. |
| Fraud | Reports of unrecognized transactions or suspected account abuse. | A routing label is not proof of misconduct and must not automatically freeze an account. |
Where to take a closer look
One ticket, several owners
A single-choice response cannot assign two teams. Decide which issue establishes ownership and preserve the secondary request in the handoff. Otherwise a plausible primary label can hide work that still needs doing.
Summaries that lose the decisive fact
Keep authorization statements, affected features, and the requested remedy. Blindly cutting a long thread to its first and last lines can remove the customer’s clarification. Include only history relevant to this routing decision.
Calibrate for handoff cost, not account enforcement
Evaluate labeled tickets from your own queues and inspect mistakes separately for each team. A reversible handoff to the wrong queue has a different cost from delaying an unrecognized-payment report. Start with human review and record both reassignment rates and missed urgent cases.
Set any automation threshold from those observations. Confidence and the probability assigned to Fraud are different fields; neither independently authorizes account restrictions. Keep payment investigations and enforcement behind their own checks.
A Jev API example for your next integration
Call the iajev REST API with cURL. Receive a choice, probabilities, and confidence as JSON.
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "I was charged twice for my subscription last month and still haven'\''t received a refund.",
"plan": "pro",
"country": "US"
},
"decision": {
"type": "choice",
"question": "Which team should handle this request?",
"choices": [
"Billing",
"Technical",
"Sales",
"Fraud"
]
}
}'Questions about this tool
Should I include earlier tickets from the same customer?
Only include facts that explain the current issue, such as an unresolved duplicate charge or a troubleshooting step already tried. An unrelated billing dispute from months ago can distract from today’s technical request. Prefer a short relevant history over a full account archive.
What if my support organization has more than four queues?
Customize the options to match your ownership rules. The current iajev request accepts two to eight choices. For more queues, consider a first pass by department and a second pass within that department, while retaining a manual path for ambiguous tickets.
Using iajev
Add context
Include the facts needed for this decision.
Review the choices
Customize the question and options to match your workflow.
Run and review
Inspect the distribution before taking action.
Is confidence the probability that a decision is correct?
No. Confidence is a separate model estimate; the choice probabilities describe the distribution over your options. Neither is a measured accuracy guarantee.
Can I compare two inputs?
Edit the context and run the same question again to compare probabilities. Changing the question or choices starts a new comparison.