The ICP-to-lead-list workflow, step by step

An ICP-to-lead-list workflow is the loop that turns "here is who we sell to" into a short list of people you can defend contacting: describe the ideal customer as criteria, confirm the system's interpretation before anything runs, resolve the spec into a bounded set of evidence-cited briefs, reveal contacts through a metered verified path, then monitor what you keep. Below is that loop as CitedLeads implements it, and it works as a checklist even if you never open the product.

Most lead tools collapse the interesting part (deciding who belongs on the list) into a filter sidebar and a big export button. The workflow below keeps that decision explicit, because the moment you stop looking at why a lead is on the list is the moment the list stops being useful.

1. Describe the product, then the ICP

There are two honest starting points:

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

In CitedLeads there is a step before either: you describe your own product once (what it does, who it is for, what problem it solves) and that product truth is persisted and versioned. It anchors every ICP the system proposes or interprets, so a run is grounded in what you actually sell rather than a bare keyword string.

2. Confirm the interpreted spec: the gate

Before anything runs, the system shows its reading of your ICP back to you: the firmographic filters, the roles it will target, the signals it will count as evidence. You review the parsed spec side by side with what you asked for, and nothing runs until you approve it.

This is a gate, not a courtesy. Approving the wrong interpretation produces a wrong list quickly and confidently. Reject, adjust, re-confirm. A tool that silently interprets your ICP will happily return 10,000 confident-looking rows for the wrong audience; a confirmation step is the cheapest quality control in the entire pipeline.

If you are not sure your ICP is specific enough to survive this step, the companion guide on ICP filtering before discovery covers how to write criteria a run can actually use.

3. Run: matching produces briefs, not rows

A run resolves the confirmed ICP against licensed provider data and returns a bounded working set (in CitedLeads, 50-100 cited lead briefs per run). Each brief contains:

• the identity (name, role, company, firmographics),
• a deterministic fit score with the rubric visible: title fit, industry fit, size fit, pain signal, evidence completeness,
• the evidence: which ICP criteria and provider-backed signals the match rests on, including gaps and negative evidence, and
• masked contact fields, revealed only through the metered path.

Bounded output is deliberate. If a run returns thousands of rows, the tool has delegated the actual qualification work back to you; you are doing the review the score was supposed to do. Fifty to one hundred is the range where a person can read every brief before touching it, which is the point.

4. Review and reveal

Work the briefs, not a spreadsheet. Read the evidence first; reject what the evidence does not support. When a brief survives review, reveal its contact fields through the metered path:

• 1 credit = 1 verified, cited contact reveal, the only metered action.
• A miss, an invalid, or an unknown costs 0 credits; the credit stays in your balance.
• Catch-all results are flagged as lower-confidence; a reveal that returns an email is charged.
• Every reveal lands in an append-only credit ledger, so spend is auditable line by line.
• Revealing the same person twice never charges twice; deduplication is handled at the candidate level, across runs.

The ordering matters: review before reveal. Credits spent on leads nobody read are the quietest waste in the category, and the tool cannot make that decision for you.

5. Monitor what you keep

Briefs you keep can be monitored: the system re-verifies them on a cadence and records change events (a role change, a signal refresh, a contact validity change). Monitoring consumes 0 credits; the cost model should never push you toward stale data. Monitoring rows are capped per tier and per organization, and a monitored list that sits dormant pauses re-verification rather than quietly burning provider calls.

A monitored list is also the honest answer to data decay: instead of re-buying a snapshot every quarter, the working set stays current and tells you when a lead's situation changed.

6. Export with caps in writing

Exports carry a printed per-export row cap and a monthly export budget per tier (both on the pricing page). Caps exist for two reasons: they keep licensed data inside licensed use, and they keep a compromised token from becoming a bulk exfiltration path. Re-exporting a contact you already revealed is free; you paid for that information once.

Exports are deliberately minimal: the fields you need for the next step, not the entire record. CitedLeads does not send outreach; what you export feeds whatever tool you already use for that.

Where the workflow fails

Four failure modes account for most wasted runs:

• Skipping the confirmation step. The fastest way to buy a confident wrong list. If the interpreted spec does not match what you meant, stop there; everything downstream inherits the error.
• Treating the brief as a row. If the evidence section is empty and you keep the lead anyway, you are back to guessing; you just paid for the privilege.
• Revealing before reviewing. Reveals are the metered action; spend them on leads the evidence supports.
• Letting the list rot. An unmonitored list decays silently. A monitored one files change events when a lead's situation shifts, which is when a warm lead either gets better or stops being a lead.

The loop, compressed

1. Describe the product once; write the ICP in plain language or upload a domain list.
2. Approve the interpreted spec; reject anything that is not what you meant.
3. Read the briefs, evidence first.
4. Reveal only what survives review; misses cost nothing.
5. Monitor what you keep; export within printed caps.

The output of this loop is not a database dump. It is a short list you can defend line by line: to a colleague, to your legal team, and eventually to the person on the other end of the outreach. That is what outreach built on evidence actually requires.

FAQ

How long does a run take? Runs resolve asynchronously; you are notified when the brief set is ready rather than watching a spinner. The bottleneck should be your review, not the pipeline.

Can I save an ICP and re-run it? Yes. Confirmed ICP specs are saved and reusable, which is how monitoring and repeat runs stay consistent.

What if my ICP is wrong? Then the run faithfully returns the wrong list, which is why the confirmation gate exists. Adjust the criteria and re-run; searches and re-runs consume 0 credits.

Does the product send the outreach for me? No. CitedLeads produces the cited briefs and the reveals; sending belongs to whatever tool you already use.

Is this live? CitedLeads is in early access; the workflow runs end to end on synthetic demo data while provider contracts clear. Contact us to join the list; the rate card locks at your activation.