There is no universal score or single field that makes every inquiry qualified. Salesforce's qualification model guidance says each company must define its own qualified-prospect criteria and monitor the model over time. The contactability-first definition here applies that principle to the pre-route decision: can the Business reach this person, does the inquiry belong in its workflow, and is the evidence safe enough for automatic Delivery?
Qualified lead definition
| Dimension | Question | Evidence | Qualification rule |
|---|---|---|---|
| Contactability | Is there at least one usable way to reach the person? | Phone and email plausibility, normalization, and provider evidence | Satisfy the Business's required contact method. One valid path can rescue a weak optional path when no independent blocker remains. |
| Business fit | Does the inquiry belong in this Business's sales workflow? | Stated Interest, service eligibility, and explicit Business rules | Apply documented criteria. Do not infer need, budget, authority, or urgency from contact data alone. |
| Routing safety | Is there high-confidence evidence that automatic Delivery is unsafe? | Abuse, synthetic data, strict duplicate policy, and compliance evidence | Block only an explicit, high-confidence condition. Send uncertain or conflicting evidence to review. |
| Next action | What should happen after the decision? | Qualified, review, blocked, or error outcome with reason codes | Only an allowed outcome proceeds to Destination selection and a separate Delivery attempt. |
In Lucidity, a Lead is a sales inquiry that the system qualifies and routes. A Validation Run evaluates named checks and produces a Validation Outcome. This operating definition is intentionally narrower than a universal marketing definition: it answers whether an inbound Lead is ready for the next controlled handoff, not whether it will eventually buy.
What criteria qualify an inbound Lead?
Start with evidence that can change the routing decision. A practical model keeps contactability, fit, and risk separate so a strong signal in one category does not erase an independent blocker in another.
| Evidence area | What it can establish | What it cannot establish alone | Safe uncertain action |
|---|---|---|---|
| Phone | Format plausibility, normalized value, and configured provider evidence | Identity, consent, buying intent, or guaranteed reachability | Review ambiguous parses or provider conflicts |
| Syntax, domain evidence, disposable risk, and prior bounce evidence | Mailbox ownership, intent, or a guaranteed reply | Treat DNS or provider failure as unknown, not invalid | |
| Interest | The human-readable request and whether it fits an offered service | Budget, purchase authority, or timeline unless the person stated them | Review an incomplete or conflicting request |
| Duplicate evidence | An exact repeated identifier or recent matching contact information | That a repeated inquiry is fake or no longer relevant | Review contact duplicates unless strict suppression is configured |
| Abuse and safety | Independent, high-confidence reasons not to deliver automatically | That every unusual name, pattern, or field belongs to a bot | Combine signals and preserve the reason for review |
The 12-check Lead qualification checklist turns these evidence areas into a pre-route review. It also explains why a provider timeout or one weak optional field should not become proof that a reachable person is unqualified.
What does not make a Lead qualified by itself?
- A form submission: it proves that information entered the Intake, not that the contact data is usable or the inquiry fits the Business.
- A numerical score: a score ranks configured signals. It does not automatically explain contactability, risk, or the correct routing action.
- A valid-looking email or phone: syntax and formatting are evidence, not proof of identity, consent, or purchase intent.
- A routing decision: selecting a Destination does not prove that the later Delivery attempt succeeded.
- A GA4 event: analytics can record a lifecycle event, but the first-party Lead record should own personal contact data, validation evidence, and Delivery outcomes.
Google's
recommended lead-generation events
separate generate_lead, qualify_lead,
disqualify_lead, working_lead, and
close_convert_lead. Its
Lead acquisition report
counts new, qualified, and converted leads from different events. Those stages are
useful traffic and funnel context, but they do not replace the operational evidence
used to decide and execute a Delivery.
Qualified Lead vs MQL vs SQL
Marketing qualified lead and sales qualified lead are lifecycle labels whose meaning depends on the company. Salesforce describes an MQL as either ready for marketing or nurtured enough to pass to sales, while an SQL is ready for sales ownership or further sales qualification. Its lead qualification guide also distinguishes qualification from scoring and notes that company definitions can vary.
Lucidity's contactability-first Validation Outcome serves a different boundary. It decides whether an inbound Lead is safe and usable enough for the configured routing workflow. A Business may later apply MQL, SQL, opportunity, or customer stages in its CRM, but those stages should not hide the original validation and Delivery facts.
What are the four safe Validation Outcomes?
qualified
Required contact and fit criteria are satisfied, with no independent high-confidence blocker. The Lead may proceed to automatic Delivery.
review
Evidence is ambiguous, conflicting, incomplete, or risky. Hold the Lead for an operator decision instead of silently rejecting it.
blocked
High-confidence bad contact data, abuse, or an explicit strict policy prevents automatic Delivery. Keep the reasons for audit.
error
Validation could not complete. Apply the Business's documented fallback and do not treat infrastructure failure as proof of a bad Lead.
Qualified Lead examples
These synthetic examples show the decision boundary. They are not universal rules, real customer records, or claims about conversion likelihood.
| Synthetic inquiry | Evidence | Outcome | Why |
|---|---|---|---|
| Usable phone, weak optional email | Phone satisfies the Business rule; email is missing; Interest is clear | qualified | One required contact path is usable and no independent blocker remains |
| Usable email, recent contact duplicate | Email is plausible; the same contact submitted recently | review | A repeat may be legitimate, so duplicate evidence needs an explicit action |
| Synthetic contact patterns | Required contact paths are confidently unusable under the configured rule | blocked | Independent high-confidence evidence makes automatic Delivery unsafe |
| Provider unavailable | Local evidence is incomplete and a required external check times out | error or review fallback | Service failure is not evidence that the person is unreachable |
How should qualified Leads be measured?
Count each stage from its own first-party record. The denominator and time window must be explicit so a team does not compare submitted forms, qualified Leads, and Delivery attempts as if they were the same event.
- Accepted inquiries: raw submissions accepted through an Intake.
- Qualified Lead rate: qualified Leads divided by accepted Leads in the stated period.
- Review and blocked rates: each outcome divided by accepted Leads, with reason codes available for calibration.
- Delivery success rate: successful Deliveries divided by Delivery attempts, or first successful Delivery divided by qualified Leads when that is the declared metric.
A qualified Lead can still have a failed Delivery because the Destination or Connector has its own outcome. The Lead Delivery software guide explains the evidence needed after qualification, while the GA4 qualified Lead guide keeps those Lucidity facts separate from GA4 traffic context and its Data Freshness.
Frequently asked question
What evidence makes an inbound inquiry qualified enough to route?
An inquiry is qualified enough to route when it meets the Business's explicit requirements, has at least one usable contact path, and has no independent high-confidence blocker. If the evidence is ambiguous or conflicting, the safe result is review rather than automatic Delivery or silent rejection.
Define one auditable qualification rule in Lucidity
Bring one approved website form, the contact method your Business requires, and one Destination. See how Lucidity records Validation Checks, holds ambiguous evidence, and keeps each later Delivery outcome separate.
Request a Lead validation walkthrough