Buying a B2B lead list is a specification exercise before it is a purchasing exercise. A supplier can return the right number of rows and still leave you with a list that cannot support the campaign. The missing detail is often ordinary: whether branches count separately, whether a technology is required or merely preferred, or whether the contact must hold a particular operating role.
This guide develops a purchase specification you can review with a researcher before payment. It uses fictional examples to show how inclusion rules, exclusions, evidence, contact requirements, and delivery checks work together. The objective is a usable decision record: another person should be able to explain why a company belongs in the order without reconstructing the sales conversation.
What you’ll be able to do
- Describe the campaign decision before selecting filters or quantities.
- Separate mandatory requirements, preferences, and exclusions; give unknown evidence an explicit treatment.
- Count companies and contacts independently, and define the entity that represents one purchased company.
- Agree the research depth and acceptance checks before reviewing a quote.
- Treat available catalogue categories as research scope candidates, not a guarantee of matching inventory.
Start with the campaign job
Write one sentence explaining what the sales team intends to do with the list. “Offer a managed checkout performance review to subscription merchants using the supported platform” is a usable starting point. “Find high quality businesses” is not. The first sentence identifies a service, a business model, and a technical dependency; the second leaves every important choice to the researcher.
Next identify the action a representative will take on receipt. Will they check account ownership, read a company brief, write a relevant opening question, or begin a partner review? Work backward from that action. If the representative needs to understand a complicated delivery model before approaching anyone, purchasing contact fields alone transfers the research task to the representative.
Document the sales team's capacity separately from market size. A team able to review twenty accounts each week does not automatically benefit from receiving several thousand names immediately. Order size should reflect the accepted minimum, intended learning, and practical handling capacity. Describe a sequence for reviewing the batch rather than pretending that every delivered company will receive identical attention on the delivery date.
Define the company you are buying
Choose an account boundary before deciding quantity. A legal entity, a trading brand, a regional office, and a website are different possible units. A nationwide group might operate several brands from one commercial team. Conversely, two subsidiaries can share a parent while making separate purchasing decisions. Your specification needs to state which boundary serves this campaign.
Use a stable identifier in the output and preserve the original company name alongside a normalized display name. A domain is useful evidence, but it is not an infallible substitute for company identity. Ask how redirects, shared domains, storefront subdomains, and rebranded businesses will be handled. The answer should explain the decision, not merely promise deduplication.
Define the counting treatment of unresolved identity. For example, require ambiguous brands to enter a review queue rather than appearing twice as assumed independent companies. If one group has three eligible entities, make the counting rule visible in the delivery. That allows you to distinguish legitimate group coverage from accidental duplication. Do not accept an unexplained row count as proof that the requested account count has been met.
Separate company and contact quantities Establish the billable unit before evaluating the size of an order.
Sort requirements into three different rule types
A mandatory rule determines whether a company may enter the accepted list. A preference changes priority among eligible companies. An exclusion removes a company even if it satisfies the positive criteria. Keeping these categories separate prevents a desirable characteristic from becoming an accidental barrier to the entire order.
For each mandatory rule, specify the observable condition, acceptable evidence, and unknown treatment. “Has a paid recurring software product, supported by a public product or pricing page; agencies selling only project work excluded” is much easier to apply than “SaaS companies.” The rule still needs a treatment for hybrid businesses, which might belong if the product is relevant to your offer.
Avoid combining unrelated wishes inside one criterion. If a sentence mentions company size, software, geography, and buyer role, split it. You can then see which requirement narrows availability and which one produces ambiguity. Use preferences for characteristics that would make an account easier to approach but are not essential to delivering your service. This is a practical research design, not a claim that every preferred characteristic is publicly observable.
| Rule type | Illustrative instruction | Unknown treatment |
|---|---|---|
| Mandatory | Operates a paid subscription product | Hold for review if the product model is unclear |
| Preference | Publishes a relevant integration guide | Retain eligible company without a priority bonus |
| Exclusion | Existing customer or active opportunity on supplied suppression list | Resolve identity before release |
| Contact requirement | Named founder or administrator with business email | Incomplete new lead until requirement is met |
Build an annotated purchase specification
Use a short specification with fields that require decisions, not a long document filled with promotional language. Begin with the campaign owner, offer, intended account action, company boundary, requested quantity, and deadline dependency. Add positive eligibility rules and exclusions as numbered statements so both sides can refer to the same requirement during review.
Create a second block for evidence and deliverables. State the desired fields, which ones are mandatory, how missing values should be represented, and whether a general company brief or an offer-specific dossier is needed. A source URL and observation date can matter more than several additional descriptive columns if the representative must verify why an account was selected.
End with acceptance and change handling. Identify who can approve revised criteria if the requested combination is unavailable. State that changes must be explained before payment or before additional work is agreed, rather than silently substituted. Keep the final accepted version with the order. A later reviewer should be able to compare the delivery against that version, even if the campaign has since changed.
Specification header
Record owner, offer, campaign action, entity unit, company quantity, and the date the scope was accepted.
Eligibility block
Number each required condition, preference, exclusion, and evidence expectation; specify what happens when evidence is missing.
Delivery block
Name the fields, contact requirement, research depth, source information, format, and the checks that define completion.
Worked example: a merchant services campaign
Consider a fictional seller, Northline Checkout, offering a review of subscription checkout journeys on one supported commerce platform. Its first draft asks for “successful ecommerce companies with modern websites.” That description would allow a researcher to choose attractive stores without establishing any reason Northline can help.
The revised specification requires an operating merchant, a publicly described subscription offer, and evidence of the supported platform within the agreed observation scope. It excludes agencies, demo stores, marketplace listings without a distinct merchant business, current customers, and companies already assigned to an active representative. Publicly documented international shipping is a preference because it may introduce complexity, but Northline can still serve domestic merchants.
The contact requirement is a named founder or administrator with business email for a completed new lead. Northline records that it will still review role relevance before choosing an approach. A general score must not be described as purchase readiness. If subscription status is unclear, the company enters an unresolved queue rather than being promoted into the accepted count.
This revision changes the purchase decision. Northline can now review a sample and ask whether each company meets three distinct requirements. It can also identify which rule causes uncertainty. A missing subscription page is a different issue from a platform observation that cannot be tied to the merchant's current site. Both deserve visible explanations rather than a single low quality label.
Worked example: a specialist partner search
A second fictional seller, Cedar Workflow, wants implementation partners for a document processing service. It initially requests “software consultancies.” That population contains product companies, staffing agencies, design studios, and implementation firms, many of which would never perform the work Cedar wants to share.
Cedar defines an eligible company as a service business that publicly describes workflow implementation for business customers. It asks for evidence of delivery responsibility, not merely a technology logo in a footer. It excludes recruiters and companies whose only relevant page is a historical blog post. A portfolio case describing integration work becomes useful supporting evidence, while an unsupported claim of innovation carries no priority.
The order needs an offer-specific dossier because partner suitability depends on Cedar's capabilities, expected division of work, and possible conflicts. The buyer supplies its website and a concise brief describing the services it will retain, the work it wants partners to own, and the kinds of overlap that should be flagged. A partner with similar capabilities may be complementary in one service line and competitive in another.
At review, one candidate is held because its public site describes advisory work but no implementation. Another is eligible but marked for conflict review because it sells a substitute product. Neither decision requires inventing a commercial relationship. The specification turns a vague category into a documented partner research task.
Prepare the seller-specific brief Use a structured brief when selection depends on your own services and exclusions.
Set an evidence threshold that fits the decision
An evidence rule should be strict enough to support the campaign without demanding facts a public researcher cannot establish. A product page may support a statement about an advertised service. It will rarely establish the customer's internal budget, dissatisfaction, or timetable. Ask for the public observation and reserve the private question for a conversation.
Record source location, observation date, and the exact scope of the claim. A page showing a service in one regional office should not automatically qualify every company in the group. A dated case study can demonstrate past work without proving a current contract. Define these boundaries in the specification so the reviewer does not mistake a confident sentence for stronger evidence.
The W3C's Data on the Web guidance treats provenance as part of making data understandable and reusable. For a lead order, an original practical application is to keep a claim-level evidence note for any fact that materially determined inclusion. You do not need a research essay for every field. Concentrate verification effort where a wrong answer would send the account to the wrong campaign.
References: W3C: Data on the Web Best Practices ↗
Specify contact scope without confusing authority
Write the required contact coverage independently from company eligibility. A relevant company can have an unsuitable contact, and a clearly named executive can belong to an irrelevant company. Combining those two checks into a single score hides the correction needed.
For StackShortlist, completed new leads require a named founder or administrator with a business email; phones are optional. An own-list research order does not guarantee new contacts. Treat these as different delivery situations. If your workflow requires a different role, ask support before you order instead of assuming that every named contact is the economic buyer.
Separate a public title from purchasing authority. A founder at a small business may be a useful entry point, but the title does not prove ownership of your specific problem. In the delivery, retain the observed title and put role suitability in a distinct field or note. Before outreach, the campaign owner should confirm the appropriate use of the data and the chosen channel. Buying a list does not itself establish permission to send a message.
Choose depth according to the missing decision
Choose basic lead data when the campaign needs a defined company and contact list and the team can make its own account judgments. Choose general company research when the missing work is understanding what the business does and how it fits a shared rubric. Choose offer-specific research when eligibility or approach changes according to the buyer's own services.
For StackShortlist, the starting prices per one hundred companies are $19 for new Stack leads, $39 for Company intelligence, and $79 for Your-offer intelligence. For an existing list, the corresponding starting prices are $15, $35, and $69. The minimum is one hundred. An extra requirement after the first adds $0.10 per company under either All or Any matching. Check the exact scope in the builder before checkout, because payment is taken at checkout.
Price is only one part of depth. A general dossier should not quietly become a promise that the supplier understands your particular offer. Offer-specific work uses your website and a brief of up to three thousand words, supplied through supported documents or pasted text. Provide enough detail to distinguish good fit from attractive but irrelevant accounts. The useful question is what decision the added research allows your team to make.
Resolve availability before treating a count as inventory
A catalogue tells you which concepts can be discussed; it does not guarantee how many eligible companies exist for your exact combination. StackShortlist's source catalogue contains 3,586 technology items, comprising 1,000 featured items and 2,586 others, alongside 46 criteria. Those figures should not be interpreted as thousands of live detectors or as a stock count for any campaign.
Make the availability review concrete. Ask which requirements are supportable, which combinations need clarification, and which conditions may produce unresolved results. If the requested list cannot be scoped as written, revise one requirement at a time and record why. Otherwise, a broader alternative can accidentally become a different campaign.
Prepare an ordered relaxation plan before you are under time pressure. You might remove a preference, accept a documented hybrid business, or lower the requested quantity subject to the minimum. Do not relax a genuine service dependency simply to obtain more rows. If your offering only works on one platform, substituting another platform creates a delivery problem rather than solving an availability problem.
Review a sample against the specification
Give a reviewer the accepted rules without explaining why you personally like the sample accounts. Have them label each row accepted, rejected, or unresolved, with the exact rule responsible. Disagreement is valuable when it exposes an ambiguous definition before a larger purchase.
Check both rows and fields. At row level, inspect company identity, eligibility, exclusion handling, and contact linkage. At field level, inspect missing values, source support, date interpretation, and consistency of labels. A visually polished dossier can still have a wrong company association. A sparse record can still meet the exact purchase requirement if optional fields were never promised.
Write denominators beside every rate you calculate. “Eight accepted companies out of ten sampled companies” is different from “eight complete contacts out of thirteen contact rows.” Do not turn a small illustrative sample into a statistical guarantee for the full order. Use it to test definitions and expose failure modes; agree separately how the delivered batch will be checked and how corrections are handled.
Review a sample systematically Use accepted, rejected, and unresolved states to reveal the reason behind each result.
Define batch acceptance Turn the purchase specification into checks with explicit denominators.
Make the order usable after delivery
Assign an owner for the delivery before it arrives. That person should preserve the original files, reconcile counts, apply suppression checks, and arrange review of unresolved cases. Delivery by email and access to an optional free workspace are distribution methods; neither replaces a clear internal owner.
For StackShortlist, the stated delivery windows begin after the accepted, paid order has complete inputs: up to one thousand leads within twenty-four hours, 1,001–10,000 within seven days, and larger orders within fourteen days. Plan internal review after receipt rather than scheduling outreach for the instant the outer window ends. Missing inputs or an unaccepted scope should not be treated as a running production clock.
Close the purchase with a short decision record. Record the accepted specification version, final quantity, outstanding exceptions, and the person who authorized campaign use. If the team later changes its offer, do not overwrite the original acceptance rationale. Keep the old delivery understandable and create a new campaign decision. This makes your next order more precise because you can identify whether a problem came from selection, missing context, routing, or the offer itself.
Common questions
Should I begin with a large number of filters?
Begin with the conditions that determine whether you can serve the company. Add preferences only when they change useful prioritization. A long filter list can contain several weak proxies for the same idea, narrowing availability without improving relevance. Test each rule against a borderline fictional company before including it.
What should happen when a required attribute is unknown?
State the treatment in advance. A required public attribute might send the account to an unresolved queue; an optional preference can remain blank without rejecting the account. Unknown should not silently mean no, yes, or a low score. The correct treatment depends on whether the missing fact blocks the campaign decision.
Can a company score replace an acceptance check?
No. A score summarizes a rubric and may help ordering, but it does not establish that mandatory fields, exclusions, and company identity are correct. Test those requirements directly. Also distinguish general fit from offer-specific fit and avoid interpreting either as evidence that the company intends to buy.
Do I need a custom brief for a straightforward list?
You need an explicit specification for every order. A detailed seller brief becomes especially useful when fit depends on your service model, supported technologies, exclusions, or division of work with a partner. Keep the brief focused on decisions that the researcher must make rather than general marketing background.
What is the best first improvement to an existing specification?
Add examples of one clear inclusion, one clear exclusion, and one unresolved case. Explain the rule behind each. This reveals terms that different people interpret differently and provides a practical starting point for sample review. Then assign a person who can resolve future disagreements without changing the campaign silently.
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.