Build a target account list with one verified call per account
Images on this page are for illustrative purposes only. Example outputs are based on Lusha data, with personal details masked or abbreviated for privacy.
This Claude prompt builds a target account list against your ICP and returns one verified decision-maker per account. Instead of having the model search the web, read company pages, and guess email patterns for every account, it makes a single verified Lusha call per account and gets a structured record back — faster, cheaper, and with no fields to fact-check.
The prompt
<context>
I want a target account list built against my ICP, with one verified decision-maker per account. Use Lusha for every contact and company detail. Do not research accounts from the open web or guess at any field — if Lusha doesn't return it, flag it rather than filling it in.
</context>
<task>
1. Build a list of accounts matching my ICP:
- Industry: [INDUSTRY]
- Size: [EMPLOYEE RANGE]
- Region: [REGION]
- Any other filter: [E.G. HAS A REVOPS FUNCTION]
- How many accounts: [NUMBER]
2. For each account, make one Lusha call to return:
- The company match (confirm it fits the ICP filters)
- One decision-maker in [TARGET FUNCTION], with verified title, email, and phone
3. Structure the output as a table:
Company | Fit check | Contact name | Verified title | Verified email | Verified phone
4. For any account where Lusha can't return a verified contact, list it separately as "no verified contact returned" rather than substituting a guessed or web-sourced one.
5. End with a count: accounts matched, contacts verified, accounts with no verified contact.
</task>
<constraints>
- One verified Lusha call per account. Do not assemble records from open web sources.
- Do not guess emails, titles, or phone numbers. Verified data only, flag the gaps.
- A clean "no verified contact" is a valid and useful result. Do not try to fill it from another source.
</constraints>What you'll get back
Input: ICP — B2B SaaS, 1,000–5,000 employees, North America, with a product and data-engineering function. Target function: senior product and engineering leadership. Sample size: accounts including Snowflake.
Output: A structured list built from verified calls, not web research. Below is a real record from running the prompt against the live Lusha connector.
| Company | Fit check | Contact | Verified title | Reachable |
|---|---|---|---|---|
| Snowflake | ✓ B2B SaaS, ~7,000 emp, NA, AI Data Cloud | C.K. | Executive Vice President of Product | ✓ Verified email and phone |
| Snowflake | ✓ (same account, eng leader) | D.R. | VP and Head of AI Engineering and Research | ✓ Verified email and phone |
Both records came back from single verified calls. No company page was read, no title was cross-checked against a second source, no email pattern was guessed. The agent didn’t reason about whether the data was real because the data came back verified.
A model assembling these two records from the open web would have read the Snowflake site, two LinkedIn pages, and a source to confirm each email — a dozen page reads and a stack of reasoning tokens to produce what two Lusha calls returned clean.
Contact data confirmed live via the Lusha connector. Names masked to initials for privacy.
Why use Lusha in Claude
A target account list is the task where the unverified approach is expensive, because the agent repeats the same research loop for every account. Twenty-five accounts means twenty-five rounds of search, read, cross-check, guess, confirm. The token cost scales linearly with the list size, and the bulk of it isn’t spent finding data — it’s spent deciding whether the data is real.
One verified call per account collapses that loop. The agent asks Lusha for the account and the contact, and gets a structured record with a confidence it doesn’t have to relitigate. The expensive branch of the agent’s reasoning — the “let me check another source” branch — never runs, because there’s nothing to doubt.
The flagged gaps are part of the saving, not a shortfall. When Lusha returns no verified contact for an account, the prompt lists it as a clean gap instead of having the agent go off and assemble a guessed record from the web. That clean negative is cheaper than the hopeful guess in both credits and tokens, and it keeps the list honest — every contact on it is verified, and every gap is labeled.
Data drawn from 300M+ verified contacts under GDPR, CCPA, SOC 2, ISO 27701, ISO 31700, and TRUSTe.
FAQ
Why is one verified call cheaper than web research if the call costs a credit?
Because the web read costs tokens, and at any real volume the token cost of reading and cross-checking dozens of pages per account is larger than the credit cost of a verified lookup. The credit is a visible line item. The tokens are a hidden one. For an agent running at volume, the hidden one is bigger.
What if I want more than one contact per account?
Adjust the prompt to ask for the buying group — Lusha returns multiple verified contacts per account in the same structured form. The pattern holds: one set of verified calls instead of a research loop per person.
Does this work for a list of hundreds of accounts?
The pattern does, though very large lists are better run through Lusha’s prospecting search directly rather than account-by-account in a chat. For chat-based agent runs, this prompt works for the working list you’ll actually action this week, not a whole-database pull.
What does "no verified contact returned" actually mean?
It means Lusha didn’t have a verified decision-maker matching your function at that account, so the prompt flagged it instead of guessing. A labeled gap is more useful than a fabricated contact, and it costs nothing in credits.
How is this different from the ICP scoring prompt?
The ICP score a target list prompt starts from a list you already have and scores it. This prompt builds the list from scratch against your ICP criteria. Start here when you have no list. Use the scoring prompt when you have a list and want to prioritize it.
Ready to build this?
Get started with Lusha and set up this play in minutes.
