Ask Jev first
The writer is not the dispatcher
Run TypeSafe's Jev on twenty closed tickets. High confidence names the queue. A person still owns money and the send.
A writer model will invent a queue name if you let it. Jev will not. TypeSafe's model answers only the options you wrote down, with a probability on each, and then it stops. That is the product. This week you put it on tickets, not in a chat window.
You already know the split. Billing or technical. Blocked or can wait. Money on the line or not. Those are not essays. They are three questions. Jev takes the ticket as state and returns those three answers in one call. Your people still write the reply.
The clerk's job is not a paragraph
On a team of twenty, the first minute of a ticket is a routing call. Someone glances at the subject, picks a board, and maybe flags a refund. You have been paying a writing model to do that glance, then parsing whatever sentence came back. The sentence can be wrong in a way that still looks finished.
Alex Lieberman (@businessbarista), who built Morning Brew and now sits with operators on live queues, did not treat Jev as another place to talk. He pointed people at the mechanics.
@businessbaristaIf you want to understand how Jev works, highly recommended read
Alex Lieberman
Jev is TypeSafe's System One model. You send it the current state of a ticket and a list of typed questions. It sends back a choice from your list, a score on your scale, or a yes-or-no probability. TypeSafe calls that yes-or-no a Noul. There is no chat. There is no draft. The model cannot write the customer a sentence, which is the point.
TypeSafe publishes the call at about 70 to 500 milliseconds, with input at $0.042 per million tokens and output unmetered. Treat those as maker numbers. They tell you this is cheap enough to run on a real queue. They do not tell you Jev will name the right closer in your shop.
That is the trial. One work object: last week's closed tickets. Not a tour of primitives.
Three questions you already ask
Sit with whoever owns the helpdesk. Write the questions the way your board already splits work. If a name is not on the board, it is not an option.
- Choice: which queue. Use the real board names. Billing, technical, account, other. No invented teams.
- Score: how blocked the customer is, on the scale you already argue about in standup.
- Yes or no: is this person asking for money back.
Jev evaluates those three against the same ticket, in parallel. Adding a fourth barely changes the wait. Your code reads the answers. High confidence on the queue, and the pick is one of your names, the ticket can land on that board. Low confidence, or a refund flag, a person reads it.
TypeSafe's own pattern is that shape. Act when confidence is high. Ask for a check in the middle. Do not act when it is low. Confidence here is how peaked the probability is, not a promise the pick is true. A 1.0 can still sit on the wrong queue. You will see that on Friday if you score against the human who actually closed it.
Do not let Jev send the customer anything. Do not let it issue credit. The model has nothing to say. It only ranks the next owner.
Who moves the ticket
The ops lead does not need to learn an API. The ops lead names the questions and the floors. The person who already wires your helpdesk makes the call. Direct TypeSafe access is still early access, so the practical path this week is typesafe-ai/jev through Vercel AI Gateway, or a key from console.typesafe.ai if you already have one. Each ticket goes in as state. Jev's queue, urgency, refund flag, and confidence sit on the same row as the human closer.
Figure 1
Duty manager looks only at the misses and the low-confidence rows. Queue owners do not rewrite the questions midweek. You, the owner, set two floors and do not move them until Friday: what confidence is high enough to label a queue, and which flags always bounce to a person. Refunds always bounce. Anything that needs an apology in your voice always bounces. The writer model, if you still use one, starts after the queue is named. It does not get a vote on the name.
This is enablement, not a new stack. You keep the board you have. You keep the people who close. Jev sits in the one minute that used to be a glance.
Friday, count the matches
Your closes already have a named person on them. You will not find a published match rate for a shop this size. Nobody has a credible figure for how often Jev would have named that closer. Speed and price from TypeSafe are not a match rate.
What you can count is sitting in last week's closes, next to the human who actually finished them.
| Measure | Count |
|---|---|
| Closed tickets where Jev's queue matched the human closer | |
| Closed tickets Jev sent to a person because confidence was low | |
| Refund-flagged tickets a person still handled |
If the match rate is ugly, tighten the option names. Vague queues produce vague probabilities. "Other" will eat everything you were too shy to define. If the match rate is fine and the low-confidence pile is still the messy work, you have a dispatcher. You still do not have a closer. That is a good Friday. Leave Jev on the label. Leave the send with a person.
Try Jev on twenty closed tickets
Pick last week's closes, not the live fire hose. You want a named human closer next to each row so the score is honest.
- Export twenty closed tickets with subject, body, closer, and whether money moved.
- Call Jev once per ticket with the three questions, through
typesafe-ai/jevor a TypeSafe key you already have. - Auto-label only when confidence is high and the refund flag is off.
- Fill the three counts on Friday. Do not change a customer-facing sentence this week.
Keep the writer for the reply. Keep the owner for money. Run the dispatcher as Jev.
You already have the tickets. Call Jev on those twenty and read the misses with the duty manager.
Sources
If one workflow is eating your week, tell me which one. I'll tell you if it's worth deploying — and if it isn't.
Message Mikko on LinkedIn