Build a Lead Scoring Model with Clear Evidence Rules

A workable lead scoring model needs three things that are easy to skip: a fixed 100-point weight budget, explicit rules for missing versus false evidence, and hard disqualifiers that override points entirely. The version below uses fit at 50, role at 20, signal at 20, and reachability at 10, plus reason codes on every scored field so anyone can explain why a record ranked where it did. Salesforce describes lead scoring as ranking prospects against criteria you choose; the weights here are one illustrative allocation, not a vendor default or a validated prediction.

Separate qualification from prioritization

A common structural mistake in a lead scoring model is asking one number to do two jobs. Qualification answers a yes-or-no question: is this record eligible to work at all? Prioritization answers a ranking question: among eligible records, which deserve attention first?

When both jobs live in the same score, ineligible records sneak through. A company far below your size floor can still accumulate points from a strong title match and a fresh funding signal, and it lands in a rep's queue looking healthy. The fix is architectural, not arithmetic: run boolean qualification gates first, then score only the survivors. A record that fails a gate gets a disqualifier code and exits the ranking regardless of its points.

If you want the conceptual grounding, the lead scoring glossary entry covers the vocabulary; this article covers the mechanics.

The 100-point weight budget

Fit gets half the budget because it changes slowest and is verifiable from company-level evidence. Role and signal split the next 40 because they explain why now and why this person. Reachability gets the smallest slice because it gates execution rather than value.

Two design rules keep this honest. First, every sub-criterion is all-or-nothing at this stage; partial credit invites arguments nobody can settle. Second, every awarded or withheld point carries a reason code, which we will get to shortly.

Signal points should come from evidence with a timestamp and a source, which is why data provenance matters as much as the weight itself. A hiring signal with no observation date is an anecdote, not a criterion.

One caution on reachability: a verified mailbox is an estimate that the address is likely to accept mail, and verification can come back inconclusive. It is not proof the person still holds the role, has any interest, or has agreed to hear from you. Score it as an execution gate, nothing more.

Missing evidence is not negative evidence

This is where scoring models quietly rot. A field can be empty for two very different reasons: nobody has checked yet, or someone checked and the answer is no. Collapsing those into the same zero destroys the model's usefulness, because it punishes records your data coverage has not reached.

The rule: a missing field earns zero points plus a reason code that queues enrichment. A confirmed false field earns zero points plus a terminal reason code, and if it touches a qualification floor, it triggers a disqualifier instead.

Worked example: two hypothetical records, same score, opposite outcomes

This is an illustrative example with invented records, not real companies.

Record A. Industry matches (15). Employee band is unknown, the field is empty (0, code FIT_SIZE_MISSING). Geography matches (10). Relevant technology confirmed (10). Fit subtotal: 15 + 0 + 10 + 10 = 35. Seniority and function both match (10 + 10 = 20). Hiring signal observed (10), no funding event (0). Signal subtotal: 10. Verified mailbox (5), no second channel (0). Reachability subtotal: 5.

Total: 35 + 20 + 10 + 5 = 70 provisional points. Status: pending mandatory size evidence, enrichment queued. Do not route the record as qualified while that gate is unknown. If enrichment confirms the employee band is in range, the record gains 15 points, rescores at 85 and can clear the size gate.

Record B. Identical evidence except the employee count is confirmed at 4 employees against a qualification floor of 20. The arithmetic would also produce 35 + 20 + 10 + 5 = 70. But the confirmed below-floor size fires DQ_SIZE_BELOW_FLOOR, a hard disqualifier. Status: disqualified. The 70 points are recorded for audit purposes and ignored for routing.

Same number, opposite decisions. That contrast is the whole argument for keeping gates separate from scores. Record A goes into an enrichment pass, which is exactly the kind of gap-filling that waterfall enrichment agents exist to close; Record B goes nowhere, and no future signal resurrects it unless the underlying fact changes.

Reason codes make the model debuggable

Attach a short code to every scoring decision: FIT_INDUSTRY_MATCH, ROLE_SENIORITY_BELOW, SIG_HIRING_OBSERVED, REACH_MAILBOX_VERIFIED, FIT_TECH_MISSING, and so on. Three payoffs follow.

Reps can inspect why a record scored 70 and challenge specific inputs or rules. Operations can find systematic gaps, such as a large share of records carrying FIT_SIZE_MISSING, which points to a coverage problem rather than a market problem. And calibration becomes tractable, because you can group outcomes by code instead of guessing which weight misfired.

Codes also let you distinguish enrichment work from targeting work. A queue full of MISSING codes is a data task. A queue full of BELOW and NO_MATCH codes means your sourcing criteria upstream need tightening.

Calibrate without pretending it is predictive ML

A weighted rules model is a prioritization policy, not a prediction engine, and it should be maintained like a policy. Adobe's Marketo documentation shows account scoring as a configured construct rather than an oracle, which is the right mental model even outside that product.

A suggested monthly routine:

1. Sample 20 records sales accepted and 20 they rejected or ignored.
2. For each, ask whether the score band matched the human judgment. Log disagreements by reason code.
3. If a single sub-criterion explains most disagreements, adjust its weight by 5 points or tighten its definition. One change per cycle.
4. Re-check threshold bands: if too many 70-plus records are being rejected, the problem may be a gate you have not written yet, not a weight.

Signal criteria deserve extra scrutiny because their usefulness fades as events age. A hiring signal from four months ago arguably should not earn the same 10 points as one from last week; adding an age window to the criterion definition is an illustrative operating choice, not a measured decay rate. The broader logic of timestamped triggers is covered in buying intent and business signals.

Tradeoffs and failure handling

All-or-nothing sub-criteria lose nuance. A 19-person company at a 20-person floor is treated the same as a 2-person company. Accept this at first; the auditability is worth more than the edge cases. If one boundary keeps producing disputes, split that criterion into bands as a deliberate second version.

Enrichment queues can back up. If MISSING codes accumulate faster than enrichment resolves them, your eligible-pending pool becomes stale. Set a maximum pending age; after it, either enrich or archive, never promote unresolved records into routing.

Disqualifiers can be wrong. Confirmed evidence still comes from sources with error rates. Keep disqualified records queryable with their triggering code so a correction can reinstate them, and require that a disqualifier cites a specific field value, never an analyst hunch.

Weights drift toward politics. When a team lobbies for its favorite signal to be worth more, require a disagreement log from the calibration routine before any change. Weights should follow logged evidence, not enthusiasm.

FAQs

Should missing data lower a lead score? No. Missing evidence should earn zero points and a reason code that queues enrichment. Only confirmed negative evidence should reduce eligibility, because scoring unknowns as failures buries records your coverage has not reached yet.

Why use hard disqualifiers instead of large negative points? Negative points can be outweighed by strong scores elsewhere, letting ineligible records reach sales. A boolean gate overrides the total entirely, keeps eligibility explicit, and leaves a clean audit trail.

How often should the model be recalibrated? On a fixed cadence, monthly is a reasonable start. Sample accepted and rejected records, log disagreements by reason code, and change one weight or definition at a time so you can trace cause and effect.

Put the model on live data

A scoring policy is only as good as the fields beneath it. AstroFabric's autonomous agents fill the missing evidence that drives MISSING codes, verify contact data behind the reachability slice, and stream scored records into your CRM and existing tools; reason-code fields are custom fields you configure and validate in your own systems before routing depends on them. Start with a signup and run this exact 50/20/20/10 worksheet against your own dataset.

Sources

• Salesforce: lead scoring
• Adobe Marketo: account score