Lead-data due diligence should happen before procurement, not after the first campaign bounces. A polished demo can prove that a vendor interface works; it does not prove that the records match your ICP or that the fields you care about are current.
Write the acceptance test before the sales call
List the fields that decide whether a record is usable. For a B2B campaign that might be company domain, industry, employee band, geography, contact function, current employer, business email, source date, and suppression compatibility.
Define failure. If the wrong company domain is a hard rejection, say so. If employee count is allowed to be a rough band, do not score a one-band difference as equally serious.
Tell the vendor your actual ICP and request a sample drawn from it.
Audit the sample independently
For each sampled row, check the company website and at least one appropriate source for the person or role. Run email verification using your normal process.
Record field-level outcomes: correct, stale, unsupported, wrong, or unable to verify. A vendor can have excellent company data and poor mobile numbers; a single “85% accurate” claim would hide that.
Also record duplicates against your CRM and contacts that are already suppressed.
Ask provenance questions that affect risk
Useful questions include: - What categories of sources feed the data? - Is data directly observed, licensed, contributed, publicly researched, inferred, or a combination? - How is a business email generated or verified? - How often are employment and company fields refreshed? - Can a customer request deletion or correction, and how does the vendor propagate it? - Which countries are covered, and how does the vendor address applicable privacy requirements? - Can the vendor apply your do-not-contact suppression before export?
You are not trying to obtain every proprietary algorithm. You are deciding whether the supplier’s process is compatible with your own legal, contractual, and reputation requirements.
Read the contract for data-quality economics
Check how the vendor defines a “credit” or billable record. Are catch-all emails charged? Are duplicate contacts charged? Are wrong titles replaceable? How quickly must you report bad records? Can unused credits roll over?
If the product includes usage limits, export restrictions, or restrictions on reselling or sharing data, make sure your intended workflow is permitted.
Also understand renewal terms. Data vendors are often recurring subscriptions; a useful one-month pilot can become an expensive annual commitment if cancellation windows are missed.
Test CRM overlap before paying for volume
Run the sample against canonical email and company-domain fields. Report: - exact contact duplicates; - existing accounts with new contacts; - new accounts; - suppressed contacts; - fuzzy company duplicates needing review.
Ask whether the vendor can exclude existing records before delivery. “10,000 contacts” is not valuable if 3,000 already sit in your CRM.
Run a controlled downstream pilot
Send only a carefully reviewed cohort consistent with your outreach rules. Measure permanent invalid addresses, wrong-person responses, role accuracy, unsubscribe/complaint signals, and sales outcomes.
Compare with another source or internally researched cohort. A high bounce rate is obvious; a low bounce rate with terrible role fit can be just as expensive.
Keep the original vendor sample and export. Do not let enrichment overwrite it before the evaluation is complete.
Create a vendor scorecard that can support renewal
Score the supplier on: - ICP-fit rate; - field accuracy by type; - freshness; - duplicate rate; - verification transparency; - replacement handling; - support responsiveness; - usable-record cost; - downstream performance.
Update the scorecard each quarter using actual campaign results. A vendor that was excellent last year can deteriorate after coverage changes or a shift in your ICP.
The decision is not “Is this vendor legitimate?” It is “Does this source repeatedly produce records our business can verify, use, and maintain at an acceptable cost and risk?”
Ask the vendor to explain provenance before buying
A credible vendor should be able to describe where records come from, how often fields are refreshed, what “verified” means, how opt-outs or suppression requests are handled, and which fields are inferred rather than observed. “Proprietary database” is not enough to assess quality.
Request a representative sample with the same filters you plan to buy. Test domain validity, company existence, role accuracy, duplication, geographic fit, and the age of key fields. Do not let the vendor hand-select ten perfect records if the purchase will contain fifty thousand.
The contract should address permitted use, replacement or credit policy for invalid data, compliance responsibilities, deletion requests, and what happens if the source cannot substantiate rights to provide the data. Buying a list transfers data, not necessarily the legal basis to use it in every channel or jurisdiction.
Test the vendor replacement policy before the full buy
Test the vendor's replacement policy before the full purchase. Submit a small, well-documented set of records that fail the agreed acceptance criteria—such as duplicate accounts, invalid mailboxes, or clearly wrong roles—and observe what the supplier actually does. Record response time, evidence demanded, and whether replacements themselves pass review.
This exposes contract language that sounds generous but is operationally unusable. A “100% replacement guarantee” can still be poor protection if only one narrow error type qualifies or if replacement rows come from the same weak source.
Keep the test results with the vendor scorecard and renewal date. At renewal, compare promised accuracy, usable-record rate, replacement recovery, CRM overlap, and downstream outcomes. Procurement should be based on the file that survived your controls, not on the size of the vendor's database.