Jev reads the ticket. The LLM writes the reply.

A customer asks for an invoice. Another says their production integration stopped working. A third wants to understand an unfamiliar charge. Generating three polished replies before deciding who should handle them spends money in the wrong order.

Classify the ticket first. Some cases need an approved macro, some need a person, and some need a drafted answer with account context. Jev can supply that decision step. It is TypeSafe's classification model: it returns labels and scores, never the reply text. Your code chooses what happens next.

The workflow below is a proposed implementation, with a hypothetical cost example. It does not report a deployed support team's results.

Give each decision its own question

Start with the latest customer message, enough recent history to interpret it, and a small set of relevant account facts. An invoice request rarely needs the customer's entire support history. A reopened outage probably needs the previous diagnosis.

Ask four separate questions:

Decision	Example answers	How the application uses it
Category	Billing, access, technical failure, product question, other	Select the responsible queue
Urgency	Routine, time-sensitive, service blocked	Order that queue using the support policy
Sentiment	Neutral, frustrated, angry, unclear	Give the reviewer context
Macro fit	A named approved macro, no suitable macro, unclear	Identify a candidate response

TypeSafe's Choice documentation describes selecting from named options and returning the option, probabilities, and confidence. Include an escape option when the list cannot cover every ticket. Several questions can share one request; that means several judgments about the supplied state, not a promise that an entire ticket export fits one call.

Keep sentiment separate from urgency. A polite report that every payment is failing deserves attention even if the customer sounds calm. An angry request for a cosmetic change should not automatically displace it.

A macro match still needs an account check

Consider this invented ticket: “Could you resend the August invoice? The download link says expired.”

The desired classification is billing, routine urgency, neutral sentiment, and the invoice-link macro. That is an expected answer for a test case, not a recorded Jev response. The application then checks the user's access and whether the invoice exists. Only after retrieving a valid link can it fill the approved macro.

For “I was charged twice and your last reply ignored it,” a billing label is insufficient. The ticket needs transaction reconciliation and history review. Letting a model select a refund-sounding paragraph does not establish that a refund is owed.

Use this routing order:

1. Apply mandatory human-review rules, including sensitive account changes and disputed charges.
2. Send missing, conflicting, or insufficiently confident decisions to manual triage.
3. Use an approved macro when its factual prerequisites pass.
4. Otherwise, ask a separate LLM for a draft using retrieved facts and the support policy.

The draft should remain a draft until the applicable review policy clears it. A classification result grants no new account permissions. If resolving the ticket requires buying a replacement job, apply a separate support repair budget.

Work out the cost per 1,000 tickets

Suppose a planning sheet uses these invented values: $0.0001 per classification and $0.01 per generated draft. These are arithmetic inputs, not Jev or LLM price quotes. Suppose the proposed routing sends 550 tickets to macros, 200 directly to humans, and 250 to generated drafts.

Inference expense	Draft every ticket	Classify, then route
Classification	$0	1,000 × $0.0001 = $0.10
Generated drafts	1,000 × $0.01 = $10.00	250 × $0.01 = $2.50
Total model spend	$10.00	$2.60

The $7.40 difference is model spend in this example. It excludes retrieval, automation fees, human review, retries, and reopened tickets. A routing mistake that adds an hour of work can erase that difference.

For your own queue, use 1,000 × classification cost + drafted tickets × draft cost, then add those other expenses to both workflows. Measure successful resolution and review time alongside the bill. If nearly every ticket still needs generation, the extra decision call may offer little financial benefit.

Test the tickets that embarrass the rule

Build a reviewed set containing ordinary requests and awkward combinations: a cancellation inside a billing complaint, an outage described without technical vocabulary, a forwarded message, and a customer who solved the first problem but reports another.

Have reviewers label the correct route before seeing Jev's answer. Compare individual categories, urgent cases missed, inappropriate macro suggestions, and the fraction requiring manual triage. Overall accuracy can hide the mistake you care about most.

Start by showing suggestions beside the existing queue. Inspect proposed macros without sending them automatically. Once the macro prerequisites and review thresholds hold up on fresh examples, automate a narrow category and continue sampling it.

Save the question version, supplied context, returned decision, actual route, and resolution against the ticket ID. Join paid calls to their receipts as described in the weekly spending review. That lets you distinguish a cheap resolved ticket from a cheap first reply that created three more messages.

You can use Jev on Vaaya, along with 500+ model options and 1,500+ endpoints. One API key, one balance, a receipt for every call.

Questions

Can Jev write a support reply?

No. Jev returns typed decisions such as categories and scores. Application code can select an approved macro, route the ticket to a person, or ask a separate generative model to draft a reply.

Does a high confidence value make a macro safe to send?

No. The application must still check that the macro applies, the account facts are current, and the action is permitted. Set thresholds using reviewed examples from your own queue.

Does classifying tickets always save money?

No. Classification adds a call. It pays for itself only when the work it avoids exceeds its cost without creating unacceptable routing errors or extra review.