Buyer acceptance criteria should define the minimum evidence required to purchase a lead, the facts that may be checked after authorized access, the exclusions that make the record ineligible, and the difference between a data defect and an ordinary commercial outcome. The criteria protect both sides only when they are versioned, visible before purchase, and connected to a bounded dispute process.
1. Translate the ICP into testable conditions
Replace broad labels such as “B2B SaaS” or “good fit” with fields and evidence: company geography, industry taxonomy, employee or revenue band with source date, buyer function, target problem, service need, excluded competitors, existing-customer conflicts, and minimum qualification evidence. Mark each condition as required, preferred, or informational.
A required condition must have a defined failure result. If headcount is missing, does the listing fail, remain eligible with uncertainty, or use another permitted source? Do not silently treat missing data as a match. Keep the seller’s attributed statements distinct from marketplace or buyer inferences in the partner-ready lead record.
2. Define what the masked preview proves
The preview should support a purchase decision without revealing unnecessary personal identity. State which criteria can be verified before purchase and which only become testable after acceptance. A buyer may see company segment, broad geography, problem category, source type, qualification date, and freshness band while name, direct contact details, and free-text notes remain masked.
Do not let a preview imply more certainty than the underlying evidence. “Decision-maker” should say whether it is a self-reported title, a CRM field, or an inference. “Verified” must name what was verified, how, and when. Apply the data-processing checklist to every revealed field.
3. Separate acceptance from outcome
| Question | Acceptance issue? | Evidence |
|---|---|---|
| The required company geography was wrong at purchase. | Potentially, if the criterion and source state were explicit. | Accepted snapshot, source, timestamp, correction history. |
| The person did not reply to outreach. | Usually not by itself. | Contact attempts may inform learning, not prove a listing defect. |
| The same lead was already owned by the buyer. | Potentially, under a documented conflict rule. | Buyer CRM match, ownership dates, deduplication result. |
| The buyer changed its ICP after purchase. | No under the earlier criteria. | Criteria version accepted at transaction time. |
The checklist cannot promise a reply, opportunity, or sale. Evaluate outcomes separately through the marketplace attribution ladder.
Once the accepted and excluded cohorts are explicit, model the economics of those acceptance rates before setting a maximum price per purchased lead.
4. Set freshness by field and event
Define a timestamp, source, and acceptable age for each material field. A qualification conversation, company size estimate, title, contact channel, and consent or notice evidence do not age at the same rate. State whether the threshold is measured at listing, reservation, purchase, or first outreach.
If a field crosses its threshold during reservation, define whether the seller must revalidate, the buyer may cancel, or the record proceeds with a visible warning. Use the lead freshness SLA to document the clocks rather than attaching one undifferentiated “fresh” badge.
5. Document exclusions and conflict checks
Before purchase, define exclusion evidence for existing customers, active opportunities, prior ownership, prohibited sectors, restricted locations, previous suppression, internal do-not-contact states, and duplicate records. Explain when the buyer may run a privacy-preserving conflict check and what result is returned.
A duplicate is not automatically a refund. The rule should distinguish the same person, the same company, a historical record, a shared domain, and an unrelated person with similar attributes. See the CRM deduplication rules.
6. Make the review window observable
Name when the review window starts, its duration, the actions that preserve or close eligibility, and the evidence required for each reason. Give the buyer enough authorized access to test the promised condition without encouraging unnecessary exports or outreach. Pause clocks during a platform incident when the buyer cannot inspect the record.
Require structured reasons—incorrect required field, stale evidence, ownership conflict, inaccessible contact channel, missing promised artifact, or policy ineligibility—plus optional context. Preserve the accepted listing snapshot so later edits cannot rewrite the transaction.
7. Assign contact and handoff responsibility
Acceptance should identify the buyer team, record owner, permitted purpose, contact policy, required notice or disclosure, suppression path, and escalation contact. Define whether the seller may continue outreach, when ownership changes operationally, and how both CRMs record that state. A purchase without contact ownership creates duplicate outreach and an avoidable dispute.
Copyable acceptance record
- Criteria version, buyer, seller, listing, timestamp, and price.
- Required, preferred, informational, missing, and excluded fields.
- Preview evidence, source, freshness, and inference labels.
- Post-access checks, ownership conflicts, and review deadline.
- Permitted purpose, contact owner, suppression, and escalation.
- Dispute reasons, evidence requirements, remedy boundaries, and decision owner.
Sources and next step
The evidence and freshness approach follows the ICO’s official accuracy guidance, which emphasizes purpose, source/status clarity, challenges, and appropriate updates, and its data minimisation guidance. Legal duties require review for the actual parties and jurisdiction.
When a condition is challenged, preserve the decision record with the lead dispute evidence packet.