ICP filtering before discovery: criteria that pass the gate

ICP filtering before discovery means converting "who we sell to" into a set of confirmable criteria (firmographic ranges, target roles, timing signals, and explicit exclusions) and approving the system's parsed interpretation of those criteria before any run executes. Filtering is the cheapest quality control in the pipeline: every error you catch at the spec stage is an error that never becomes a confidently wrong list.

Most wasted lead spend is not a data problem. It is a definition problem discovered downstream, after the credits moved. This guide covers how to write an ICP a run can actually use, what the confirmation gate is for, and how to iterate from a small run into a tight working set.

Why filtering happens before discovery

Discovery against licensed provider data resolves whatever spec it is given faithfully, including its mistakes. A vague ICP does not produce an empty result; it produces a large, confident, wrong one. The order of operations matters:

1. Cheap stage: the spec. Criteria cost nothing to write, review, or correct.
2. Expensive stage: the run and reveal. Candidates cost provider calls; reveals cost credits.

Every dollar of lead waste in the category traces to a spec that was never made explicit. Filtering before discovery is not caution; it is arithmetic.

The four layers of a usable ICP

A description becomes filterable when it decomposes into criteria a lead either meets or does not:

• Firmographics: segment, headcount band, geography, funding stage where relevant. "B2B SaaS, 50-200 employees, North America, Series A-C" is filterable; "mid-market tech companies" is not.
• Roles: the function and seniority you need a conversation with, written as titles the data actually contains ("Head of Platform Engineering," "VP Revenue Operations"), not "decision makers."
• Signals: provider-backed observations that suggest timing (hiring patterns in the target function, stack changes, expansion activity). Signals are what separate "fits the profile" from "fits the profile now."
• Negative criteria: the exclusions (segments you do not serve, roles that look right but buy nothing, sizes that churn). An ICP without exclusions is a filter that only passes.

Write it in plain language first (the way you would explain the buyer to a new hire), then let the tooling translate it into provider filters. Plain language survives review better than a field-by-field form you filled in on autopilot.

Two input styles, and when each is right

• Natural-language ICP. "DevOps leads at Series A-C SaaS companies in North America that are hiring platform engineers." Right when you know the buyer but not the account list; the discovery is in the matching.
• CSV of domains or accounts. Right when the companies are already decided (a founder's target list, partner referrals, event scans) and discovery means resolving those accounts into the right people and the evidence inside them.

Both paths land in the same pipeline and both hit the same gate: the parsed spec gets shown back to you before anything runs. A CSV is not a workaround for the gate; it is a different input to it.

The confirmation gate is where filtering actually happens

A parsed spec shown back to you before the run is the difference between filtering and hoping. In CitedLeads, nothing runs until you approve the system's reading: the firmographic filters it derived, the roles it will target, the signals it will count as evidence.

Use the gate deliberately:

• Read it adversarially. "Would this spec pass companies I explicitly do not want?" If yes, add the exclusion before approving.
• Check what it counts as signal. A spec that scores "visited a pricing page" differently from "hiring three platform engineers" is telling you its reasoning; make sure you agree with it.
• Reject freely. Rejection costs a revision; approval of a wrong spec costs a run.

Searches, spec revisions, and re-runs consume 0 credits (the meter only moves on verified reveals), so the gate is designed to be used repeatedly, not nervously approved once.

Iterate on bounded runs, not big ones

The instinct is to widen the ICP until the run returns thousands of rows. Resist it. That is paying to do the filtering yourself, downstream, where it costs credits instead of keystrokes.

The better loop:

1. Start tight enough that a run returns within the reviewable band (in CitedLeads, 50-100 cited briefs).
2. Read the evidence on what comes back. Reject briefs whose evidence does not hold up; note which criterion admitted them.
3. Tighten the failing criterion, or loosen one that filtered out a profile you would have wanted.
4. Re-run. Match rate (briefs kept ÷ briefs delivered) is the metric that tells you whether the iteration is working.

Two or three loops of this beats one wide run in every measurable way: better match rate, better citation coverage, and a fraction of the reveals spent on leads nobody should have seen. For the full metric set, see lead list quality metrics.

Common ICP-writing mistakes

• Describing the dream customer instead of the reachable one. "Fortune 500 CIOs" fails as a spec not because it is wrong but because the signals that distinguish a buying CIO from a browsing one are not in it.
• Role inflation. Targeting the C-level because it sounds senior, when the person who actually owns the problem is a Head of or a Director. The role criterion should describe who feels the pain, not who signs the biggest version of the contract.
• No negative criteria. "Not agencies, not students, not companies under 10 people" filters more bad matches than three extra positive criteria.
• Signals that do not expire. "Raised funding in 2021" is a historical fact wearing a signal's clothes. Prefer signals with recency (hiring now, migrating this quarter) and check whether the tool timestamps its evidence.
• Skipping the spec review because the last run was fine. Criteria drift as your positioning drifts. The gate exists for every run, not the first one.

FAQ

How specific should an ICP be before the first run? Specific enough that every clause is checkable against a record: named segments, headcount bands, real role titles, time-bound signals. If a clause cannot be checked, it is commentary, not a filter.

Should I use natural language or a CSV? Natural language when you are discovering accounts; CSV when the accounts are decided and the work is finding the people and evidence inside them. Both go through the confirmation gate.

What does the confirmation step cost? Nothing. Reviewing, revising, and re-running specs consume 0 credits. Only verified contact reveals are metered.

Can I save and reuse an ICP? Yes. Confirmed specs are saved and reusable across runs, which is also what makes monitoring and repeat runs consistent.

Is the scoring AI? No. Matching runs on a deterministic rubric (title fit, industry fit, size fit, pain signal, evidence completeness), reproducible for the same input. Your criteria decide the outcome, not a model's mood.

Is the product live? CitedLeads is in early access on synthetic demo data while provider contracts clear. Contact us to join. See the product loop and rate card in the meantime.