Most lead-scoring projects start with a spreadsheet of arbitrary points—10 for industry, 20 for demo requests—creating a false sense of scientific rigor. But as Isabelle Dubuis argues in a new DEV.to guide, a score alone is not a decision system. It is merely a collection of opinions expressed as arithmetic. To build a deployable system, developers and data engineers must move beyond static rankings and implement a capacity-aware pipeline that accounts for limited seller resources, time-sensitive opportunities, and the high cost of false positives.
Separate Fit, Intent, and Action
A critical first step is disentangling the five distinct objects often conflated into a single "lead score." Fit measures plausibility, intent tracks current demand, propensity estimates probability, priority determines queue position, and action dictates the next step. A high-propensity lead might rank low in priority if it is perishable or strategically less important than a lower-propensity lead already waiting in the queue. By keeping these objects separate, teams can generate actionable explanations, such as "route to enterprise queue due to verified decision-maker," rather than meaningless numbers like "Score 82."
Define the Decision Contract Before Coding
Before extracting CRM fields, Dubuis recommends writing a one-page decision contract. This document must define the decision unit, the specific outcome (e.g., sales-accepted opportunity, not "good lead"), the prediction horizon, and the available actions. Crucially, it must specify capacity constraints—how many leads each queue can honestly process—and the cost asymmetry of bothering a poor-fit prospect versus delaying a strong one. This prevents the common failure of optimizing for convenient proxies, like form submissions, which may favor students or vendors rather than profitable opportunities.
Implement a Three-Layer Architecture
The guide proposes separating eligibility, prediction, and policy into three distinct layers. Layer 1 uses deterministic eligibility gates to exclude records the organization cannot legally or operationally act on, such as competitors or those outside supported geographies. Layer 2 estimates the outcome probability, starting with transparent baselines like logistic regression rather than jumping to complex LLMs. Layer 3 is the action policy, which turns estimates into constrained actions based on capacity, expected value, and lead age. This separation allows operations to adjust queue sizes without retraining models, making change safer and attribution clearer.
Optimize at the Queue Boundary
Global accuracy is irrelevant if the team can only make forty calls per day. The system must be evaluated at realistic capacities, measuring qualified opportunities captured within the top forty leads versus those missed. A fixed threshold like "MQL = 70" can flood the team after a campaign or starve it in a quiet week. Instead, a capacity-aware policy might call the best forty eligible leads provided they exceed a minimum expected-value floor, ensuring that low-value leads are not called simply to fill a quota.
Key Takeaways
- Avoid Label Leakage: Create point-in-time feature snapshots to ensure training data only contains information available at the decision timestamp, preventing the model from learning from post-call updates.
- Preserve Abstention Paths: The system must be able to refuse a decision when key fields are missing, enrichment is stale, or calibration is unreliable, treating abstention as a valid operational state rather than a failure.
- Correct for Feedback Loops: High-ranked leads receive more attention, skewing outcome data. Use randomized holdouts and exploration slices to learn whether prioritization actually caused improvement.
- Build an Evidence Ledger: Every recommendation must be tied to a decision ledger containing the score, policy version, reason codes, human overrides, and final outcomes to enable auditing and rollback.
The Bottom Line
Lead scoring is an infrastructure problem, not just a data science one. Stop treating scores as magic bullets and start building auditable, capacity-aware systems that respect the physical limits of your sales team.