B2B Leads QA: Fit, Role, Freshness, Reachability, and Risk

A B2B lead is a record of a person or organization that may be relevant to an offering and may be eligible for a defined follow-up. Lead QA verifies separate questions: account fit, the person’s role, evidence date, contact-point reachability, identity and duplicate risk, and whether the intended use is permitted. None of those fields proves buying intent.

There is no universal lead-quality score. A weighted total can hide a hard failure: the wrong person, a duplicate identity, an invalid address, an objection, or a use the team is not permitted to make. Verify hard stops first. Prioritize only the records that survive.

A lead is not an account, contact, opportunity, marketing-qualified lead, or sales-qualified lead. Microsoft Dynamics’ qualification documentation illustrates the distinction by allowing qualification to create or match separate account, contact, and opportunity records. Product behavior varies, but the data-model lesson travels: person, organization, buying process, and acquisition record are different entities.

The six-part QA contract#

Fit should be rule-based rather than intuitive. Record the attribute, its source, and why it matters to the offering. “Looks enterprise” is not evidence. A verified company size can support a declared segmentation rule, but it still does not reveal the person’s authority or current project.

Role needs the same discipline. A title can suggest a function, not prove decision power. Distinguish user, evaluator, technical reviewer, budget holder, executive sponsor, procurement, and unknown only when the evidence supports that relationship. Unknown is a valid state; invented certainty is not.

Freshness belongs to fields, not files#

A record does not become fresh because one enrichment job ran today. Company domain, employment, title, phone, email, consent, account status, and fit evidence change at different rates. Store the source and verified-at timestamp with each volatile field or evidence bundle.

Do not invent one cross-industry expiry window. A team should define review triggers based on volatility, consequence, and use. A role used for one manual research call carries a different risk from a role used to launch a large automated sequence. When a required field is beyond its approved window, route it to verification instead of silently treating stale as false or current.

Reachability is not permission#

An address can accept mail and still be inappropriate for a particular message. Permission and lawful use depend on jurisdiction, recipient type, source, purpose, channel, notice, preferences, and other facts. The UK ICO’s B2B marketing guidance shows how even one jurisdiction distinguishes corporate subscribers, sole traders, electronic mail, calls, consent, and legitimate interests.

That guidance is not a global permission slip. It supports a more general operating boundary: store the intended purpose and channel, retain the data source, provide required privacy information, evaluate the applicable basis, and honor objection or opt-out. Obtain qualified legal review for the actual regions and campaign.

Suppression must be durable. Microsoft documents contact-point consent controls that can share preference updates across integrated applications. The product implementation is optional; the system requirement is not. A downstream tool must not reactivate a suppressed address because its local copy was stale.

Resolve identity before qualification#

Duplicate rules create candidates, not truth. Dynamics documents signals including the same email, same phone, similar lead and company names, and similar name plus email domain. Those signals can catch obvious duplicates, but shared mailboxes, recycled numbers, name collisions, subsidiaries, consultants, and job changes still need review.

Before merging, compare source provenance, timestamps, activity history, organization relationships, consent and suppression, ownership, and open processes. Preserve the more restrictive communication state when policy requires it. Never let an automatic merge erase the evidence needed to understand why a record was suppressed or qualified.

Run QA in dependency order#

Prioritization comes after validity#

Once a record passes the hard gates, a team can prioritize based on declared fit, role, first-party behavior, timing, or sales capacity. Keep the component evidence visible. A score should accelerate review, not erase the reasons, unknowns, or disqualifying conditions underneath it.