๐ŸŽฏ Calibrated Lead Scorer - B2B Scores That Actually Spread avatar

๐ŸŽฏ Calibrated Lead Scorer - B2B Scores That Actually Spread

Pricing

Pay per event

Go to Apify Store
๐ŸŽฏ Calibrated Lead Scorer - B2B Scores That Actually Spread

๐ŸŽฏ 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

mohamed alaya

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

a month ago

Last modified

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:

  1. 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.
  2. 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 calibratedScore is the number to sort and tier by; rawScore is 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 calibratedScore of 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.