A data provider's own "verified" flag is not an independent check. When 997 addresses a provider marked verified went through a separate verifier, 57% came back safe, 41% were catch-all, and three were invalid addresses that would have bounced.

That is the pattern with lead lists. Every filter looks like it did what you asked, every row looks clean, and the problems only show up after you have paid for enrichment or sent the email. Enrich first and filter later, and you pay for people you throw away. Skip verification, and bounces go straight into your domain reputation.

This prompt builds the list in the order that throws records away while it is still free.

What it does

It works stage by stage, reporting what each stage produced and waiting for you before the next. It starts by checking you have a validated ICP, and stops to ask for one if you do not, because a full list on an unvalidated ICP is the most expensive mistake in outbound.

The stages run from free to paid: search and narrow, check what the filters actually returned, suppress and cap per company, stop for your review, enrich, score, verify independently, and load into the CRM. Before anything that spends credits, it tells you the cost and waits for a yes.

At the end you get the count at every stage, credits spent against credits remaining, the verification buckets with a recommendation for each, High, Medium, and Low counts, and where the files are saved.

What it catches

• Paying to enrich records with no email. Filtering on the "has an email" flag first cut one list from 2,259 to 2,019, and enrichment then came back 99.7% verified.

• Title filters that return the wrong people. A search for "founder" also returned Founding Engineers and Founding Designers, 9 to 14% of the list in real runs.

• Duplicate pages from the provider. 3,238 rows held only 2,933 unique people, a 9% duplicate rate, each one a paid credit if it survives.

• People you already paid for. Across three angles on one ICP, 85 people in the second list had already been enriched for the first.

• Billing per attempt, not per match. A 10-person batch with seven matches charged 10 credits.

• Running out of credits mid-campaign. 2,712 credits of a 4,000 plan sounds fine; 2,712 of 3,055 remaining leaves 343. It stops at 85% of what is left and gives you options.

• Stale timing lists. A headcount-growth list lost 106 of 1,259 people (8.4%) in 18 days, so it re-runs the search before enriching.

• CRM imports that duplicate. On one platform, bulk creation did not deduplicate despite its documentation saying it did.

How to use it

There is more than one way in, depending on how you work.

1. Paste it into any chat. Copy the prompt below into ChatGPT, Claude, or any other assistant, bring your ICP, and run each stage in your own tools.

2. Add it to a Claude Project. Upload the prompt as a file. If you connect Apollo, it runs the searches and enrichment itself and asks before spending credits. Setup: the Claude setup guide.

The prompt

Copy the whole prompt below, from the first line to the last.

You are helping me turn a validated ICP into a clean, enriched, verified lead list that is ready for a sequence. Work through the stages below one at a time: report what each produced, then wait for me. Do not run the whole pipeline in one reply.

If I have not given you a validated ICP (titles, company size, industries, locations, exclusions, and one to three scoring signals, checked against a sample of real people), stop and ask for it. A full list on an unvalidated ICP is the most expensive mistake in outbound.

If a prospecting database, verifier, or CRM is connected as a tool, run the steps yourself, but tell me the cost and get a yes before anything that spends credits or writes records. If nothing is connected, tell me exactly what to run and I will bring the results back. Never estimate a count or a spend you could read.

You advise and I decide. Flag what looks wrong, then do what I ask. The one place to be firm is sending to unverified addresses.

Cost assumptions. This method assumes people search is free, company search is cheap but paid, enrichment is paid per record, and verification is a small per-address charge on a separate service. If search is paid on my platform, narrow harder before paging.

The order is the method. Each stage costs more than the last, so throw records away while they are free. Never enrich first and filter later. Never write copy before verification: personalising an address that will never receive mail is waste.

Stage 1. Search, and narrow for free. Save results outside the chat, one file per stage: thousands of rows do not fit in a conversation, and saved stages let me check the work. Narrow for free before paying:

• Filter to addresses the provider already believes are good. In one real run this cut 3,240 people to 2,742, which meant about 500 enrichments never bought.

• Check whether search tells you a record has an email at all. On one provider, a sample of five records flagged as having no email all cost a credit to enrich: three returned nothing and two returned a guessed firstname@domain. Filtering on that flag first took a list from 2,259 to 2,019, and enrichment then came back 99.7% verified. It held on two more runs: 939 of 942, and 490 of 490.

Stage 2. Never trust that a filter returned what you asked for. A filter expresses intent, not a guaranteed result. Print the distribution of everything filtered on and read it before a credit is spent:

• Titles. A search for "founder" also returned Founding Engineer, Founding Designer, Founding GTM, Founding Recruiter, and Founding Member: 9 to 14% of the list in real runs. They are not the buyer. Write an explicit allow list plus a deny list for the near-misses. "C-suite" likewise sweeps in Chief People Officer.

• Duplicates. Pagination on one provider returned overlapping pages: 3,238 rows held only 2,933 unique people, a 9% duplicate rate. Later pulls were clean. Dedupe by person ID anyway, first, and confirm row count equals unique ID count. Dedupe after a per-company cap and the duplicates survive, one paid credit each.

• Sector. Keyword tags pull in adjacent industries. Read the industry mix before enriching: one real run showed 43% professional services, 19% software, and education and health care as drift to cut. Name-matching people to companies joined 88%; keep the unmatched rest as its own bucket.

Stage 3. Suppress and cap. Deduping the list against itself is not suppression. Subtract, before enriching:

• Everyone already enriched or contacted for another angle. In one run of three angles on one ICP, 85 people in the second list had already been paid for in the first, and 19 more sat in both new lists. When two live angles want the same person, assign them to the higher-intent one on purpose.

• People who must never get an email: customers and anyone at a customer account, open deals, anyone who unsubscribed, said not interested, or complained, partners, vendors, investors, employees, and anyone in another live sequence. EU-located people too, unless someone has decided on purpose to prospect them.

• Cap two to three people per company, unless it is deliberate account-based work.

• Test the sending platform's own enrollment guards rather than trusting them. On one platform the same-company guard let a second person from one company through. Enforce the cap in the list file. Never switch off a guard that blocks unverified addresses to make a number go up.

Stage 4. Stop and show me what I am looking at. Nothing is enriched yet, so there are no emails or phones and last names may be masked. Say that out loud: empty columns look like a broken tool. Then give me something reviewable: total people and companies, High, Medium, and Low counts, what you cut and why, and the per-company cap. State the credit cost of enriching, and wait for a yes.

Stage 5. Enrich. Confirm the whole scope once, not batch by batch.

• Billing is per record attempted, not per match. A 10-person batch with seven matches charged 10 credits. Read the actual spend off each response and report the summed real number.

• Before starting any enrichment that runs in the background, confirm you can collect the result. If the tool that fetches it is missing, I pay for data I cannot retrieve. Stop and ask me to reconnect.

• Re-enriching charges again. Three people already paid for cost three more credits. This is why suppression is not hygiene.

• Compare the cost to what is left, not the plan limit. If enriching would use more than 85% of my remaining credits, stop and give me three options: enrich the top tier and hold the rest, skip until credits reset, or proceed. 2,712 of a 4,000 plan sounds fine; 2,712 of 3,055 remaining leaves 343.

• Enrich as late as possible. People change jobs and addresses go stale. If sending is weeks away, build and grade now, enrich close to launch.

• Re-run the search before enriching a held-back timing list. A headcount-growth list lost 106 of 1,259 people (8.4%) in 18 days. Enrich only the people who still match.

• Enrich in small batches and save after each one, so an interruption costs nothing.

• Keep the full enrichment payload, every field. The credits bought it and it lives nowhere else.

• Gap-filling enrichment across other providers has variable cost. Never quote a fixed price, and confirm you can collect the result before paying.

Stage 6. Apply the scoring signals. Filter signals were applied in search. Research signals get applied now, per company, by reading the site or pulling a paid company signal only where it earns it. Tag every lead High (hits the signal), Medium (fits the ICP, not the signal), or Low (edge of the ICP).

Stage 7. Verify independently. A provider grading its own data is not an independent check. 997 addresses a provider marked verified went through a separate verifier: 564 safe (57%), 413 catch-all (41%), 16 unknown, and 3 invalid that would have bounced. Narrowing to provider-verified in search stops paying for rubbish; independent verification stops sending to it. Neither replaces the other.

• Safe: send.

• Catch-all: unconfirmable, not bad. A 30 to 40% share is normal for B2B. On a new sending stack, hold them and launch on safe only. Once domains have a track record, send them as a separate later batch so any damage is attributable.

• Unknown: re-verify in a few days.

• Invalid: drop.

• Remove role accounts (info@, sales@) even when deliverable.

Over about 100 addresses, use the verifier's bulk upload, not a loop of single checks, each a slow live probe. If you must loop, treat anything that is not an explicit success as a retry, because refusals can arrive looking like a normal response.

Stage 8. Load it into the CRM, carefully. On one platform, bulk contact creation did not deduplicate, despite its documentation saying it did: the same five contacts sent twice produced two records each. So dedupe before sending, create in checkpointed batches, and never retry a batch on a timeout. An option to attach a list during creation was silently ignored, so attach separately and confirm by count. A match overwrites: single creation replaced a real person's name with test values after a search had found nothing. Never test with a real person's address.

If my database is thin for the segment (local businesses, a niche vertical, an event's attendees), say so: directories, public registries, and exhibitor lists can beat it on fit, and go through the same stages.

What to hand me at the end: the count at each stage (raw, deduped, suppressed, capped, enriched, verified), credits actually spent against credits remaining, the verification buckets with what you recommend for each, High, Medium, and Low counts, what is held back and why, and where the final list and the full enrichment file are saved.

Method adapted from the list builder in Apollo Operator, a free, open-source headless GTM toolkit by Creatop: github.com/creatop-gtm/apollo-operator

Part of the Apollo Operator prompt pack

This is one of 19 free prompts from Apollo Operator, the open-source headless GTM toolkit Creatop builds and runs on its own campaigns. Get the full pack here: the Apollo Operator prompt pack.