Use case
Lead scoring
Score fit and buying stage from a pricing-page form in one request.
The problem
SDRs treat every demo request the same and miss high-intent engineers.
What your code does with the answer
Page sales when fit is strong and intent is evaluating or ready.
One form payload, three signals
The pricing-page payload is state: company_size, role, the note the lead wrote, and the source. Three questions come back in one call — fit (score from poor to strong), intent (choice across researching, evaluating, ready) and contact_sales (yes/no). In the example, the message about routing 40k tickets a month with exploding LLM costs reads clearly as a strong-fit, evaluating-stage lead — the case where the person is worth a human reply the same day.
What sales does with the answer
Contact within 24 hours when fit is strong and intent is evaluating or ready — a plain rule in code over three numbers. Below that bar everything still routes: strong-fit researchers to nurture, possible-fit evaluators to an SDR queue, weak fit to drip. The model reads the written message — "costs exploding", not just the fields — so a serious note from a small company scores as worth a look instead of being filtered by headcount.
Pitfalls specific to lead scoring
Do not let the score substitute for the human call: scores inform who gets a call, people own that decision — especially refusals. A "strong fit" whose description is really "anyone technical" is a catch-all, and catch-alls load the wrong queue. Include the message field every time: it is the highest-signal input, and dropping it quietly degrades everything to field-data rules.
The request shape
This is the full request the playground sends for this preset — the same JSON your server sends to /v1/systemone with a Bearer key.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"form": {
"company_size": "200-500",
"role": "Head of Engineering",
"message": "We route ~40k support tickets a month with an LLM and costs are exploding. Looking for something faster."
},
"source": "pricing page"
},
"questions": {
"fit": {
"type": "score",
"instructions": "How well does this lead fit a developer API product?",
"criteria": [
"Poor fit",
"Possible fit",
"Strong fit"
]
},
"intent": {
"type": "choice",
"instructions": "What is their buying stage?",
"criteria": {
"researching": "Early research",
"evaluating": "Comparing options now",
"ready": "Ready to buy"
}
},
"contact_sales": {
"type": "noul",
"instructions": "Should sales reach out within 24 hours?"
}
}
}'FAQ about this use case
- Is a lead decision a fairness-sensitive decision?
- Yes — keep it in a defined lane: scores inform routing, humans decide who gets called and who gets refused. Set a threshold for low-confidence leads and let those wait for a person rather than an automated no.
- What does the model catch that rules miss?
- It reads the message field, which rules ignore entirely. The winning combo is usually a typed decision for signal plus static rules for compliance: country restrictions, existing-customer dedup, vendor-list checks.
- Does the source field matter?
- Yes — pass it in state ("pricing page" vs a referral intro). The contact_sales probability reads that intent context, and your rules can still weight sources differently.