๐ฏ Calibrated Lead Scorer - B2B Scores That Actually Spread
Pricing
Pay per event
๐ฏ Calibrated Lead Scorer - B2B Scores That Actually Spread
๐ฏ Score B2B leads with a weighted, fully configurable rubric, no LLM calls. โ Fixes the classic AI-scorer failure mode where every lead lands at a confident-sounding 70-80: a percentile-rank calibration pass stretches the batch across the full 0-100 range.
Pricing
Pay per event
Rating
0.0
(0)
Developer
mohamed alaya
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
a month ago
Last modified
Categories
Share
Calibrated Lead Scorer
Score B2B leads for sales prioritisation with a transparent, fully configurable rubric โ no LLM calls, no network requests, nothing non-deterministic. Run it twice on the same input and you get byte-identical scores back.
The problem this actor exists to fix
Point an LLM at a list of leads and ask it to score them 0-100 and you get back a wall of confident-sounding reasoning and a distribution that bunches almost every lead at 70-80. The model is not wrong about any individual lead, but the scores are useless for ranking โ if 40 of your 50 leads are all "78", you have not prioritised anything. That bunching is not a prompting problem; it is what happens when a system produces a plausible-sounding absolute judgement instead of a genuinely comparative one.
This actor separates the two problems on purpose:
- RAW score (0-100) โ an explicit, weighted rubric over firmographics (employee count, revenue), fit signals (industry/country/job-title match against your ICP), contact quality (corporate vs. free email, has a website), and intent signals (tech stack, hiring, funding). Every weight is a plain integer you control. Each lead gets a full explanation: which features fired, what value was read from the input, and how many points (positive or negative, around a neutral 50 baseline) that feature contributed.
- CALIBRATION โ a percentile-rank transform applied across the whole batch. Whatever spread
genuinely exists in the raw scores gets stretched across the full 0-100 range: the
highest-raw-scoring lead in the batch becomes 100, the lowest becomes 0, and everything else is
placed by rank, with ties sharing the average rank of their group. The output
calibratedScoreis the number to sort and tier by;rawScoreis kept alongside it so you can see what the rubric actually thought before ranking.
Input
Pass leads inline and/or sourceDatasetIds. All feature weights, ICP fields and tier cutoffs
have sensible defaults โ the minimum viable run is just { "leads": [...] }.
{"leads": [{ "employeeCount": 220, "industry": "SaaS", "country": "United States", "email": "vp@acme.com", "jobTitle": "VP of Sales", "isHiring": true }],"icpIndustries": ["SaaS", "Industrial Automation"],"icpCountries": ["United States", "Canada"],"tierACutoff": 90, "tierBCutoff": 70, "tierCCutoff": 40}
Output
One row per lead (type: "lead") with tier (A/B/C/D), calibratedScore, rawScore,
featuresUsed, and โ unless disabled โ an explanation array of
{ feature, label, value, points, reason }. Malformed input entries (null, arrays, non-objects)
are never silently dropped: skip them from scoring and, when includeSkipped is true, emit a
type: "skipped" row with the reason. The key-value store's SUMMARY reports the raw and
calibrated score distributions (min/max/mean/stdev) so you can sanity-check the spread yourself.
Honest limitations โ read before you trust the ranking
- Calibration is relative, not absolute. A
calibratedScoreof 80 means "ranks better than 80% of this batch", not "this lead is worth 80 points of pipeline". Run the same lead in a batch of much stronger leads and its calibrated score will drop, even though nothing about the lead itself changed. - Needs a reasonably sized, varied batch. With fewer than ~10-20 leads, or a batch where every lead is genuinely similar, there is little real spread to calibrate โ the transform cannot invent variance that is not present in the raw scores, and with a single lead it passes the raw score through unchanged.
- Garbage in, garbage out on feature data. A lead missing every optional field (no industry, no email, no job title) simply has fewer features contribute to its raw score and lands near the neutral 50 baseline โ this is not the same as "this is a bad lead", just "this lead has thin data".
- No semantic understanding. There is no LLM here. Industry/country/job-title matching against
your ICP is exact-or-fuzzy string similarity (shared with
entity-resolver's matching engine), not an understanding of what the company actually does. "FinTech" and "Financial Technology" will match well; a genuinely novel industry description that shares no tokens with your ICP list will not, even if a human would recognise the fit instantly. - The rubric encodes assumptions, not universal truth. Default weights favour larger companies, senior titles and corporate email โ reasonable defaults for a typical enterprise B2B motion, wrong for a PLG/SMB motion. Every weight is configurable; the defaults are a starting point, not a verdict.


