The best Claude prompts for data enrichment for SaaS companies in 2026

TLDR: SaaS GTM teams deal with two data problems — incomplete inbound (PLG signups, webinar registrations, badge scans where you only have an email) and decaying CRM records that look fine until a touch fails. These eight Claude prompts fix both: three for enriching inbound lists before anyone works them, three for cleaning CRM records before outreach, and two for giving RevOps the pipeline exposure numbers that actually move leadership. All run on Lusha’s verified data inside Claude.

SaaS companies acquire contacts differently from every other industry. A PLG motion generates hundreds of trial signups a week, most of them with a single field populated: an email address — sometimes a work email, sometimes a personal Gmail, sometimes both. A webinar campaign returns 600 registrations from a form that asked for name and company and got “John” and “Salesforce” half the time. A conference badge scan lands in a spreadsheet with first names, misspelled companies, and no titles at all.

The other side of the problem is decay. SaaS sales cycles run fast — 30 to 90 days — but CRM records don’t refresh automatically when a contact gets promoted or changes companies. The list a rep pulls for an outbound push was accurate when it was built. One in three records is wrong today.

These eight prompts are built for SaaS GTM teams dealing with both sides of that problem: enriching what comes in incomplete, and cleaning what’s gone stale before it burns a campaign or a calling block. Organized into three workflows so you can find what you need fast — inbound enrichment, CRM hygiene before outreach, and RevOps and pipeline intelligence.

All eight run on Lusha’s verified contact and company data.

Connect Lusha to Claude in two minutes →

Inbound enrichment (Prompts 1–3)

SaaS inbound is noisy, partial, and high-volume. A trial signup gives you an email. A webinar gives you a name and sometimes a company. A contact form gives you whatever the prospect felt like typing. These three prompts are built for the moment right after the lead: resolving who it is, filling what’s missing, and making sure every address is safe to send to before anything goes out.

Prompt 1 — Match unknown emails to verified contacts

For SaaS teams working PLG signups, webinar registrations, conference exports, or any inbound source where the email is the only thing you start with. This prompt resolves each address to a verified person — current name, title, company, LinkedIn URL — and assigns a resolution status: MATCHED, MATCHED-MOVED (verified person, but the email’s domain is from a previous employer), or NO MATCH. The MATCHED-MOVED case is the one SaaS teams miss most: the email is real, the person is real, but their current employer is different from the domain they signed up with. That’s a net-new opportunity at a company that wasn’t on your radar.

<context>
I have a list of email addresses. I want to know who is behind each one — name, current title, current company, LinkedIn URL — so I can qualify and route the inbound lead correctly.
</context>

<task>
1. Take this email list (one per line):
[PASTE EMAILS]

2. For each email, use Lusha's contact lookup to resolve the verified person record:
- Full name
- Current title and current employer
- Validated work email(s) (with confidence grade and update date)
- Validated phone with Do Not Call status
- LinkedIn URL
- Job start date (for promotion or new-role signals)
- Previous job (for trajectory context)

3. Output a resolution table:
Email input | Resolved name | Current title | Current company | LinkedIn | Resolution status

4. Assign a resolution status per row:
- MATCHED — Lusha returned a verified person record for this email
- MATCHED-MOVED — verified person, but the input email's domain no longer matches their current employer
- NO MATCH — Lusha cannot resolve the email (likely personal, made-up, or an unindexed alias)

5. Summarize at the top: total matched, total matched-moved, total no-match. Surface the matched-moved count separately — those rows are useful intelligence.
</task>

<constraints>
- The lookup tool resolves the person, not the email itself. If the input email's domain is from a prior employer, Lusha returns the verified person at their current company. Flag this as MATCHED-MOVED.
- The verified emails Lusha returns may not include the input email — that is expected, especially for older inbound addresses.
- A no-match returns no credit charge. Personal Gmail, Yahoo, Outlook, and made-up addresses will not resolve and will not be billed.
- Do not invent any fields. If Lusha returns no record, the row stays NO MATCH.
</constraints>

See the full workflow→

Prompt 2 — Find missing fields on a contact list

For SaaS teams working incomplete lists — event badge scans with names but no emails, form fills with emails but no titles, LinkedIn exports with no phones. This prompt fills the gaps using whatever field each row does have as the lookup key: LinkedIn URL first, then email, then name and company. Three different lookup paths, one clean table out. The disambiguation case is worth flagging specifically: when two people share the same name, the company input resolves to the right person. The prompt surfaces the resolution so the rep can confirm before working the row.

<context>
I have a partial contact list. Different rows are missing different fields — some have only name and company, some have a LinkedIn URL, some have an email but no phone. I want to fill the gaps.
</context>

<task>
1. Take this partial contact list (one row per line, any combination of fields):
[PASTE LIST — name, company, LinkedIn URL, email, phone, title]

2. For each row, use Lusha to fill the missing fields. Use whatever input the row has as the lookup key:
- LinkedIn URL → full profile
- Email → matched person record
- Name + company → resolved contact
- Name only → ask for company before searching

3. Return a unified table:
Name | Current title | Company | Email (grade) | Phone | LinkedIn | What was missing | What got filled

4. Flag any row where Lusha cannot match. No-match rows do not consume credits.

5. Summarize at the top: total rows, total filled, total partial, total no-match.
</task>

<constraints>
- Use the strongest available input as the lookup key (LinkedIn URL is strongest, then email, then name + company).
- Do not invent fields. If Lusha returns no email, the row stays partial — don't fabricate an address.
- Surface email confidence grade and Do Not Call flags inline. A partial fill without compliance signals is not a clean row.
- When a name resolves to multiple people (same name, different companies), the company input disambiguates. Show the resolution so the user can confirm.
</constraints>

See the full workflow→

Prompt 3 — Validate emails before a campaign

For SaaS marketing and SDR managers running a pre-send QA pass. Bounce rates above 2% damage sender reputation — not just for the campaign that caused them, but for every send that follows. This prompt validates deliverability per row before the sequence loads: confidence grade, domain match against current employer, and a clear send decision per row (SEND, SWITCH, HOLD, SKIP). The SWITCH case is the most important output for SaaS teams: a contact with a real, verified email whose domain is from a previous employer. That email will bounce. The prompt finds the current address and flags it as the one to send to.

<context>
I am about to send a campaign to a contact list. Before launch, I want to validate every email — confidence grade, domain match to current employer, recommended send address where a contact has more than one — so I do not burn sender reputation on bounces or send to the wrong inbox.
</context>

<task>
1. Take this campaign list (paste with name, company, and the email on file):
[PASTE LIST]

2. For each contact, use Lusha to validate:
- Current employer (does it match the email's domain?)
- All work emails on file (with confidence grades and updateDate)
- Recommended send address: pick the email whose domain matches the contact's current company
- Flag any contact whose employer changed since the email on file was captured

3. Output a pre-flight table:
Name | Current company | Email on file | Lusha-verified email | Confidence | Domain match | Bounce risk | Send decision

4. Assign one of these send decisions per row:
- SEND — email matches current employer, A or A+ confidence
- SWITCH — Lusha has a better verified email for this contact; recommend the new one
- HOLD — contact changed employer; the email on file will bounce; needs the new address
- SKIP — no current record (likely bounce, do not send)

5. Summarize at the top: total to send, total to switch, total to hold, total to skip.
</task>

<constraints>
- A no-match result returns no credit charge — flag as SKIP, don't send.
- Domain match is the key signal: if the email's domain is from a previous employer, that email will bounce.
- When a contact has multiple verified emails, recommend the one whose domain matches their current company. Surface the alternative addresses but don't recommend them.
- Email confidence below A is worth flagging in the bounce-risk column even when the domain matches.
- Do not invent or guess emails. If Lusha returns no email, the row goes to SKIP.
</constraints>

See the full workflow →

CRM hygiene before outreach (Prompts 4–6)

CRM data doesn’t go stale on a schedule a rep can see. A record updated in January looks identical to one updated last week — same fields filled in, same confidence on the surface. The decay is invisible until a call connects to a stranger or an email bounces, and by then the touch is spent. These three prompts are built for the moment before the outreach: verifying a full list before a calling block, re-enriching a dormant segment to surface trajectory changes worth acting on, and recovering the right address after a hard bounce in under 60 seconds.

Prompt 4 — Refresh stale CRM records before you reach out

For SDRs and AEs pulling a list from the CRM that hasn’t been touched in months. This prompt re-verifies every record against live data before the first touch: still at the company, title still current, phone and email still valid. Returns a per-record status — CURRENT, UPDATED, DEPARTED, UNVERIFIED — with every correction shown as old → new so the CRM update is a copy job, not a re-research job. The headline number: how many records on the list are actually workable today, before anyone dials.

<context>
I'm about to work a list of CRM contacts. Before I do, I want to re-verify each one against live data — confirm the person is still at the company, the title still matches, and the phone and email are still good. I'd rather drop a stale record than burn a touch on it.

My list (paste from CRM export):
- Each row: [NAME, TITLE, COMPANY, EMAIL ON FILE, PHONE ON FILE, DATE RECORD LAST UPDATED]
</context>

<task>
For each contact, use Lusha to verify against live data:

1. Still at the company
- Confirm the person is currently at the company on file
- If they've left, flag it and surface where they are now if Lusha returns it

2. Title still current
- Confirm the title on file matches their current title
- If it changed (promotion, lateral move), return the current title

3. Contact details still verified
- Confirm the email on file is a current verified work email; if stale, return the verified one
- Confirm the phone on file is a current direct line; if stale, return the verified one

4. Return a per-record status:
- CURRENT — person, title, email, and phone all confirmed. Work this record as-is.
- UPDATED — record corrected. Show exactly what changed (old → new) so I can update the CRM.
- DEPARTED — person has left. Drop from this list; surface the replacement contact if available.
- UNVERIFIED — could not confirm. Flag it; don't guess.

5. End with a one-line summary: how many records are current, updated, departed, and unverified, so I know the real size of the list I'm working.
</task>

<constraints>
- Each check is binary — the person is at the company or they aren't, the title matches or it doesn't. Don't soften with "likely still there."
- Show every correction as old → new so the CRM update is a copy job, not a re-research job.
- Do not invent contacts, titles, emails, or phone numbers. Surface only what Lusha returns.
- A CURRENT record is safe to work today. An UNVERIFIED record is not — keep them separate.
</constraints>

See the full workflow →

Prompt 5 — Re-enrich stale CRM records

For RevOps and managers re-activating a dormant segment or running a quarterly data refresh. The difference from a straight verification pass: this prompt surfaces what changed and why it matters for re-engagement timing. A contact who moved from one SaaS company to another in the last 90 days isn’t just a stale record — they’re a net-new opportunity at a company that may not be in the pipeline. A contact who got promoted in the last 60 days is in a mandate window. The prompt classifies every row (SAME, PROMOTED, MOVED, DEPARTED) and returns the job start date so the timing of the re-engagement is based on data, not a rep’s guess.

<context>
I have CRM records that haven't been touched in 12+ months. I want to re-enrich them and surface what changed — not just refresh the fields, but flag contacts whose buying context has shifted.
</context>

<task>
1. Take this stale CRM list (paste with name, company, and last-update date):
[PASTE LIST]

2. For each contact, use Lusha to compare:
- The company on file vs Lusha's current employer
- The title on file (if any) vs Lusha's current title
- The job start date (when did they start the role they're in now?)
- Previous job (where did they come from?)

3. Output a re-enrichment table:
Name | Was (company / title) | Now (company / title) | Job start date | Change type | Action

4. Assign one of these change types per row:
- SAME — same company, same role, refresh the updateDate
- PROMOTED — same company, new title or expanded scope (re-engage with first-90-days framing)
- MOVED — new company since the CRM record was created (update the row, re-engage at the new employer)
- DEPARTED — no current record (likely retired or off-grid, archive)

5. Summarize at the top: total same, total promoted, total moved, total departed.
</task>

<constraints>
- A DEPARTED result returns no credit charge.
- PROMOTED and MOVED are both signal events — surface the job start date so the rep can time the re-engagement.
- Do not invent fields. If Lusha returns no match, the row goes to DEPARTED.
- Show the contact's previous job inline when available — it confirms the trajectory and helps the rep frame the re-engagement.
</constraints>

See the full workflow →

Prompt 6 — Find the right email address after a bounce

For SDRs when a sequence hits a hard bounce. This prompt recovers the correct address in under 60 seconds: confirms the contact is still at the company, flags the current verified title if it changed, and returns the verified work email. If the contact has left, it finds the replacement. The prompt doesn’t guess email formats — it confirms or returns a clean reason why it can’t. The title-change note matters specifically for SaaS outreach: a VP who is now SVP is a different conversation, and the re-send should acknowledge the change rather than pretend the CRM is still current.

<context>
An email I sent just bounced. I need to find the correct current email address for this contact and confirm they're still at the company before resending.

My bounced email:
- Contact name: [NAME]
- Company: [COMPANY NAME OR DOMAIN]
- Title I have on file: [TITLE — may be outdated]
- Last time I successfully reached them: [DATE OR "NEVER — first touch"]
</context>

<task>
1. Use Lusha to search for this contact by name and company:
- Confirm they're still at the company
- Return their current verified title — flag if it changed from what I have on file
- Return their verified work email
- Return their direct phone as a fallback if email isn't available

2. If the contact is no longer at the company:
- Flag the departure
- Find the most likely replacement in the same function via Lusha
- Return the replacement's verified email and title

3. Return:
- FOUND: verified email, current title, and whether title changed
- DEPARTED: confirmation they've left, replacement contact details if found
- NOT FOUND: Lusha can't confirm — flag for manual check
</task>

<constraints>
- Only return what Lusha verifies. Don't guess email formats.
- If the title changed significantly, flag it — it changes how the re-send should be framed.
- DEPARTED and NOT FOUND are valid outputs. Don't return an unverified address.
</constraints>

See the full workflow →

RevOps & pipeline intelligence (Prompts 7–8)

“We have a data quality problem” doesn’t move budget or change rep behavior. “$350K of active pipeline doesn’t meet our defined verification standard — including one deal at Negotiation with no verified contact” does. These two prompts are built for the RevOps leader or VP of Sales who needs a number, a percentage, and a recommendation they can take into a board meeting, a headcount conversation, or a pipeline review.

Prompt 7 — Build an enriched ICP scoring table

For RevOps and ABM leads scoring a new account list before handing it to the team. Takes any list of company domains and returns verified firmographics per account — headcount, revenue range, funding history, industry, office footprint — then scores each against ICP criteria and returns a ranked tier table: Tier A (strong fit plus active signal in the last 12 months), Tier B (strong fit, no current signal), Tier C (weak fit). The DISQUALIFIED output is as useful as Tier A — it’s what stops four accounts consuming rep time that should go to the two with active funding rounds. For SaaS account lists specifically, the funding history and stage indicator (public vs. growth vs. early-stage) tell the rep which sales motion to run before the first call.

<context>
I have an account list. I want each account enriched with verified firmographics and signals, then scored against my ICP and tiered A/B/C for prioritization.

My ICP:
- Headcount: [RANGE, e.g. 500-5,000]
- Revenue: [RANGE, e.g. $50M-1B]
- Industry: [TARGET, e.g. B2B SaaS]
- Geography: [REGION, e.g. United States]
- Signal preference: [e.g. recent funding round, hiring surge, leadership change]

Scoring weight (rebalance as needed):
- Size fit: [weight]
- Industry match: [weight]
- Geography match: [weight]
- Active signal: [weight]
- Stage indicator (public / growth / early): [weight]
</context>

<task>
1. Take this account list (one row per line, with company name or domain):
[PASTE LIST]

2. For each account, use Lusha to enrich:
- Company name, HQ, headcount band, revenue range, industry
- Funding history (total raised, last round, last round date, IPO status)
- LinkedIn follower count (as a soft market-presence indicator)
- Office footprint (HQ + count of regional offices)

3. Apply the ICP framework to each account:
- Size fit: does the headcount and revenue land inside the target range?
- Industry match: does Lusha's sub-industry match the ICP industry?
- Geography match: does the HQ or office footprint match the target region?
- Active signal: is there a funding round in the last 12 months, or a public-company event?
- Stage indicator: public (mature stack, replacement sale), growth (rebuilding stack, expansion sale), early-stage (foundational stack, greenfield sale)

4. Assign a tier per account:
- Tier A — Strong fit on 4+ ICP dimensions plus active signal in last 12 months
- Tier B — Strong fit on 3 ICP dimensions, or 4 dimensions without an active signal
- Tier C — Strong fit on 2 or fewer ICP dimensions

5. Output a scoring table:
Company | Tier | Size fit | Industry | Geography | Active signal | Stage | Notes

6. Summarize at the top: total accounts, count per tier, recommended first-touch count for Tier A.
</task>

<constraints>
- Use Lusha's canonical company name and verified data. Do not invent fields.
- Surface the scoring reasoning per row so the user can adjust weights and re-tier.
- An account that fails industry or geography match cannot be Tier A regardless of size.
- An account without any verifiable signal can still be Tier B if size and industry are strong fits.
- Flag any account Lusha cannot resolve as no-match — do not auto-tier missing data.
</constraints>

See the full workflow →

Prompt 8 — Build a data quality SLA report for the sales org

For the RevOps lead or VP of Sales who needs to make the data quality case to leadership — or prove they don’t need to. This prompt audits the full active pipeline: verifies every deal contact via Lusha, calculates ACV exposure by verification status (VERIFIED, DEGRADED, FAILED, CRITICAL FAIL), and returns an executive summary paragraph with a dollar figure, a compliance rate, and one specific recommendation. The CRITICAL FAIL category is the number that gets executive attention: a Negotiation-stage deal with a departed contact is not a data problem — it’s a revenue risk that cannot advance to close without first re-establishing the relationship. The SLA framing is the one that moves the room.

<context>
I want a data quality SLA report for our sales org — a clear picture of how accurate our CRM contact data is right now, what the exposure is in terms of pipeline and revenue, and what it would take to get to a defined standard.

My pipeline:
- Active deals: [PASTE DEAL NAME, COMPANY, PRIMARY CONTACT NAME AND TITLE, STAGE, ACV — one per line]
- Total pipeline value: [DOLLAR AMOUNT OR "CALCULATE FROM ABOVE"]
- Our data quality standard: [e.g. "Every deal contact verified and reachable within the last 90 days"]
- Last time a data audit was run: [DATE OR "NEVER"]
</context>

<task>
1. For each deal's primary contact, use Lusha to verify:
- Still at the company in the same role?
- Verified email available?
- Direct phone available?

2. Score each deal contact:
- VERIFIED: confirmed at company, email and phone available — meets SLA
- DEGRADED: still there but title changed, or only email (no phone) — partial SLA
- FAILED: departed, unverified, or unreachable — below SLA threshold
- CRITICAL FAIL: departed contact on a deal at Proposal stage or beyond — immediate action required

3. Calculate pipeline exposure:
- Total ACV with VERIFIED contacts
- Total ACV with DEGRADED contacts
- Total ACV with FAILED contacts
- Total ACV with CRITICAL FAIL contacts

4. Return the data quality SLA report:
- Overall SLA compliance rate: % of deals meeting the defined standard
- Pipeline exposure table: ACV by verification status
- CRITICAL FAIL deals sorted by ACV — immediate action list
- By-stage breakdown: where is data quality worst?
- Estimated time and credit cost to bring all FAILED contacts to VERIFIED

5. Executive summary paragraph: current data quality state, ACV at risk, what it takes to fix it, and what the risk is of not fixing it.
</task>

<constraints>
- ACV at risk is the number that gets executive attention — lead the report with it.
- CRITICAL FAIL on a late-stage deal is not a data problem, it's a revenue risk — frame it that way.
- The executive summary must include a dollar figure, a % compliance rate, and one specific recommendation.
</constraints>

See the full workflow →

The pattern across all prompts

The eight prompts above cover three different SaaS data enrichment problems — inbound qualification, CRM hygiene, and pipeline intelligence — but share one structural pattern: the verified data layer is what makes each output usable at scale, not just plausible.

Generic AI prompts produce plausible content. These prompts produce verified records — email confidence grades, current titles, job start dates, callable phones with DNC flags, and ACV exposure by verification status. For SaaS GTM teams specifically, the difference shows up in four measurable places:

1. Inbound lists become qualified leads. A 400-row webinar export is not a lead list until each email resolves to a verified person with a current title and an ICP signal. Running that pass before anyone touches the list (Prompts 1 and 2) is the difference between a day of qualified outreach and a day of bounced emails and wrong titles.
2. Campaign sends stop degrading sender reputation. Bounce rates compound. A list that looks clean from a CRM pull contains SWITCH cases — real people at new employers, where the email on file is already dead. The pre-send validation pass (Prompt 3) catches them before the sequence loads.
3. Re-engagement timing improves. A contact who got promoted two months ago is in a mandate window. A contact who moved to a new company last quarter is a net-new opportunity. The re-enrichment prompt (Prompt 5) surfaces both signals with the job start date attached, so the rep re-engages at the right moment.
4. Data quality becomes a revenue argument. A compliance rate and a dollar figure moves budget and rep behavior. “We need to clean the CRM” doesn’t. The SLA report prompt (Prompt 8) produces the executive summary a RevOps lead can take directly into a board prep or a pipeline review.

Where these prompts live

Each prompt above has a full play page with a live demo output — worth reviewing before running one for the first time.

• Match unknown emails to verified contacts →
• Find missing fields on a contact list →
• Validate emails before a campaign →
• Refresh stale CRM records before you reach out →
• Re-enrich stale CRM records →
• Find the right email address after a bounce →
• Build an enriched ICP scoring table →
• Build a data quality SLA report for the sales org →

All eight are part of the Lusha Pipeline Acceleration Gallery — a library of Claude prompts built for every role in a revenue team.