A useful lead list sample exposes how the supplier makes decisions. It should help you see why companies were included, which fields are supported, how missing information is represented, and where the research remains uncertain. A handful of attractive company names is a demonstration, but it is not yet a reviewable sample.
The method below is an original operational rubric for buyers. It separates defects from missing optional data and turns disagreements into changes to the specification. The worked examples are fictional and illustrate reasoning, not measured provider performance. Use them to design a review that matches the campaign you actually intend to run.
What you’ll be able to do
- Ask how the sample was selected and which population it represents.
- Label rows accepted, rejected, or unresolved, with a rule and reason for each decision.
- Inspect company identity, eligibility, contact linkage, and evidence separately.
- Measure missingness by field and denominator; a blank optional phone is not the same as a missing required email.
- Use sample disagreements to improve the specification before extrapolating expectations.
Decide what the sample needs to reveal
A sample can serve several purposes: show the delivery format, test whether your criteria are understandable, demonstrate the available depth of research, or support a structured provider evaluation. State the purpose before requesting it. A polished format example cannot establish how frequently a target population will meet your requirements.
Write the decision you will make after the review. You might approve the field schema, revise a business-model rule, request clearer source notes, or reject the proposed account boundary. If you cannot name the decision, the team may spend its review time debating whether the companies feel interesting rather than testing anything actionable.
Keep output review separate from campaign outcomes. A sample can show whether the account matches a public eligibility rule. It cannot establish that the prospect will answer an email, accept a meeting, or buy a service. Those later outcomes depend on other decisions and on the recipient.
Ask for an explanation of any omitted fields. If personal details are redacted in a public demonstration, the sample can still show structure and evidence handling, but it cannot prove person-to-company matching for the redacted rows. Record that limitation explicitly rather than treating an untestable field as a pass.
Separate delivery from downstream outcomes Keep sample acceptance focused on what the data can actually demonstrate.
Ask how the sample was selected
Selection method changes what you can infer. A supplier may choose its clearest records to demonstrate the best possible output. A buyer may supply several difficult examples to test edge cases. A random selection from a defined candidate population serves a different purpose. None should be presented as interchangeable.
Record the selection method in a short note: who chose the rows, from which population, under which criteria, and at what stage of research. If those details are unknown, treat the sample as a demonstration of possible output. Avoid attaching a population-wide quality estimate to it.
For a practical scope review, deliberately include borderline cases alongside clear inclusions. A hybrid business, a shared corporate domain, and an account with incomplete role information may teach more about the workflow than another obvious match. This does not make the sample statistically representative; it makes it useful for testing definitions.
Do not ask for difficult cases merely to create a failure. Explain the decisions those cases are meant to test. A productive provider discussion asks whether the classification rule handles ambiguity consistently and whether the output makes that ambiguity visible to the buyer.
Build a review sheet with independent checks
Use one row per company for the acceptance review, even when the delivery contains multiple contact rows. Add columns for company identity, required eligibility rules, exclusions, contact completion, company-contact linkage, source support, and final disposition. Keep the original company ID so every finding can be returned precisely.
For each check, allow pass, fail, and cannot determine. A reviewer who cannot find the supporting source should not be forced to decide that the claim is either true or false. A separate reason field explains whether the obstacle is missing evidence, an ambiguous rule, inaccessible material, or contradictory observations.
Reserve the final disposition for the combined decision. A company may have correct identity and complete contact fields but fail a mandatory service criterion. Another may satisfy the visible criteria while remaining unresolved because the relevant page is no longer accessible. These outcomes need different follow-up actions.
The UK Government Data Quality Framework distinguishes several dimensions of data quality, including completeness and accuracy. The practical rubric here applies that separation to lead review: filled cells and correct claims should be checked independently. A record should not receive a high quality label merely because every field contains text.
References: UK Government: The Government Data Quality Framework ↗
Use an accepted, rejected, and unresolved rubric
Acceptance should mean that the available evidence meets the agreed requirements. Rejection should identify a specific failed requirement. Unresolved should mean that the reviewer cannot yet make the decision for a named reason. These states make the next action visible.
Do not use unresolved as a soft rejection for accounts that feel less attractive. If a company meets mandatory requirements but lacks optional appeal, accept it and record the lower preference separately. Likewise, do not use accepted as a reward for an impressive website when the account fails the actual campaign rule.
Apply exclusions before discussing priority. A current customer on the buyer's supplied suppression list should not become acceptable because its score is high. If identity matching against that list is uncertain, hold the record until the relationship is resolved.
The following decision table is deliberately simple enough for two reviewers to use without a meeting. Adapt the named requirements, but preserve the distinction between evidence missing and evidence showing a failure. That distinction prevents researchers from filling uncertainty with optimistic language.
| Disposition | Required condition | Recorded reason | Next action |
|---|---|---|---|
| Accepted | All mandatory checks supported; no active exclusion | List rule IDs and supporting evidence | Continue to campaign review |
| Rejected | At least one mandatory requirement demonstrably fails | Name the failed rule and observed contradiction | Remove or correct the record |
| Unresolved | A necessary decision lacks sufficient evidence | Name the missing or conflicting evidence | Request clarification or further research |
| Accepted, lower priority | Mandatory rules pass but a preference is absent | Keep preference separate from eligibility | Retain without priority bonus |
Check identity before reading the brief
Open the website attached to the record and confirm that the company described in the brief is the business operating that site. Review the displayed name, business description, and any evidence of a parent, brand, or redirect. This check should precede detailed scoring because a well-written brief about the wrong company is still unusable.
Inspect same-name businesses carefully. A familiar company name can cause a reviewer to accept a match without noticing a different location or service. Compare the input context, the proposed website, and the source used for the contact association. One correct field does not repair a wrong entity link.
For rebrands, retain both names and explain the relationship. For shared sites, document whether the record represents a group or a specific operating unit. If the provider cannot support the chosen boundary, mark it unresolved. Avoid silently replacing the buyer's entity model with the website's navigation structure.
Record identity findings using stable IDs and short evidence notes. “Wrong company” is less useful than “C-014 points to a design studio; the input describes an industrial equipment supplier.” The second statement gives the researcher a concrete correction task.
Worked example: a sample reveals an unclear segment
A fictional workflow software seller asks for recurring software businesses. Its ten-row sample includes six companies with public product and subscription pages, two agencies with hosted client portals, one software-and-consulting hybrid, and one business whose product page cannot be found.
An unstructured review might call the sample “mostly good” and move on. The rubric produces a more useful result. The six clear product businesses are accepted. The agencies are rejected under the current rule because a client portal alone does not establish a recurring software product. The hybrid is unresolved because the specification never said whether a product business with substantial services belongs. The final account is unresolved because the required public evidence is missing.
The reviewer does not count the two unresolved cases as proven failures. Instead, the team clarifies that hybrids qualify when a distinct paid product is publicly offered and relevant to the seller's service. It also asks for a source location supporting the final company's product model.
After the rule is revised, the hybrid can be reviewed consistently. The value of the sample is the clearer segment definition, not an unsupported claim that the provider has an 80% or 90% quality rate. The sample was selected to test the specification, and the conclusions should remain within that purpose.
Worked example: complete rows hide weak contact linkage
A fictional buyer reviews eight company rows with names, roles, and business emails in every required column. At first glance, field completeness is perfect. The buyer then checks the company-contact associations rather than stopping at the populated cells.
Five contacts have source evidence tying the named person to the correct organization. One belongs to a parent company whose role in the subsidiary's purchasing is unclear. One source labels the person as a former employee. The final contact name appears on a page for a different same-name business.
The reviewer accepts five contact associations, marks the parent-company case unresolved, and rejects the two contradicted associations. The company descriptions may still be accurate, so the issue log should not discard them indiscriminately. It should request corrected contact linkage for the specific IDs.
This example also shows why optional phone coverage should be reported independently. A missing phone would not repair or worsen the wrong-company association. Separate checks make the correction order clear: resolve who the person belongs to before evaluating additional contact channels. For StackShortlist completed new leads, the required contact is a named founder or administrator with business email; phones remain optional.
Measure missingness one field at a time
Create a field-level table showing the number of eligible rows, populated values, explicit unknowns, not-applicable values, and unexplained blanks. The denominator should match the field. A company-level service classification uses company records; a person-level role check uses relevant contact records.
Do not treat every empty cell as a defect. Some fields are optional, some do not apply to the business, and some cannot be established from the available sources. The delivery should make those differences understandable. A generic blank forces the buyer to guess whether the research was attempted.
Inspect suspicious completeness as well. If every company has a highly specific growth claim, budget estimate, or pain statement despite limited public evidence, ask how those fields were derived. A meaningful unknown is better than a polished guess. The sample review should reward honest boundaries, not simply the presence of prose.
Record whether the missing field blocks campaign use. No public phone may be irrelevant to an email-first workflow. No supported company identity blocks nearly everything. Prioritize corrections according to the decision they affect rather than assigning equal weight to every missing cell.
Test the depth of the research rather than its length
Read a company brief with the campaign decision in mind. Does it explain what the business sells, who it serves, and which observations support eligibility? Does it distinguish current public claims from historical examples? Does it make the unknowns visible? These questions are more useful than counting paragraphs.
For an offer-specific dossier, inspect the link between the seller's capability and the target observation. A sentence that praises innovation or growth may sound personalized while leaving the seller no closer to a relevant conversation. Ask whether the dossier identifies a plausible fit question and a reason the account might not fit.
Check two important claims back to their sources. The purpose is to understand the evidence chain, not to reread every public page in the sample. If the source supports a narrower claim than the brief states, record the overreach. “Published one logistics case study” is different from “specializes exclusively in logistics.”
Keep general and offer-specific scores separate. A shared rubric may describe a company's overall profile, while seller-specific research depends on the buyer's website and brief. Neither score proves buying intent. The sample should reveal what the score means and how unknown evidence affects it.
Compare research depth by decision value Evaluate whether the added context changes a useful account decision.
Use independent review to expose unclear instructions
If two people will use the data differently, let them review a small shared set independently before discussing it. Give each the same specification and rubric. Ask them to record the exact requirement behind each decision, so disagreement can be traced to a rule rather than personal taste.
Compare disagreements by type. One reviewer may interpret a hybrid as eligible while another excludes it. That is a taxonomy issue. Another disagreement may arise because one reviewer missed the supporting page. That is a navigation or evidence-presentation issue. Treating both as supplier error would obscure the improvement needed.
Resolve the rule, then revisit the affected records. Do not simply average the two reviewers' scores. Averaging can conceal a fundamental disagreement about whether the company belongs in the population at all. A clear eligibility decision should precede numerical prioritization.
Keep a brief disagreement log with the original labels, evidence considered, final rule, and affected IDs. This becomes useful onboarding material for the next reviewer. It also prevents the same borderline case from consuming another meeting when the larger delivery arrives.
Return findings as a correction request
Write feedback that a researcher can act on without interpreting frustration. Include the company ID, field or rule, observed problem, supporting evidence, expected treatment, and whether the issue affects acceptance. A screenshot can help with a transient display problem, but a source URL and concise explanation are usually easier to route.
Separate changes to your own specification from corrections to the supplier's work. If the original brief allowed hybrids and you later decide to exclude them, that is a scope change. If the accepted brief excluded agencies and an agency appears without product evidence, that is a potential delivery defect. Keeping the distinction honest supports a useful review conversation.
Group repeated errors by root cause. If several contacts are attached to parents rather than operating entities, ask for an association-rule review across the affected population. Correcting one visible row without checking the rule can leave the same problem elsewhere.
After revisions, compare the changed records and the version note. Do not quietly replace the old sample and lose the reason for the update. The correction history shows whether the process can resolve findings and provides a reference for the final batch acceptance.
Identify
Use the stable company or contact ID and the relevant field or requirement.
Explain
State what the evidence shows and why it differs from the accepted rule.
Request
Ask for a correction, clarification, or explicit unresolved status.
Verify
Review the revised version and check whether the same cause affects other rows.
Turn the sample into a bounded purchase decision
Close the review with a decision note rather than an overall impression. State which parts of the proposed delivery were demonstrated, which remain untested, what specification changes were accepted, and what must be checked on the full batch. This allows the purchasing owner to approve a concrete scope.
A small sample can reveal serious errors and useful process behavior, but its limitations remain. Do not present a handful of selected records as a guaranteed future acceptance rate. If the purchase requires a more formal sampling design, agree the population and method separately with someone responsible for that analysis.
For StackShortlist, the scope is what you select in the builder and pay for at checkout. Use the public samples to clarify required fields, account boundaries, and research depth before treating a catalogue category as available inventory. The sample should make uncertainty easier to discuss, not create a promise of an unlimited matching population.
Keep the accepted sample, rubric, and specification together. When the delivery arrives, the reviewer can reuse the same definitions and compare actual outputs with the demonstrated format. A useful sample has then done its job: it has made the larger order more understandable and more testable.
Convert the rubric into batch acceptance Carry the same definitions and denominators into final delivery review.
Common questions
How many sample rows should I request?
Choose the number according to the decision and available review capacity, not a universal rule. Include enough cases to exercise the important boundaries and field types. A format demonstration, an edge-case review, and a population estimate need different designs. Label the purpose before attaching meaning to any sample size.
Should every missing value count as a failure?
No. Check whether the field is required, applicable, and obtainable within the accepted scope. Missing mandatory identity or contact information can block completion; an optional phone may not. Ask for explicit missingness states so blanks do not hide whether research was attempted or whether the field simply does not apply.
What if the supplier selected its best examples?
Use those examples to assess the achievable format and evidence presentation, while recording that selection limitation. If you need to test difficult boundaries or typical coverage, request a separately defined sample. Do not infer average performance from a showcase, and do not treat a clearly labeled showcase as a failed statistical test.
Can I approve a sample with unresolved rows?
You can approve a clarified workflow or format while leaving specified rows unresolved. Whether the purchase can proceed depends on which unknowns affect the accepted scope. Record the unresolved requirement and its treatment explicitly; avoid silently including unresolved companies in a completed quantity when they lack required evidence.
What is the most useful signal of a good review process?
Look for precise explanations, visible uncertainty, and corrections that address the underlying rule. A provider should be able to explain why a record was selected and respond to a specific finding. The review process becomes useful when both sides can reproduce the acceptance decision from the same evidence.
Sources & further reading
Primary references support the technical details. Worked examples are illustrative; workflows and checklists are practical methods to adapt to your own process.
Something changed? Tell the editorial team.