Build an Acceptance Test Before Buying Leads

Define what acceptance means for this order

Acceptance means the delivered work satisfies the agreed scope sufficiently to move into the buyer's next review stage. It does not mean every prospect is interested, every contact owns the purchase, or the campaign will produce a particular number of opportunities.

Begin with the final purchase specification. Identify the company unit, quantity, mandatory requirements, exclusions, contact obligation, research depth, and evidence expectations. Each acceptance rule should point back to one of those elements. If a rule has no basis in the accepted scope, it may be a new request rather than a correction criterion.

Define the disposition of unresolved records. Some orders may allow researched companies with unknown optional fields. A new lead order with mandatory contact coverage should not count an unresolved required contact as complete. The buyer and supplier need the same interpretation before the file arrives.

The UK government's Data Quality Issues Framework describes data quality rules as a basis for identifying issues. The checklist here is an original application to lead delivery: make the expected condition explicit, then record the exact way a delivered record does or does not meet it.

References: UK Government: Data quality issues framework ↗

Freeze the review population before counting

Preserve an untouched copy of every received file. Record the version, filenames, receipt date, and the stated company count. Use a separate working copy for checks and corrections. This protects the evidence needed to explain a later discrepancy.

Identify the populations inside the delivery. There may be company rows, contact rows, company-contact associations, and input-to-output mappings. They need different denominators. A contact completeness rate calculated across company rows can become meaningless when some companies have several contacts.

Count raw rows first, then distinct identifiers. Do not silently remove duplicates before recording them, because duplicate handling is itself an acceptance check. If a legitimate repeated-row format is used, the data dictionary should explain it.

Mark which checks apply to the full batch and which use a reviewed subset. Structural checks such as missing IDs can often cover all rows. Manual evidence checks may use a defined selection. State the selection method and avoid presenting a convenience sample as a guaranteed estimate for the whole population. The acceptance report should make its coverage as clear as its findings.

The ten-rule batch acceptance checklist

Adapt the following checklist to the accepted order. The rule names are intentionally specific, and each denominator describes the population being tested. Do not combine the ten results into one score unless you can explain why the aggregation supports a real decision.

A rule can produce pass, fail, unresolved, or not applicable at the record level. Keep those states separate in the summary. If a required fact is unresolved, decide whether that blocks completion according to the accepted scope. Do not automatically treat every unknown as either a failure or a pass.

The threshold column belongs in your own acceptance document. Some structural requirements may require every relevant record to pass. Other checks may need an agreed review method and correction process. Avoid inserting a universal percentage that has no relationship to the campaign's consequences.

Use rule IDs in the exception log. A correction request referring to R5 and a company ID is more reproducible than one saying the list has weak contacts.

Review identity and count before fit

Identity errors can contaminate every later check. Confirm that the company name, website, and business description refer to the same target. Look closely at redirects, rebrands, shared domains, and same-name organizations. A detailed brief about the wrong company is not repaired by a high fit score.

Apply the accepted company boundary. If the order counts operating businesses, do not automatically count every office as a separate account. If subsidiaries are allowed as distinct targets, preserve the relationship rather than merging them solely because they share a parent.

Keep a merge or alias ledger. Record the original ID, retained ID, reason, and evidence. This allows the count to change transparently while preserving the buyer's ability to trace the original rows. Never delete a duplicate silently and then report only the cleaner final total.

After identity review, reconcile the count to the purchased quantity. Report delivered company records, distinct research targets, accepted companies, and unresolved cases separately where relevant. A single total can conceal whether the issue is duplication, missing evidence, or incomplete contact coverage.

Test positive and negative rules independently

For each mandatory eligibility condition, record the evidence and decision. A company should not pass a required product-model rule merely because it has a polished website or a relevant technology observation. Test the actual condition, not a convenient proxy that was never accepted.

Apply exclusions separately. A business can satisfy every positive criterion and still be an existing customer, an active opportunity, or an unsupported account type. Do not allow a high score to override an exclusion without a documented change to the scope.

Distinguish supplied suppression matching from researched business exclusions. The first depends on identifying the same account across files. The second depends on interpreting the company's activities. If either match is ambiguous, preserve the uncertainty and state whether the account can be released.

Review the All or Any logic exactly as accepted. Under Any matching, several alternative segments may be eligible. The output should make the qualifying alternative visible so the buyer can route accounts appropriately. Under All matching, one missing mandatory condition can block completion even if every other attribute looks attractive.

When reviewers disagree, identify the rule that caused the disagreement. Clarify the wording and revisit affected records. Do not average an eligible and ineligible judgment into a vague medium score; eligibility is a decision that needs an explicit basis.

Check contact completion and association separately

A completed contact requirement has several parts. The named person, business email, and company relationship must satisfy the accepted scope. A populated cell does not by itself establish that relationship, and a correct company profile does not repair a wrong contact association.

For StackShortlist completed new leads, the required contact is a named founder or administrator with business email. Phones are optional. In an own-list order, additional contacts are not guaranteed. These distinctions should determine which records enter the R5 denominator.

Inspect role evidence without overstating authority. A title can support the observed role but does not prove who controls the particular purchase. If your campaign requires a different operating role, that requirement should be discussed during scope review rather than added silently to acceptance.

Keep address status separate from role suitability. A technically plausible business email can still belong to an irrelevant role or the wrong organization. Likewise, a relevant role with no required address may remain incomplete for the purchased new-lead scope.

Return corrections with both company and contact IDs when available. This allows the researcher to fix the association without overwriting unrelated company findings. The exception should describe the failed relationship precisely, such as a former employee or a contact from an unrelated same-name company.

Worked example: accepting a fictional new-company batch

A fictional buyer receives one hundred company records and 128 contact rows. The accepted scope requires one hundred distinct operating businesses, each with a named founder or administrator business email, plus evidence for a particular public service condition.

The structural review finds one hundred company IDs, but two IDs refer to the same operating business under different names. One additional record represents a branch that should not count independently under the agreed boundary. The buyer therefore has ninety-eight distinct eligible counting units before reviewing other requirements.

Contact review finds that three of those companies lack the required business email and one contact belongs to an unrelated organization. These are separate completion findings. The buyer does not subtract contact rows from the company quantity or report 128 as the delivered lead count.

A defined manual review of twenty company cases identifies two unsupported service claims. Because the subset was selected to include difficult cases, the buyer reports the findings and method without claiming that exactly 10% of the entire batch is defective. It requests clarification and review of the rule that produced the unsupported claims.

The acceptance note lists each issue by ID and rule, keeps the original version, and identifies the work required before completion. It does not declare the order successful because the raw row count exceeds one hundred, nor does it reject every correct record because a subset needs correction.

Worked example: accepting an own-list enrichment

A fictional buyer supplies 150 rows from an account spreadsheet. The accepted task is company research with preserved input IDs. The file contains repeated aliases, several unresolved company names, and some contacts that the buyer already maintains internally.

The return package contains a mapping table for all 150 input IDs, a company research table for resolved targets, and explicit unresolved statuses. Two input aliases map to the same company ID. This is acceptable if the scope allowed consolidation of research targets while preserving every input relationship.

R9 checks whether each original input ID has exactly the required returned status or mapping. R1 checks the resolved identities. R3 checks the accepted research criteria. R5 does not create an unstated requirement for newly discovered contacts, because the own-list task did not guarantee them.

One returned row lacks an input ID even though its company research is otherwise useful. The buyer reports a joinability defect and requests the missing mapping. Another record remains unresolved because the supplied name matches several businesses and the available context is insufficient. That state can be an honest research result if it follows the agreed unknown treatment.

The final acceptance report separates input rows accounted for, distinct companies researched, unresolved matches, and optional contact changes. This makes the transformation understandable without pretending that every input row became a newly completed lead.

Review claim support without rereading the entire web

Prioritize claims that materially affected inclusion, score, or approach. Select the source attached to the claim and ask whether it supports the exact statement. A public service page may support an advertised capability; a historical project may support past experience. Neither automatically establishes every current customer or internal process.

Check the observation date and the source's own date where available. A researcher can observe an old page today. Those two dates describe different things. If a historical event is used to imply a current condition, the dossier should explain that interpretation rather than leaving it implicit.

Inspect negative claims carefully. “Not found in the reviewed sources” is narrower than “does not exist.” A missing public page should not become proof that a company has no capability or no internal team. Record the accepted research scope and the appropriate uncertainty.

Do not require every sentence to carry a separate citation when several sentences describe one tightly bounded observation. Instead, require the reader to be able to trace each consequential claim. A long undifferentiated source list at the end of a report is not enough if the reviewer cannot tell which source supports which conclusion.

Create an exception log that supports correction

Use a compact schema: exception ID, company ID, contact or input ID if relevant, rule ID, observed issue, supporting evidence, proposed treatment, owner, and status. Keep the language factual. “Source names the person as a former employee” is stronger than “bad contact.”

Group related exceptions by cause. Several wrong-parent associations may indicate a shared entity rule problem. Several broken dossier links may indicate a delivery-format issue. Ask for a review of the affected cause rather than assuming each visible row is isolated.

Separate correction requests from scope changes. If the buyer adds a new exclusion after delivery, record it as a revised requirement. If the supplier failed an accepted exclusion, record it as a defect. The distinction prevents the exception log from becoming a place where the purchase is quietly renegotiated.

After a revision, retain the original exception and record what changed. Verify the corrected field and any dependent conclusion. A fixed website may require a new company description and fit assessment, not merely a replaced URL. Close the exception only when the relevant acceptance rule is satisfied or an explicit unresolved treatment has been agreed.

Use the log to explain the accepted version. The final campaign file should have a clear lineage to the delivered and corrected records, so another reviewer can understand why a company was released or withheld.

Separate acceptance from release to outreach

A batch can satisfy the purchased scope and still need buyer-side preparation. The team may need to import it, apply current internal suppression, assign account ownership, review role suitability, and assess the appropriate use of the data. Acceptance should not silently trigger outreach.

Create a release state separate from acceptance. An accepted company may be withheld because an internal owner is already managing it. Another may need a current role check before a message is prepared. Those are campaign decisions, not necessarily defects in the research delivery.

Keep the count bridge visible: delivered records, accepted companies, internally suppressed accounts, unresolved campaign reviews, and released accounts. This prevents the final release quantity from being mistaken for a supplier shortfall when the buyer deliberately withheld some records.

Buying data does not itself establish permission to send messages. The campaign owner must handle the applicable rules, recipient preferences, channel choice, and message accuracy. A fit score, including the scores already present in basic Stack leads, should not be treated as permission or buying intent.

Assign someone to retain the original files, the acceptance report, and the released version. Without that ownership, representatives can accidentally use an earlier file containing records that were later corrected or withheld.

Write the final acceptance note

The final note should identify the specification version, delivered file version, company unit, review populations, checks performed, unresolved exceptions, and the decision. State which findings were corrected and which limitations remain accepted under the scope.

Use precise totals. If all structural checks covered the full batch but evidence checks covered a defined subset, say so. If optional fields remain unknown, distinguish that from missing required fields. If a small number of records remain withheld, identify them rather than burying the issue in an overall quality statement.

Avoid declaring absolute accuracy based on a review that cannot establish it. The note should explain what was tested and what the evidence supports. This is more useful than an impressive percentage without a denominator or method.

Keep the checklist reusable but revisit it when the offer, company boundary, or output changes. A test designed for a general company profile may not cover seller-specific hypotheses. An own-list mapping check may not apply to a new-company discovery task. Acceptance stays objective when it follows the actual order rather than becoming a rigid form detached from the work.