A provider's “verified” badge is a claim about an unspecified test until the buyer can answer: which field, tested how, against which identity, on what date, with which result?
An email address can have valid syntax and still belong to the wrong person. A mail server can accept a probe without proving that a message will reach a mailbox. A number can ring and still be a switchboard, a recycled mobile, or the wrong employee. A current role can be well supported while the contact field remains unknown.
Contact quality is therefore not one Boolean value. It is a chain of field-level observations, identity evidence, provenance, and a decision for a defined use. This article turns that chain into a reviewable workflow, a reproducible provider test, and a buy-or-stop decision based on raw counts rather than a vendor badge.
Define verification by field and method
Use separate observations rather than collapsing every check into verified = true.
If a provider cannot explain its method, store the badge only as provider_claimed_verified, not as confirmed truth. A label such as “valid,” “premium,” “direct,” or “verified mobile” should be mapped to the provider's documented definition and tested on your own segment.
Use result states that preserve uncertainty
Every requested field should end in one of these states:
These states separate availability from correctness. A no-result is not a false value. An inconclusive result is not a confirmed error. A blocked value is not a provider-quality observation and should not be added to the provider's denominator unless the test protocol explicitly measures that gate.
Build the comparison Sheet before testing a provider
Leadbase is useful here because the test needs an operating record, not because Leadbase can make a provider's verification claim true. Start with already accepted accounts and the specific roles your team actually needs. Then create one shared, typed comparison Sheet in which the baseline, provider proposal, evidence, and review decision remain distinguishable.
For each requested field, keep explicit columns for:
- accepted account and intended role;
- original value and its source or owner;
- proposed value, provider, method, source link, and observation date;
- provider result state and confidence, where supplied;
- the independent review state from the protocol above;
- reviewer, review date, reason, and final keep/replace/reject decision;
- separate quality, suppression, and campaign-approval states.
Leadbase's focused enrichment can use only the selected context columns for a defined research task. The completed result can be inspected with its confidence, concise summary, and source links before it is accepted; an uncertain search can remain a no-result instead of being forced into a value. Those are review aids, not independent proof. The reviewer still applies the field contract and can reject the proposal. See the current enrichment workflow documentation.
Freeze the test cohort before the first provider run. In practice, preserve the baseline as a named version or controlled export, restrict editing with Sheet permissions, and use revision history to make later changes visible. If the Assistant helps structure or research the batch, keep actions behind the appropriate approval setting. This gives the test an inspectable history without pretending the Sheet itself certifies the data. The relevant controls are documented under history and recovery, sharing and permissions, and Assistant approvals.
Define the measurement before comparing vendors. Ask Leadbase to design the verification scorecard around a fixed cohort of accepted accounts and known edge cases: catch-all domains, recycled numbers, stale roles, conflicts, and no-results. Every provider should face the same requests, field contract, evidence standard, and reviewer rules in a frozen comparison Sheet.
Qualify the account and role before contact lookup
Contact lookup should begin with accepted account and role decisions, not a large list of names.
- Accept the account. Record the entity, sites, fit criteria, evidence, exclusions, decision version, and owner.
- Define the role family. Specify the problem owner, technical validator, commercial approver, or other role needed for the use case. Preserve original local titles rather than matching a translated title string alone.
- Confirm the employment relationship. Link person, account, role scope, source, and observation date. If the person changed companies, preserve the historical relationship and create or update the current one explicitly.
- Request only the channel-needed field. A work-email workflow does not automatically need a mobile number. A call workflow does not need an inferred email merely because the provider can return it.
- Stage the result beside the original. Keep provider, source, method, date, status, confidence, and proposed value without overwriting the accepted field.
- Review conflicts and uncertainty. Apply the written field rule and record who accepted or rejected the proposal.
- Run suppression and campaign gates immediately before activation. A quality-approved field can still be blocked for the intended purpose or channel.
This order protects both cost and interpretation. The team does not pay for fields on rejected accounts, and the reviewer has enough context to decide whether a returned value belongs to the right person and role.
Write a field contract for the intended channel
A reproducible lookup begins with a field contract written before seeing provider output.
Set the freshness window according to the cost of being wrong and the evidence available. Do not cite a universal contact-decay percentage: industries, roles, countries, sources, and fields change at different rates. Report the actual observation-age distribution in your batch.
Handle ambiguous email and phone signals explicitly
Catch-all and accept-all domains
A catch-all or accept-all configuration can make a server appear to accept mail for addresses that do not map cleanly to a confirmed individual mailbox. Treat the endpoint as inconclusive unless additional evidence confirms the specific address and identity. Do not turn domain-level acceptance into mailbox-level certainty.
Keep this attribute separate from syntax and identity. A contact may have a strongly supported role and a plausible email pattern while mailbox reachability remains unknown.
Recycled, shared, and switchboard numbers
A connected phone number does not prove current ownership. Numbers can be reassigned, shared by a team, routed through a switchboard, or attached to a previous employee. Preserve the provider's field type and observation date, then confirm the person/company association according to the pilot rule.
If a call reaches a different person, mark the proposed identity confirmed incorrect and update suppression or correction workflows where applicable. Do not simply replace the name and reuse the number for another campaign without a new identity and purpose review.
Role changes and stale relationships
Keep person identity separate from employment. When evidence supports a new employer or role, close or date the old relationship rather than deleting it. Reassess every field whose meaning depended on the old employer, including the work email, direct number, account owner, campaign membership, and role relevance.
Conflicting values
Use field-level authority. A returned value may be newer but less well sourced than the CRM value; a CRM value may be old but tied to a current customer relationship. Preserve both candidate and accepted values, their dates and sources, then let the named field owner decide. “Latest timestamp wins” is not enough when sources observe different facts.
Test a provider with a frozen, labelled batch
The following numbers are invented only to demonstrate the method. They are not Leadbase results, provider performance, or a market benchmark.
Suppose a team freezes 200 accepted account-role requests and asks one provider for one current work email per request. The provider does not see a different test set, and the team fixes its verification rules before results arrive.
The reviewer uses independent current evidence where available and assigns one outcome per request:
- 118 returned emails are confirmed correct;
- 14 returned emails are confirmed incorrect;
- 24 returned emails remain inconclusive, including catch-all or unresolved identity cases;
- 44 requests receive no result;
- of the 118 confirmed-correct emails, 96 also fall within the predetermined freshness window and satisfy every other technical quality gate.
The provider charges €780. Review takes 10 hours at a hypothetical loaded rate of €60 per hour, so total test cost is €1,380.
Do not report “89.4% accurate” without the other denominators. That number excludes 24 inconclusive returns and 44 no-results. Conversely, counting every no-result as incorrect would confuse availability with truth.
Set acceptance thresholds before the test and report strata that matter: country, role family, company size, source age, domain type, provider method, and field type. Double-review a subset. If reviewers disagree frequently, improve the adjudication rule before using the result to rank providers.
The 96 “usable” records in this example have passed the stated data-quality gates only. They are not automatically approved for outreach.
Turn the raw counts into a buy, narrow, or stop decision
Decide the thresholds before the provider sees the batch. Otherwise a team can always choose the denominator or segment that flatters the result. At minimum, set limits for usable yield, confirmed incorrect values, inconclusive returns, no-results, observation age, review time, and total cost per quality-approved record.
The provider decision should follow the failure pattern, not one blended percentage:
Leadbase can keep each provider's proposed value, evidence, no-result, reviewer outcome, and cost beside the same frozen request cohort. That makes it possible to compare providers on identical denominators and export only the controlled decision set for the next approved workflow. It does not turn Leadbase into the verifier, promise provider coverage or accuracy, or make the resulting contacts lawful or channel-approved.
Already have raw provider output? Keep it unsummarised and ask Leadbase to audit the denominators: returned values, no-results, reviewer outcomes, costs, and the original request count. The review should end with a documented buy, narrow, stop, or inconclusive decision for the tested segment—even when the evidence argues against a purchase.
Keep technical quality separate from permission to contact
Scope — not legal advice: This section states an operational boundary, not whether a specific campaign is lawful. The official sources were checked on 8 August 2026. Have qualified counsel or the responsible privacy function approve the actual countries, sources, purposes, audiences, and channels.
For EU work, three decisions remain separate:
- Is the field technically and semantically reliable enough for the intended operation?
- May the organisation collect, enrich, store, disclose, and otherwise process the personal data for the defined purpose under the GDPR?
- May the organisation use the chosen communication channel under the ePrivacy Directive and applicable national rules? For Germany, § 7 UWG is a central channel-specific source.
A syntactically valid email, accepted mail-server response, connected phone, public professional profile, provider contract, or “verified” badge does not answer the second or third question. A legitimate data-processing basis does not by itself approve every channel, and technical reachability does not defeat an objection or suppression state.
Store the campaign, country, channel, purpose, approval record, transparency requirements, and suppression result separately from contact quality. Re-run the applicable checks immediately before activation because the campaign or control state can change after lookup.
Review before activation and learn from outcomes
The activation queue should include only records that passed account, role, field-quality, freshness, provenance, suppression, and campaign gates. Keep review, unknown, no result, conflict, stale, and blocked outside automatic activation.
After the operational outcome, record field-specific feedback without rewriting history:
- delivered, bounced, temporary failure, or provider-specific email outcome;
- correct person, wrong person, switchboard, disconnected, reassigned, or unknown phone outcome;
- current role, changed role, left company, wrong account, or insufficient evidence;
- correction, objection, exclusion, or deletion workflow triggered;
- source, provider, batch, campaign, and observation timestamp.
A delivered email does not prove that the original identity decision was correct. A reply can confirm some facts, but absence of a reply proves neither wrong data nor lack of interest. Use labelled corrections to refresh the test set and compare providers over time without treating engagement as a universal verification oracle.
Before repeating lookup, check whether the failure came from missing inputs, provider coverage, a stale role, a conflict, a blocked purpose, or a changed field contract. Blind retries can spend credits and overwrite the evidence needed to diagnose the problem.
A verified badge is not a buying decision
A credible provider test preserves what procurement copy tends to compress: the original field, proposed field, identity relationship, source, date, method, uncertainty, no-result, reviewer outcome, and denominator. It also keeps technical quality separate from the permission to process data or use a channel.
Leadbase's role is deliberately narrower and more useful: give the team a shared, controlled place to qualify already accepted accounts, stage focused research beside the baseline, review evidence, recover history, and carry only an approved decision set forward. The provider still has to earn the purchase on your segment. Your team still owns the verification protocol, provider due diligence, suppression, campaign approval, and activation decision.
That is a stronger definition of “verified”: not a promise of permanent truth, but a field-level claim that survived a dated, reviewable test with visible uncertainty and a denominator nobody can hide.
