A lead dispute evidence packet should contain the transaction snapshot, applicable acceptance and policy versions, record provenance and freshness, identity and ownership checks, authorized access events, the buyer’s structured reason, the seller’s response, corrections, and the reviewer’s reasoned decision. Preserve only evidence necessary for the review, restrict access, and do not treat a failed sales outcome as proof that the listing was defective.
1. Open a case without rewriting the transaction
Create a case ID and freeze the relevant listing and acceptance snapshots. Record buyer, seller, marketplace listing, transaction, timestamps, amount, review deadline, claimed reason, and requested remedy. Later CRM updates may be useful evidence, but they must not replace what each party saw and accepted at the time.
Link the exact buyer acceptance criteria version. If the policy or ICP changed after purchase, the reviewer should evaluate the earlier contract and criteria rather than today’s settings.
2. Classify the claim before collecting everything
| Claim class | Core question | Minimum evidence |
|---|---|---|
| Incorrect fact | Was a promised material field wrong or misleading at acceptance? | Accepted value, source/status, timestamp, correction evidence. |
| Stale evidence | Had a required field crossed its published freshness threshold? | Field clock, source event, listing/purchase time, SLA version. |
| Ownership conflict | Did the buyer already own or actively work the same eligible identity? | CRM IDs, normalized identifiers, ownership dates, conflict rule. |
| Missing artifact | Was a promised record, note, or verification result absent after access? | Handoff schema, access event, received packet. |
| Outcome dissatisfaction | Is the complaint only that the person did not reply, meet, or buy? | Policy boundary and outreach log, without implying a guarantee. |
Classification limits unnecessary collection and routes the case to the correct owner. It also prevents commercial disappointment from being converted into a false data-accuracy claim.
3. Preserve the listing and handoff evidence
Include the masked preview, accepted handoff record, source and attribution for material fields, qualification event, freshness timestamps, inference labels, exclusions, and seller attestation. Hash or otherwise bind exported evidence to the case where the system supports it. Record who obtained the evidence and when.
Use the partner-ready lead record as the field inventory. Do not attach unrelated free-text notes, entire CRM exports, or another person’s record merely because they are easy to collect.
4. Show access, contact, and system events
Record reservation, purchase, reveal, export, assignment, CRM sync, conflict-check result, first authorized view, first contact attempt, suppression, correction, and incident events. Distinguish platform timestamps from buyer-supplied statements. If a webhook or integration failed, include the error, retry, and final state.
For duplicate claims, preserve normalized identifiers and rule output without assuming one shared domain means one company. Apply the CRM deduplication rules and document any human merge judgment.
5. Give both parties a bounded response
The buyer should identify the exact criterion, observed value, evidence, discovery time, and requested remedy. The seller should be able to provide source context, historical state, correction, or a reason the criterion does not apply. Set response deadlines and allow the reviewer to request one focused clarification rather than opening an unlimited evidence exchange.
Do not make the parties prove facts they cannot access. If only the platform can see the accepted snapshot or audit log, the platform owns that evidence. Preserve disagreement when a conclusion remains uncertain.
6. Separate correction from remedy
Correct an inaccurate or misleading current record even when the commercial remedy is denied. Conversely, a contractual remedy may apply even when historical data accurately records what was known at the time. The ICO’s accuracy guidance emphasizes purpose, source/status clarity, challenges, and appropriate updating; its rectification guidance explains that later correction and an accurate historical record may both matter.
Possible marketplace results include approve, partially approve, deny, request more evidence, correct data, suppress a record, reverse an ownership state, or escalate a policy/system incident. Never invent a remedy not authorized by the applicable terms.
7. Write a reasoned decision
The decision should state the claim, applicable versioned rule, material facts, disputed facts, evidence accepted or rejected, limitations, result, correction, remedy, owner, and appeal or escalation path. Do not use a quality score as the reason. The score may point to evidence, but the reviewer must connect the evidence to the rule.
Feed only structured, reviewed outcomes into quality monitoring. One complaint should not automatically punish a seller or retrain an inference system. See the quality score methodology.
Copyable packet index
- Case, parties, transaction, claim, remedy request, and deadlines.
- Listing, preview, acceptance, terms, policy, and schema versions.
- Provenance, freshness, statements, inferences, and corrections.
- Access, reveal, export, sync, contact, suppression, and incident events.
- Buyer submission, seller response, platform evidence, and reviewer questions.
- Decision, rationale, correction, remedy, owner, retention, and appeal path.
Sources and next step
Primary references: the ICO’s official accuracy principle and right to rectification guidance. Contract, evidence, and privacy duties depend on the real case and jurisdiction.
After resolution, place the validated event at the correct stage of the attribution ladder without treating one case as a marketplace benchmark.