Direct answer: place an eligibility gate before lead scoring. Auditable rules should decide whether the offer, market, channel, and operating capacity fit the lead. Only then should AI rank eligible records by propensity, expected value, or urgency. When evidence is missing, use an explicit unknown state and route it to review or data collection—do not translate missing evidence into zero points or silent rejection.
A lead can visit pricing, attend a webinar, and request a demo. The company still may not sell that plan in the lead's market, support the required product version, serve that customer type, have permission for the selected channel, or have an available seller with the necessary expertise. A high score does not resolve the mismatch. It moves the wrong record to the front faster.
Separate invalid, ineligible, and low priority
- Invalid — spam, a duplicate without separate value, a false identity, or an unusable contact path.
- Ineligible — a real person or company for whom the declared offer or workflow does not apply under a current rule.
- Unknown — evidence is insufficient; the next step is enrichment, a question, or review.
- Eligible and lower priority — the company can serve the lead, but other cases have greater value, urgency, or probability.
- Eligible and higher priority — the offer applies and the record merits faster action within available capacity.
When one score represents all five states, marketing cannot tell whether to repair media, a form, data, market coverage, the offer, or sales operations. Sellers receive impossible cases. Platforms learn from ambiguous rejection labels. Finance sees lower cost per lead while cost per eligible conversation rises.
Write an Offer Eligibility Contract
- Decision unit — one offer, version, market, channel, and effective period, not “all leads.”
- Hard rules — geography, product, customer type, contract, permission, inventory, or capacity that should not be inferred probabilistically.
- Evidence — field, system of record, provenance, timestamp, freshness, and owner for resolving disagreement.
- States — eligible, ineligible, and unknown with standardized reason codes; unknown does not mean no.
- Precedence — rule order and behavior when CRM, catalog, territory, entitlement, or capacity disagrees.
- Action — route, nurture, ask, review, wait for capacity, or close with an appropriate explanation.
- Priority — a score applied only to the eligible population, with version, threshold, and validity window.
- Feedback — acceptance, first conversation, progression, revenue, return reason, and cost tied to the rule version.
The contract should fit in a versioned table before it becomes architecture. A midsize U.S. B2B company might start with one product tier, two states, one company segment, and two seller queues. Territory comes from the approved coverage table; plan eligibility comes from CRM or entitlement data; capacity comes from the work queue; intent comes from behavior. Do not ask a model to infer a restriction that a system of record should state.
Use the native CRM before buying another engine
HubSpot separates fit and engagement scores and supports different scores for different regions. That is useful, but subtracting points for an unsupported region remains a number, not necessarily a hard stop. Materialize eligibility with properties, lists, and branches; use the score to order records inside the permitted set.
Salesforce evaluates assignment entries in order and recommends a catch-all entry. The catch-all can send unknown records to a review queue instead of burying them under a default owner. Dynamics 365 can use seller attributes, availability, and capacity. A native rule is often enough when evidence is structured, current, and relatively stable.
Integration becomes the primary investment when eligibility lives outside CRM: coverage, entitlement, catalog, inventory, scheduling, authorized partners, or capacity. A model earns a role when useful evidence arrives in text or documents, volume warrants classification, and a reviewed sample exists. Even then, AI should extract and recommend; hard rules remain outside the score.
Define what AI may and may not do
AI can read a requirements note, map a mentioned product, detect a country-offer conflict, summarize evidence, propose a standardized reason, request a missing field, and prioritize eligible cases. It should preserve source and confidence and accept human correction. Run it in shadow mode before it changes owners, stages, or outreach.
Do not use it to infer sensitive criteria, credit decisions, legal eligibility, or regulated exclusions from proxies. Do not treat absence as ineligibility. Do not let a score override an explicit prohibition. NIST calls for documented scope, human oversight, and safe failure beyond knowledge limits. In this workflow, safe fallback means review, a question, or waiting—not fabricated action.
Run a six-week pilot on one offer
- Week 1 — choose one offer and reconstruct 50 to 100 recent leads, owners, returns, conversations, and outcomes.
- Week 2 — classify rules, sources, freshness, conflicts, and unknown states; name business and data owners.
- Week 3 — implement a rule baseline, review queue, and standardized reasons in the CRM without AI.
- Week 4 — run AI extraction or classification in shadow mode; review false eligible, false ineligible, and unknown cases.
- Week 5 — release one market or queue with supervision, SLA, capacity controls, logging, fallback, and reversal.
- Week 6 — compare with the prior flow and decide whether to repair data, expand rules, integrate another source, retain review, or stop.
Deliverables include the versioned eligibility table, evidence dictionary, precedence matrix, unknown queue, routing reasons, rule tests, reviewed sample, decision log, operating view, and runbook. The pilot does not require a CDP or custom model. It needs a bounded offer, observable population, and an action the team can execute.
Measure eligible conversion, not only MQL volume
Track eligible share, unknown rate, stale evidence, false eligible and false ineligible decisions, misrouting, time to owner, time to first accepted conversation, capacity consumed, returns by reason, conversion per eligible lead, contribution, and cost per eligible conversation. Watch countermetrics: improper exclusion, geographic concentration, overdue review, abandonment caused by extra questions, and rules that never surface real exceptions.
Cost grows with offers and versions, markets, rule-change frequency, systems of record, identity, APIs, availability, contractual logic, text volume, human review, audit, and support. Compare three paths: native rules, data integration, and AI classification. The model may not be the expensive part; maintaining current, reconcilable eligibility evidence often is.
Connect eligibility to the revenue loop
Compare native and custom scoring in https://makinai.co/insights/en/crm-native-ai-lead-scoring-vs-custom-model-investment, enrich without hiding uncertainty in https://makinai.co/insights/en/ai-lead-enrichment-short-form-evidence, match routing to capacity in https://makinai.co/insights/en/ai-align-demand-generation-sales-capacity, and return outcomes to acquisition through https://makinai.co/insights/en/ai-crm-revenue-feedback-loop-ad-platforms. If the CRM currently compresses restrictions, fit, intent, and priority into one number, bring MAKINAI one offer, the current rules, and an anonymized sample of returned leads through https://makinai.co/services/en/crm-ecommerce-commerce-transformation. We can scope the contract and pilot before you buy another scoring engine.
The sources document product capabilities and risk practices; they do not guarantee conversion or define legal eligibility. The contract, pilot, and metrics are editorial guidance. Privacy, accessibility, contracts, regulated sectors, and treatment criteria require review by accountable local teams. A 30-day aggregate report cannot attribute leads or revenue to one article; content impact should be assessed through relevant traffic, inquiries, and qualified opportunities when those data exist.