JevSeptember 23, 2026
Only pay to enrich the CRM records worth calling
Put a Jev fit check before OneFind enrichment, cap each accepted lookup, and measure usable contacts alongside spending and missed opportunities.
A CRM with ten thousand incomplete contacts does not need ten thousand email lookups. It needs a decision about which records would change the team's next action if an email were found.
Use Jev to classify fit from information already in the CRM. Send accepted records to OneFind with a spending limit. Keep the uncertain ones in a review queue. This puts the inexpensive decision before the lookup, while keeping the spending decision in code.
Jev evaluates the supplied record and returns a label or score. It cannot discover the missing employer, verify an email, or write the outreach message. TypeSafe's documentation defines it as a model for structured decisions. The workflow here combines that decision step with a separate enrichment service.
Remove records that need no model call
Start with ordinary rules. Skip a fresh verified contact, a duplicate identity, a record already being researched, and any record excluded by your contact policy. Hold back records with no identifier strong enough to resolve a person. An empty employer field does not authorize guessing a company from a common name.
Give each remaining record a stable ID and an enrichment purpose. “Find the work email for an account owner to review” is more useful than “complete the database.” Decide what makes a returned value usable, including freshness, identity match, and verification requirements.
Cache by normalized identity and purpose with an expiry date. A retried import should not purchase the same information again because the row arrived with different capitalization.
Let Jev choose among enrich, skip, and review
Send only the fields relevant to fit: known role, known company, product use case, observed activity, and the specific gap you want to fill. Distinguish a field entered by the person from an inference copied out of an old campaign.
The Choice rubric can be plain:
| Choice | Meaning |
|---|---|
enrich |
Known role and company fit the campaign, and a missing contact field blocks a defined next step |
skip |
Available evidence clearly places the record outside the campaign |
review |
Identity, fit, or the reason for enrichment remains unclear |
Choose an automation threshold using labeled examples from your own CRM. Preserve the full answer distribution. TypeSafe's confidence guidance explains why an uncertain answer should lead to a different path; it does not supply a universal threshold for your campaign.
This gate must work with information you already have. Paying to enrich the whole list so the classifier can decide which rows deserve enrichment defeats its purpose. If every record is too sparse to judge, improve the input or run a deliberately budgeted research sample first.
A one-cent lookup can still leave you without an email
OneFind separates discovery from deeper contact lookup. The synchronous API finds people without contact data. The deep route accepts a query or identifiers and can try several vendors under a budget. Its current reference documents the difference.
For a name-and-company input, consider this illustrative settlement pattern based on the documented waterfall:
| Hop | Example outcome | Charge in this example |
|---|---|---|
| Exa | Resolves a matching profile | 1¢ |
| ContactOut | Returns no contact data | 0¢ |
| Tomba | Returns no contact data | 0¢ |
| Total | Person match, no email or phone | 1¢ |
The cent paid for the successful profile lookup. It did not buy a reachable contact. This table illustrates a possible outcome, not a receipt or a general price promise. A later successful contact hop changes the amount, and current prices should be checked before a run.
Keep enriched: true with email: null distinct from a row that was never enriched. The first says a lookup was attempted without finding an email. The second says the workflow has not tried. Neither should become a guessed address in the CRM.
Enforce the limit before starting the job
For predictable per-record control, submit each accepted identifier as its own deep job with an explicit budgetCents, within the endpoint's supported range. A multi-record job has a shared job budget; it does not automatically give every row the same allowance.
Check the job cap and daily remaining budget in code before submission. Store the returned job ID and poll that job. Repeating the submission to check progress starts more work. Distinguish the reserved amount from the final charge and release unused allowance in your own scheduler after the job settles.
For async receipts, read the job's charge rather than the outer poll charge, which may be zero. Record the provider hops and source dates beside the result. The same discipline applies across the gated AI SDR workflow: a favorable model answer never increases the spending ceiling.
Count contacts someone could use
Track two denominators. Cost per attempted record tells you what the lookup machinery costs. Cost per fresh usable contact tells you whether the output helps the campaign.
In a fictional planning example, suppose 200 records remain after deterministic checks, Jev accepts 40, and the run produces 16 usable contacts. If classification and lookups together cost $4, the cost is $0.10 per attempted enrichment and $0.25 per usable contact. These are assumed figures, not measured results or service quotes.
Add hosting, verification, retries, and review costs when comparing with an ungated process. Audit a permitted sample of skipped records, because savings from rejecting good prospects are expensive in a different way. Track identity errors separately from missing data so a confidently wrong match cannot count as success.
Begin with proposed decisions and a fixed review sample. Once the rubric is useful, enable paid enrichment for accepted records under a small daily cap. Return the verified fields to the account owner with their sources; deciding whether to contact the person remains a separate action.
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 OneFind always cost one cent per contact?
No. The synchronous OneFind API currently lists a 2-cent search price without contact data. Deep enrichment charges successful vendor hops against a budget. A 1-cent Exa match can still leave email and phone fields empty.
Can Jev find the missing email itself?
No. Jev classifies the evidence you provide. OneFind performs the lookup after your code accepts the record and checks its budget.
How do I know whether the enrichment gate skips good prospects?
Review a permitted sample of skipped records as well as accepted ones. Track false skips, unresolved identities, fresh usable contacts, and the complete cost of the workflow.