From ICP slide to checkable criteria and an evidenced match list

Most ideal customer profiles live on a slide: “mid-market B2B software companies, fast-growing, with a modern data stack and a dedicated revenue operations team”. That sentence is useful for aligning a sales team and close to useless as input for a data API or an agent, because nearly every word in it is a judgment rather than a check. This guide turns an ICP into criteria that can be verified, shows how to collect matching companies so that every field carries its evidence, and explains how to report the limits of the search so nobody mistakes a long list for a complete one.

Why the slide version fails as a query

Hand the slide to an agent and it will return a list. The trouble is that you cannot tell whether the list is right. “Mid-market” might mean revenue, headcount or deal size. “Fast-growing” has neither a threshold nor a time window. “Modern data stack” is a cluster of tools nobody named. Each vague attribute becomes a gap the agent fills with its own definition, differently for each company, and the result is a list whose inclusion rules exist only inside a model's reasoning.

The fix is not a cleverer agent. It is a sharper specification.

Rewrite each attribute as a criterion

Go through the profile one attribute at a time and ask three questions: what observable fact would show this, which source could show it, and what happens when that source is silent. It helps to sort the answers into three groups: hard filters that exclude a company outright, scoring signals that rank the companies that pass, and disqualifiers that override everything else.

Look at the last column. Deciding in advance what silence means is what keeps the list honest: a company whose headcount nobody could find is not a company with no employees. If the technology criterion matters to you, reading technology use from public signals explains how to grade it.

Where candidates come from, and what each source misses

Matching usually runs in two phases: generate candidates broadly, then verify each one against the criteria. Candidates can come from company data APIs, official registries, search APIs, industry directories, event attendee lists or your own CRM. Every source has a coverage shape, and that shape quietly becomes the shape of your list.

• Company databases tend to cover larger and venture-backed firms better than small private ones, and some regions better than others.
• Registries are authoritative but national, and seldom say what a company sells.
• Search results favor companies that publish a lot and rank well.
• Your CRM reflects where your team has already looked.

Using more than one source and recording which source produced each candidate lets you see these biases instead of inheriting them. When candidates come from an API, a few habits save rework: send hard filters as structured parameters rather than free text, store each raw response with the time it was fetched, deduplicate on stable identifiers such as registration number and primary domain rather than on names, and page through to the end of the results instead of treating the first page as representative. Choosing data sources for company research and the guide to data enrichment APIs compare the options.

Collect matches with evidence in every cell

Once candidates exist, verification is where an agent earns its place: visiting a company's pages, reading a job posting, checking a registry entry and filling in the criteria table. Ask for one row per company and one cell per criterion, and make each cell a small record rather than a bare value.

company     example-analytics.test
status      partial match
employees   value: about 450
            evidence: careers page, 'a team of around 450 people'
            source: example-analytics.test/careers, read on <date>
revops      value: unknown
            note: no public team page; no matching job posting found

Three statuses cover most outcomes: match (every hard filter passes with evidence), partial match (no hard filter fails, but some are unverified) and excluded (a hard filter fails or a disqualifier applies, with the evidence that shows it). Keeping partial matches visible, rather than silently dropping or promoting them, lets a sales team decide how much manual checking to spend. Missing evidence is an open question explains why an empty cell is information rather than failure.

Report what the search could not cover

A match list without a coverage note invites the wrong conclusion. The number of matches tells you how many companies were found, not how many exist. Each delivery should state which sources were searched, which segments or regions they cover poorly, how many candidates remain unverified and which criteria could not be checked at all. A short note does the job:

Candidates came from two company databases and the CRM. Both databases cover small private companies outside the EU poorly. Some candidates remain partial matches because their headcount could not be verified. The RevOps criterion could only be checked where a public team page or job posting existed.

This is the part of the work most often skipped and the part reviewers value most, because it tells them where to look next.

Running it as reviewable work

In GoCux this maps onto FindAll: you state the matching criteria and the columns you want, and you get back a table in which each row comes with its evidence. Coverage limits are part of the result rather than a detail that gets smoothed over, and a result count is never offered as proof that the list is complete. The request lives on a work order with the criteria as its acceptance criteria; how to specify a task walks through writing one. GoCux is not a company database and does not read the open web on its own: public pages reach a project through an authorized browsing or export step, carrying a reference to the page and the date it was retrieved.

What happens once the list exists matters as much. Exporting the table pauses for approval with the files in scope listed, and any outreach to the companies on it is a sending action that waits for a person. The sales research page shows how that looks for account research.

Before you hand the list to sales

• Every ICP attribute is a criterion with an observable fact, a source and a rule for silence.
• Hard filters, scoring signals and disqualifiers are kept separate.
• Each candidate records which source produced it.
• Each cell holds a value, its evidence, its source and an observation date, or an explicit unknown.
• Partial matches are visible and labeled, neither dropped nor promoted.
• The delivery carries a coverage note: sources, weak segments, unverified rows, criteria that could not be checked.
• Your CRM is checked for customers and competitors before anyone is contacted.
• Exports and outreach wait for a decision by someone accountable.