JevSeptember 23, 2026
A weekly health score for every account
Use Jev to classify account signals each week, preserve the evidence behind each flag, and spend on follow-up only when someone has a useful action to take.
The top ten accounts usually get discussed. The rest get a dashboard and a hope that somebody notices the warning signs.
A weekly Jev pass can give every account a place in the review queue. Collect a small packet of recent usage, support, and customer messages; classify the evidence; then assign follow-up where it is warranted. Expensive research and generated account plans come later, after a person or a rule has identified a useful next step.
Jev is TypeSafe's classification and scoring model. It returns typed answers instead of writing the customer-success memo. TypeSafe's introduction describes that separation. The workflow below is an implementation proposal with fictional examples, not a report of measured churn reduction.
Give every account the same weekly snapshot
Choose a cutoff, such as Monday at 08:00 UTC, and build one record per account using information available by that time. Compare the last seven complete days with a suitable earlier period. Your code should calculate counts and changes before asking a model what the evidence suggests.
Include the product events associated with value, open support issues, resolution status, recent customer messages, and renewal timing when your system already holds it. Preserve source IDs and timestamps. A ticket that was closed last Friday should not appear as an unresolved blocker because an old summary missed the resolution.
A compact fictional packet might contain:
| Signal | Observation | Source |
|---|---|---|
| Core workflow | Successful exports fell from 12 to 3 | Weekly event query |
| Support | Export permissions issue remains open | Ticket T-42 |
| Customer message | Admin asks how to add a second team | Message M-18 |
| Coverage | Event sync current; email sync two days late | Connector status |
This account has both a problem and an expansion signal. Forcing it into one red-or-green label would discard information someone needs.
Remove unrelated personal content before sending the packet. Keep tenant boundaries intact, restrict source links to people who can already access the account, and set a retention period for snapshots. TypeSafe's state guidance explains how to supply structured context; your application remains responsible for selecting that context.
Separate health, risk, expansion, and ownership
Ask narrow questions. One Score can assess whether the core workflow appears to deliver value. A second can assess the severity of unresolved blockers. A Choice can classify expansion evidence as explicit_request, possible_signal, or none_observed. Another Choice can assign a review category such as support_owner, account_owner, data_review, or routine.
Write descriptive levels for each Score. For workflow health, three possible levels are “core task repeatedly blocked,” “task completes with recurring friction,” and “task completes without a reported blocker.” Define which sources count and how old they may be. Jev's Score documentation describes ordered rubrics and fractional scores between levels.
Keep coverage in a separate field calculated from connector status and source dates. No recent tickets may mean a quiet customer. It may also mean a broken integration. An account with insufficient evidence belongs in unknown, even if the model returns a confident answer about the small amount it saw.
The account owner can still choose to combine dimensions into a display score. For an illustrative three-level health rubric ranging from 0 to 2, code could display 100 × score / 2. A result of 75 means the weighted rubric position is 1.5. It does not mean a 75% chance of renewal. Retain the component scores so nobody has to reverse-engineer a single number.
Attach evidence without asking Jev to invent a rationale
Store the account ID, snapshot cutoff, question version, model version, answers, and source references together. Jev's answer should select from your categories; the application should supply the underlying evidence.
For example, when the blocker question evaluates ticket T-42, save that known ticket ID beside the answer. Show its title, current status, and a permitted excerpt. Do not ask the classifier to generate a paragraph explaining events or to produce links it has never seen.
The fictional account above might enter the support owner's queue with T-42 attached, while M-18 appears in an expansion column for the account owner. Resolving the export issue may be the immediate task. Writing a long expansion email before resolving it would add work at the wrong time.
This follows the same ordering as enriching signups after meaningful product activity: collect a signal, decide what it warrants, then authorize the next expense.
Budget the weekly pass
For N account packets at an observed classification cost of j each, the decision pass costs N × j. If owners request generated briefs for F flagged accounts at an average cost of d, add F × d, then include retrieval, retries and review time. A model-only reference for generating a summary for every account is N × d; the two approaches produce different outputs, so compare the usefulness of the review queue as well as its bill.
Reuse unchanged packets where the freshness policy allows it. Count the Jev requests actually made, including paid retries, and join them to the weekly run ID. Use those receipts to estimate the next week's ceiling instead of borrowing a best-case price from an unrelated prompt.
Test earlier weeks against later outcomes
Build the evaluation from historical snapshots, not today's CRM export. Reconstruct what the team could have known on each cutoff date, freeze the rubric, and compare its flags with outcomes that happened afterward. Later cancellation notes and revised account stages must stay out of the input.
Use an earlier period to adjust the questions and a later period to evaluate them. Compare against a simple baseline such as unresolved critical tickets or a sustained usage drop. Review missed accounts as well as the ones the system flagged. Otherwise a quiet queue can look successful while it overlooks customers who needed help.
Measure alert precision, missed actionable accounts, owner review time, and time until someone acts. Renewal is a separate, slower outcome with many causes. Log owner overrides and reasons, including stale evidence and a mismatch between the rubric and the product.
Schedule the weekly pass with a spending ceiling, cache unchanged packets, and reserve expensive account research for a specific unanswered question. Begin with a queue that owners review. Enable automatic internal task creation only after the labels produce useful work at a volume the team can handle.
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
Does a Jev health score predict whether an account will churn?
It evaluates the evidence against your rubric. A health score becomes a useful predictor only after you test it against later outcomes. Model confidence is not an account's probability of renewing.
What happens when an account has little recent data?
Keep data coverage separate from health. Missing events, stale contacts, and disconnected sources should produce an unknown or review state, not a healthy label.
Does Jev write the account summary or customer email?
No. Jev returns typed decisions and scores. Your application can display source excerpts and templates, or ask a separate language model to draft a message after an owner chooses the next action.