The direct answer
An ICP is not an account list. It becomes one only when every person on the team can apply the same written inclusion and exclusion rules to a real company, record the evidence, and leave an uncertain company unresolved instead of forcing a yes.
Start with one narrow commercial decision: which accounts are worth research before we spend on contacts or outreach? Translate the answer into account fields, proof sources, disqualifiers, and a review state. Then test the definition against a deliberately mixed sample of clear matches, close calls, and obvious non-matches. The result should be a reusable qualification system, not a large export.
This guide is about building the account universe. It does not decide whether a named person may be contacted, whether a channel is lawful, or whether a contact value is current.
Its scope is deliberately narrower than agent design or governance: it owns the human-reviewable implementation from an ICP brief to an accepted or rejected account. For AI-agent instructions, permissions, and review controls across a broader list-building workflow, read How to build an AI agent for B2B list building.
1. Write a decision-shaped ICP
Generic firmographics create generic lists. A useful ICP describes the observable conditions that make an account worth the next action.
For every condition, name three things: the evidence that can support it, the evidence that blocks it, and the state used when the evidence is insufficient. “Unknown” protects quality. It prevents a sparse website from becoming either an automatic rejection or an invented match.
2. Build an account field contract
Create fields for the decision, not a free-form notes column. The smallest useful contract usually looks like this:
Do not add a contact field merely because it is available. That changes the question from “is this company relevant?” to “can we find a reachable person?” and makes a weak account look attractive.
3. Test the ICP against negative controls
Most bad account lists fail through false positives. Add companies that use the same vocabulary but should fail: distributors when the ICP requires manufacturers, parent entities when the local operating site matters, agencies with the same customer segment, and inactive or out-of-country entities.
Review a small labelled sample before expanding. Track:
- acceptance rate = accepted accounts ÷ reviewed candidates;
- review rate = accounts requiring human investigation ÷ reviewed candidates;
- duplicate rate = duplicate entities ÷ returned candidates; and
- reason coverage = accounts with a recorded inclusion or exclusion reason ÷ reviewed candidates.
These are operating measures, not universal market-coverage claims. Acceptance rate describes the outcome of this reviewed sample; it is not audited precision. If you need to claim precision, compare accepted and rejected decisions with an independently adjudicated labelled sample and state that denominator and method. If you do not have a credible denominator for every eligible company, do not claim recall.
Plan the first account review
Plan a small first review before researching the full candidate list. Change the sample and expected decision mix to make the review workload visible.
Keep and investigate are capped at the full sample; the remainder is shown as exclude. Replace these assumptions with observed review decisions.
Review 30 of 120 candidate accounts: 12 keep, 6 investigate, and 12 exclude under these assumptions.
| Review decision | Accounts |
|---|---|
| Keep | 12 |
| Investigate | 6 |
| Exclude | 12 |
Use the composition to check whether the sample gives the team enough accepted, uncertain, and rejected records to review the criteria together.
The planner limits the review sample to the available candidate accounts. It applies the provisional keep rate first, then the investigate rate to the remaining capacity; every other reviewed account is excluded. It does not extrapolate the sample to the full market.
This is a workload and calibration aid. A sample is only useful when the same written criteria are applied consistently and the actual decisions are retained with their reasons.
Use the ICP translation record
Download the ICP account translation record. Capture the canonical company plus domain or register identifier, original request, entity boundary, each inclusion and exclusion rule, exact source, observation date, and the reason for every pass, review, or fail. Record insufficient evidence as unknown and route it to review rather than treating it as a fourth decision. Its sample row is deliberately incomplete: replace it with a real account, rather than copying a claimed fact. A reviewer should be able to reproduce the decision from this file without opening a separate brief.
4. Separate discovery, review, and contact research
Use four queues:
- Candidate: discovered but not yet evaluated against every required rule.
- Accepted: the account has current enough evidence for the defined commercial step.
- Review: evidence conflicts or is insufficient; retain unknown as the evidence status and name the question to resolve.
- Rejected: a documented disqualifier applies.
Make account acceptance a team gate: do not send a contact-lookup request until the account passes the written review. Keep the original title, site, source URL, observation date, and reviewer decision. A later team member must be able to distinguish “we found no relevant role” from “we never approved this account for person research.”
Where personal data is processed, this separation also supports data minimisation. GDPR Article 5 requires personal data to be adequate, relevant, and limited to what is necessary for its stated purpose, as well as accurate and kept up to date where necessary. An account-first gate cannot make outreach lawful, but it can prevent unnecessary contact-data collection while the account decision is unresolved. GDPR Article 5: principles relating to processing
5. Run a calibration, not a one-time argument
Ask two reviewers to classify the same 20–30 mixed accounts using only the written contract. Compare disagreements.
Version the ICP after calibration. Do not edit historical decisions invisibly; record which version produced each decision. Re-test after changing markets, buyer profile, offering, or exclusion logic.
6. Resolve the entity before judging the fit
Many list-building errors begin before a person reads the company description. A brand, parent group, local subsidiary, sales office, factory, and website can all share a name. If the ICP says “German operating manufacturer,” a group website is not sufficient evidence that the specific legal entity or operating site belongs in the queue.
Use an entity-resolution mini-check before making an account decision:
When evidence does not resolve the relationship, mark it review, not duplicate or accepted. Do not invent a group hierarchy from a logo footer, matching name, or a third-party directory. A reviewer can later choose to link the records, but the original observation must remain visible.
The EU business-register directory is useful for locating official register information across participating jurisdictions, while availability and fields vary locally. It can support identity research but does not prove current operating fit or buyer relevance. EU e-Justice: business-register search
7. Turn the brief into a repeatable discovery recipe
Discovery should create candidates that can fail the contract; it should not quietly decide the contract. Write one small discovery recipe for each source class. It contains the terms or filters used, date, source, intended inclusion rule, known blind spot, and what the reviewer must still prove.
For the example ICP, a recipe might use a local-language service term plus an industry source to produce candidates. Its output is not “field-service companies in Germany.” Its output is “companies worth checking against the operating-manufacturer and German-site rules.” That difference stops a search term from becoming evidence.
Save the recipe with the ICP version. If a candidate was found through an old source or old query rule, the reviewer needs to know that before interpreting its absence or its rank. This also lets the team test source mix: if a source produces mostly review cases, it may be useful for discovery but inefficient for the next pilot.
8. Use an evidence hierarchy without pretending it is a truth score
Not all evidence supports the same conclusion. Define a hierarchy for the specific field, not a generic “verified” badge:
- A dated company-controlled or official source directly supports the narrow fact.
- A credible secondary source gives a discovery lead that requires a primary check before acceptance.
- A search snippet, undated directory, or category label is a clue only.
- Missing, ambiguous, or conflicting evidence remains unknown or goes to review.
The hierarchy tells the reviewer how far they may go, not whether an account is universally true or false. A careers page can support “this role was advertised on the observed date”; it cannot by itself establish team size, budget, or a purchase project. A register can support an identity fact; it cannot establish that a local location is commercially relevant to your offer.
Add a claim boundary to difficult fields: one sentence that says what the source does not establish. That makes the quality rule teachable to new reviewers and keeps downstream sales copy from upgrading an account-level clue into a personal claim.
9. Work a mixed example before you scale
Use a fictional but realistic batch to make the contract concrete. Suppose the team is qualifying 30 companies for a service-operations product. The rule is: an operating manufacturer with a German site and public evidence of multi-location service delivery; distributors and group-only pages fail.
Now ask two reviewers to decide without discussing the accounts first. Their disagreement reveals whether the rule, evidence class, or entity boundary is underspecified. Do not solve disagreement by adding more generic firmographic filters; solve it by changing the written decision rule.
10. Define the handoff and deletion boundaries up front
The accepted list is not an endpoint. Define where it goes, who can use it, which columns must travel, and which columns must not. The immediate handoff should normally contain the canonical account, decision, inclusion reason, source URL, observation date, reviewer, ICP version, and next allowed action. Raw discovery notes, weak inferences, and unneeded personal information should not become permanent downstream fields merely because they were useful during review.
Where the next step processes personal data, name the purpose before requesting a contact field. GDPR Article 5 requires data minimisation for the stated purpose. A team gate does not itself decide lawfulness, but it can keep unresolved accounts out of unnecessary contact research. GDPR Article 5: principles relating to processing
Create an exit rule as well: reject candidates that fail, retain the decision reason for the agreed review period, and re-open them only when a versioned ICP or new primary evidence changes the relevant condition. That prevents a list from repeatedly recycling the same weak candidates.
11. Test the pilot against a known reference set
If the team already knows a few clearly fitting and clearly unsuitable companies, do not use them only as inspiration. Put them in a small reference set and assess them with exactly the same rule as new candidates. The set does not prove complete market coverage. It does show whether the new rule treats known examples reproducibly.
For every disagreement, record whether the fault is discovery, entity resolution, evidence class, or the inclusion rule itself. A known customer that fails the new rule may reveal an overly narrow definition. A known exclusion that passes often reveals a missing negative control. Repair the field contract and repeat the sample before rescuing individual rows through an exception.
12. Align review economics with the next action
Not every uncertainty merits the same amount of time. Define a time limit per candidate and an escalation rule. Missing local-site evidence can justify review for a high-cost enterprise account, while a broad top-of-funnel pilot may treat it as a rejection or no-result. The important part is that the rule is set before work begins and applies to every source.
This makes the list not only more precise but manageable: the team can see which uncertainties create real value and which research merely compensates for a weak starting rule.
13. Decide from documented errors, not list size
Close the pilot with a short decision: scale, narrow the rule, change source, or stop. Scaling is justified only when the mixed sample was classified reproducibly, the review burden suits the next action, and repeated errors have a documented repair. A large list without those conditions is not progress; it is simply a larger queue for later correction.
The ICP therefore remains a testable working instruction at every stage.
Why qualification belongs before contact lookup
A database-first workflow usually treats a returned company as a lead and pushes the difficult work downstream: export the rows, clean the list, debate the edge cases, and reveal contacts before anyone can explain why every account belongs. Leadbase reverses that sequence. A returned company stays a candidate until the written ICP rule and the retained evidence justify the next action.
Leadbase does not make the biggest export the goal. It builds the list around your own definition of the right account.
That change sounds small, but it removes the most expensive break in list building. The company, qualification fields, source evidence, review state, owner, and next action can live in one shared Sheet. The team can select only accepted rows for focused research, keep a no-result visible instead of converting it into a guess, and export the list only after the decision is made.
This is the reason to use Leadbase when the ICP is difficult: not because another database cannot return rows, but because returning rows is only the beginning of the job. Build a small candidate set in Leadbase and test whether another reviewer reaches the same decisions. If you only need a static, already-approved mailing file, the additional review workflow may be unnecessary.
Checklist before you scale
- One sentence says what an accepted account enables.
- Every inclusion rule has acceptable evidence and a failure condition.
- Negative controls were reviewed, not merely described.
- Pass, review, and fail are decision states; unknown is visible evidence status that routes an account to review.
- The team does not request contact lookup until account acceptance.
- The Sheet retains source, observation date, decision, and decision version.
- A second reviewer can reproduce a sample of outcomes.
