Before routing an inbound inquiry, verify that the Lead has a usable contact path, matches explicit business rules, is not a transport duplicate, and has enough evidence for a clear outcome. Ambiguous evidence belongs in review, not in a silent block. A useful qualification checklist produces one of four outcomes: qualified, review, blocked, or error, with the evidence and next action attached.

This is a pre-route safety checklist, not a universal sales score. Salesforce's lead qualification guidance says each business must define and monitor its own fit and engagement criteria. Use the checks below as stable names, then set thresholds and required fields for the Business that owns the Lead.

What should you check before routing a Lead?

# Named check Input or evidence Possible result Failure action
1 Required contact path Phone and email presence under the Business rule Present, missing, unknown Review an incomplete requirement. Block only when every required path is confidently unusable under an explicit rule.
2 Phone normalization Raw phone value plus the expected country or region Normalized, ambiguous, invalid Preserve the raw value and hold ambiguous parses. Never guess a country code silently.
3 Phone contactability evidence Number plausibility and provider evidence when configured Valid, risky, unknown, invalid Review uncertain or risky evidence. Do not call a well-formed number connected without supporting evidence.
4 Email syntax and normalization Raw email value and normalized domain Valid syntax, ambiguous, invalid Correct only safe normalization differences. Review unusual but permitted syntax instead of rewriting it.
5 Email domain and risk evidence Domain, MX or DNS evidence, disposable status and bounce history Valid, risky, unknown, invalid Treat DNS uncertainty as review or unknown. Block only configured, high-confidence combinations.
6 Name usability Name value, placeholder patterns, URLs or embedded contact data Usable, risky, missing Use name as supporting evidence only. Do not block accents, apostrophes, hyphens, mononyms or non-English names.
7 Interest completeness The human-readable summary of what the Lead is asking for Clear, incomplete, ambiguous Send incomplete intent to review. Do not invent product, service or urgency details.
8 Business and Location eligibility Resolved Business, optional Location and explicit service rules Eligible, ambiguous, out of scope Review ambiguous ownership. Block only a clearly documented eligibility failure.
9 Source and Intake integrity Submitted Source, receiving Intake and attribution evidence Explicit, derived, unknown, conflicting Preserve explicit submission data. Mark weak attribution unknown and review conflicts rather than forcing a Source.
10 Duplicate evidence Provider identifier, normalized contact values and Business time window New, idempotent repeat, recent duplicate Prevent a second record for an exact idempotency key. Review contact duplicates unless strict suppression is configured.
11 Abuse and synthetic signals Rate, field consistency, test patterns and repeated behavior Clean, risky, high confidence Combine independent signals. One weak field should not become a spam verdict or automatic block.
12 Route and audit readiness Latest Validation Outcome, evidence record and enabled Destination Qualified, review, blocked, error Route only an allowed outcome. Hold review, record blocks, and make error fallback behavior explicit.

Qualification and analytics answer different questions

Google's current recommended lead-generation events separate generate_lead, qualify_lead, and disqualify_lead. That lifecycle vocabulary is useful for reporting, but GA4 remains traffic context. The first-party Lead record should own contact data, validation evidence, routing decisions and Delivery outcomes.

How should contactability be checked?

Start with the required contact path

Decide whether this Business requires phone, email, either one, or both. A missing email is not automatically disqualifying when a valid phone satisfies the configured requirement. Likewise, an invalid phone should not erase a usable email. The decision should reflect the actual sales workflow, not a generic template.

Normalize phone numbers before comparing them

Parse the submitted value with a known regional context, then store a normalized representation for comparison and routing. The ITU's E.164 recommendation defines the international public telecommunication numbering plan. A normalized format makes exact comparison safer, but formatting alone does not prove the person can be reached.

Separate email syntax from reachability

An email parser can check whether a value follows the address structure documented in RFC 5322. That is only the syntax layer. Domain evidence, disposable status, bounce history and provider results are separate signals, and a timeout is not evidence that the person is unreachable.

Which fit fields should affect qualification?

Contactability answers whether a human can likely be reached. Fit answers whether the inquiry belongs in this Business's workflow. Keep those questions separate so a syntactically valid email does not become proof of purchase intent.

  • Name: use it as weak supporting evidence. Placeholder or URL-like values can raise review, but inclusive name handling matters.
  • Interest: require enough context to understand the request. Do not infer missing vertical-specific detail.
  • Business and Location: resolve ownership from explicit rules. If more than one destination is plausible, review the Lead instead of guessing.

Salesforce describes qualification as a blend of fit and engagement, with criteria defined jointly by the teams that receive the Leads. Its five-step process includes discovery, data, definition, engagement metrics and ongoing monitoring. The practical lesson is that qualified lead criteria need an owner and a feedback loop.

When is a duplicate a block?

Treat exact transport duplicates and contact duplicates differently. A repeated provider identifier is an idempotency problem: it should not create a second Lead. A matching phone or email within a Business time window is evidence about a recent duplicate, not proof that the new inquiry is fake.

The conservative action is review. A strict duplicate block should require an explicit Business or campaign policy, because a real person may submit again after their needs change or after a prior Delivery failed. Keep the matching fields, window and prior record reference attached for audit.

What should each Validation Outcome do?

qualified

The configured contact and fit requirements are satisfied, with no high-confidence blocker. The Lead is eligible for automatic Delivery.

review

Evidence is ambiguous, conflicting, incomplete or risky. Hold the Lead for an operator decision instead of silently discarding it.

blocked

High-confidence bad contact data, abuse or an explicit strict policy prevents automatic Delivery. Preserve the reasons for audit.

error

Validation could not complete. Apply a documented fallback, normally review, and never treat an infrastructure failure as proof of a bad Lead.

The outcome is not the Delivery result. A qualified Lead may be routed to one or more Destinations, and each attempt has its own Delivery outcome. Keep the qualification decision and the downstream handoff evidence as separate first-party facts.

What should the pre-route signoff record?

  1. The Business rule version used for the decision.
  2. Each named Validation Check, status and non-secret reason code.
  3. The normalized comparison values needed for duplicate detection.
  4. The final Validation Outcome and whether it was automatic or manual.
  5. The Destination selected by the routing rule.
  6. The later Delivery attempt and outcome, kept separate from qualification.

This audit trail makes false positives measurable. Review decisions can reveal which checks are too strict, while failed Deliveries can reveal a routing or Connector problem that qualification alone could never detect.

How does this fit a website Lead workflow?

Start with the accepted inquiry, not a button click. The GA4 form tracking guide explains how to measure the confirmed browser event without confusing it with the durable Lead. For the wider measurement boundary, read how to measure qualified Leads with GA4 context.

Lucidity's Lead Validation workflow keeps the Validation Outcome with the first-party Lead, then routes eligible Leads to a Destination and records each Delivery attempt. GA4 remains traffic context and may have different Data Freshness from Lucidity's operational facts.

Validate one real Lead path before automatic Delivery

Bring one approved website form, your contact requirements and one Destination. See how Lucidity records the checks, holds ambiguous evidence and keeps the Delivery outcome attached.

Request a validation walkthrough