The 12 best Claude prompts for RevOps — CRM hygiene, lead scoring, ICP work, forecast accuracy. Copy, paste, run with verified data from Lusha.
RevOps is the function most B2B vendors quietly built their tools for and almost no content team writes for directly. The 12 prompts below are the ones a working RevOps leader actually runs in 2026 — system-scale workflows that handle 10,000-row CRM exports as easily as 50-row inbound lists, with verified data underneath every output.
Organized by workflow so you can find what you need fast — CRM hygiene and data quality, lead routing and ICP work, forecast accuracy and pipeline health. Copy the green/black block, paste it into Claude, replace the bracketed values with your specifics, and run.
Connect Lusha to Claude in two minutes →
CRM Hygiene & Data Quality (Prompts 1–4)
The foundational layer. Cleaning what’s in the CRM, refreshing what’s gone stale, deduping what’s been entered twice, and filling in what was never captured the first time.
Prompt 1 — Clean a CRM contact export
The foundational hygiene workflow. Paste any contact export. Get back a cleaned table with validated emails, current titles, callable phones, DNC flags, and recent role changes surfaced inline.
<context>
I have a CRM contact export that needs cleaning before it goes into a campaign, scoring model, or sales hand-off.
The contacts:
[PASTE — one row per contact, with name, email, company, optional title]
</context>
<task>
For each row, use Lusha to validate and enrich:
1. Confirm the contact is still at the listed company
2. Update the title if it has changed
3. Validate the email and return the confidence grade (A+ through D)
4. Surface direct dial with DNC flag per number
5. Flag any contact who has changed roles or companies in the last 12 months
Return a sorted table:
Name | Current title | Current company | Validated email | Confidence grade | Direct dial (DNC: y/n) | Role change flag | Notes
Sort by data freshness — most recently verified contacts first.
</task>
<constraints>
- For contacts that can't be resolved, surface "unresolvable" rather than dropping the row silently
- A no-match doesn't consume a credit — flag honestly
- For DNC numbers, surface the flag but keep the number visible (some workflows still need the data for warm transfers)
</constraints>See the full workflow with a live demo →
Prompt 2 — Re-enrich stale records with state classification
The trajectory detection workflow. Surface which contacts moved companies, which got promoted, which left the workforce — so the CRM update is intelligence, not just refresh.
<context>
I have a segment of CRM records untouched in [WINDOW — e.g., 12 months]. Re-enrich them and classify each row by what's changed.
The list:
[PASTE — contact rows with the existing data fields]
</context>
<task>
For each contact, compare the stored data against the current verified record. Classify each row into one of four states:
- STABLE — same title, same company, validated email still A+ or A. Keep in active segments.
- PROMOTED — same company, new title with later job start date. Update the title; re-evaluate segmentation and lead score.
- MOVED — different company than the stored record. Update both company and email; re-evaluate ICP fit at the new company.
- DEPARTED — no current verified employer match. Suppress from active segments; consider archiving.
Return a sorted table:
State | Name | Stored data | Current data | Action required
At the bottom, summarize counts per state so I can size the cleanup work and route follow-up actions.
</task>
<constraints>
- For PROMOTED and MOVED rows, surface both the old and new data side by side for clean diff reading
- A DEPARTED row is data, not failure — flag and suppress, don't drop silently
- Trust the individual contact record over the company-side record when they conflict
</constraints>See the full workflow with a live demo →
Prompt 3 — Dedupe a messy contact list
The hidden cost of B2B data is duplicates created by name variations, email format inconsistencies, and contact records split across multiple sources. This prompt resolves the duplicates using verified identity, not fuzzy string matching.
<context>
I have a contact list with suspected duplicates — same person entered under different name variations, email formats, or company spellings. I want to dedupe using verified identity, not fuzzy string matching.
The list:
[PASTE — contact rows]
</context>
<task>
For each contact, use Lusha to resolve the canonical record:
1. Look up each contact by available identifiers (email, LinkedIn URL, or name + company)
2. Match contacts whose verified records resolve to the same person ID, regardless of how they're spelled in the source list
3. For each group of duplicates, identify the canonical row (most complete data, most recent verification)
4. Surface the suggested merge or archive action per duplicate group
Return:
Canonical row | Duplicate rows to merge | Confidence | Suggested action
Apply confidence levels:
- HIGH — same person ID returned across rows; safe to auto-merge
- MEDIUM — strong identity overlap but partial mismatch; manual review recommended
- LOW — weak similarity, do not merge automatically
At the bottom, summarize duplicate count and the projected list size after dedupe.
</task>
<constraints>
- Use Lusha's verified identity (person ID) as the dedupe key, not name similarity
- For same-name-different-people cases (common with John Smith, Sarah Johnson), the company match disambiguates — surface both as separate canonical rows
- Don't auto-merge MEDIUM or LOW confidence groups
</constraints>See the full workflow with a live demo →
Prompt 4 — Find missing fields on a partial contact list
For lists that are 80% complete but missing emails, phones, titles, or company details. Backfill the gaps with verified data instead of leaving rows incomplete.
<context>
I have a contact list that's partially complete — some rows have names but no emails, some have emails but no titles, some have companies but no direct dials. I want to backfill the missing fields.
The list:
[PASTE — contact rows showing which fields are populated and which are blank]
</context>
<task>
For each row, identify which fields are missing. Then use Lusha to fill the gaps:
- Missing email → look up the contact by name + company, return the validated work email with confidence grade
- Missing direct dial → return mobile and direct dial numbers with DNC flags
- Missing title → return current job title and start date
- Missing company → look up by email or LinkedIn URL, return current employer
- Missing industry / headcount / location → enrich with firmographics
Return the completed table with all fields populated where possible. For fields that couldn't be resolved, mark them "unresolvable" with a one-line reason.
</task>
<constraints>
- Don't overwrite fields that are already populated unless they're flagged as stale
- For unresolvable fields, surface why (contact left the workforce, ambiguous name match, no verified record) rather than leaving blank silently
- Track credit consumption — partial enrichment shouldn't consume credits for unresolved fields
</constraints>See the full workflow with a live demo →
Lead Routing & ICP Work (Prompts 5–8)
The lead-to-rep handoff layer. Resolving unknown emails, scoring inbound against ICP, validating deliverability before send, and finding lookalikes to refine the target universe.
Prompt 5 — Match unknown emails to verified contacts
For paid lead lists, gated content downloads, and any inbound source where only the email is captured. Turn anonymous addresses into named buyers with current roles and ICP scoring data.
<context>
I have a list of email addresses with no other context. I want to identify each person, pull current firmographic data, and route based on ICP match.
The emails:
[PASTE — one email per line]
My ICP for routing:
- Target titles: [TITLES]
- Industry: [INDUSTRY]
- Headcount: [RANGE]
- Geography: [REGION]
</context>
<task>
For each email:
1. Reverse-lookup the contact in Lusha
2. Return current name, title, company, headcount, industry, geography
3. Flag if the contact's individual record shows they moved to a different company than the email domain suggests (stale email)
4. Apply ICP routing logic:
- HOT — full ICP match, route to sales tier 1
- WARM — partial match (right title, wrong size, or right industry, wrong title), route to sales tier 2 or nurture
- COOL — not ICP, route to marketing nurture
- UNRESOLVABLE — email couldn't be matched, route to manual review
Return:
Routing tier | Email | Name | Title | Company | ICP component match | Notes
</task>
<constraints>
- For free email domains (gmail, outlook, yahoo), still attempt reverse lookup — many real buyers register with personal email
- A stale email (contact moved) routes to nurture, not sales — surface the new company as enrichment for marketing's records
- Surface unresolvable emails honestly, don't guess
</constraints>See the full workflow with a live demo →
Prompt 6 — Build an enriched ICP scoring table for inbound leads
The lead-scoring foundation. Transparent component scoring with verified data underneath, so sales gets leads with both a score and the reasoning behind it.
<context>
I want to build a scored ICP table from inbound leads with transparent component scoring — not just YES/NO qualification but a defensible score sales can trust.
My ICP scoring model:
- Title fit (0-30 points): [DEFINE — e.g., 30 for VP+, 20 for Director, 10 for Manager, 0 for IC]
- Industry fit (0-25 points): [DEFINE — e.g., 25 for core ICP, 15 for adjacent, 0 for off-ICP]
- Company size fit (0-20 points): [DEFINE — e.g., 20 for sweet-spot range, 10 for adjacent, 0 for off]
- Geography fit (0-15 points): [DEFINE — e.g., 15 for core regions, 0 for off]
- Signal bonus (0-10 points): [DEFINE — e.g., 10 if buying signal fired in last 90 days]
The leads:
[PASTE — name, email, company, optional title]
</context>
<task>
For each lead, enrich the row with verified data, then apply the scoring model:
1. Pull current title, company, industry, headcount, geography
2. Check Lusha's signals layer for buying signals in the last 90 days
3. Calculate each component score with reasoning
4. Sum to a total (0-100)
5. Apply routing tier: HOT (80+), WARM (50-79), COOL (20-49), COLD (under 20)
Return a sorted table:
Tier | Total score | Name | Title | Company | Industry | Component breakdown | Reasoning
Sort by total score descending. Surface HOT leads at the top so sales can route immediately.
</task>
<constraints>
- Component scoring must be transparent — sales should see why each lead scored where it did
- Include the signal bonus reasoning when applied (which signal, when it fired)
- For leads that can't be resolved, route to manual review rather than scoring as zero
</constraints>See the full workflow with a live demo →
Prompt 7 — Validate emails before campaign launch
The pre-flight deliverability check. Catch the bounces before the campaign launches and before sender reputation takes the hit.
<context>
I'm about to launch a campaign to a list. Validate deliverability before send to protect sender reputation and minimize the bounce rate.
The list:
[PASTE — contact rows with name, email, company]
</context>
<task>
For each row, validate:
1. Is the contact still at the listed company?
2. Is the email address current in Lusha's verified records?
3. What's the confidence grade — A+, A, B, C, or D?
4. Has the contact recently changed roles or companies?
Output a triage table:
Send status | Name | Email | Confidence grade | Company match | Notes
Three send-status categories:
- SAFE TO SEND — A+ or A confidence, contact still at company, no recent role change
- HOLD — B or C confidence, or company match uncertain
- DO NOT SEND — D confidence, contact departed, or email otherwise invalid
At the bottom, summarize the volume in each tier so I can judge the campaign's deliverability before launch.
</task>
<constraints>
- Be strict on HOLD — when in doubt, hold rather than send
- Flag any contact whose individual record shows they moved — that email is likely already dead at the original domain
- Surface the bounce-rate forecast based on the tier distribution
</constraints>See the full workflow with a live demo →
Prompt 8 — Find lookalike companies to your closed-won accounts
The ICP refinement workflow. Take your best-fit customers, surface 20-50 similar companies, hand the list to sales for territory planning or outbound expansion.
<context>
I want to find companies that look like my best closed-won customers — for territory planning, outbound expansion, or ICP refinement.
My seed customers (5-15 best-fit closed-wons):
[PASTE — company domains or names]
Filters to apply:
- Geography: [REGION]
- Headcount range: [RANGE]
- Exclude existing customers and accounts already in pipeline: [LIST]
</context>
<task>
Use Lusha's lookalike engine to find similar companies. For each result:
Company | Domain | Headcount | Industry | Location | Similarity factor
Apply the filters strictly — don't return excluded companies, respect geography and headcount constraints.
At the bottom:
1. Suggest the 5-10 strongest matches for sales prioritization based on similarity
2. Identify any unexpected similar companies that fall outside the assumed ICP — these are signals worth investigating for ICP refinement
</task>
<constraints>
- The lookalike model returns broad candidates — apply filters as a sharpening pass
- Surface companies that violate ICP assumptions but score high on similarity — those are real ICP intelligence
- Don't return companies clearly off the geography or headcount filters
</constraints>See the full workflow with a live demo →
Forecast Accuracy & Pipeline Health (Prompts 9–12)
The forecast-discipline layer. Auditing coverage, validating stage advancement, surfacing signal-based intelligence, and catching decision-maker drift before the contract goes out.
Prompt 9 — Audit multi-thread coverage on an open deal
The forecast-protection prompt. Audit a deal’s buying-group coverage against the current stage and surface the gaps that predict slip.
<context>
I want to audit multi-thread coverage on an open deal and identify the next 2-3 touches needed to protect the forecast.
The deal:
- Prospect company: [COMPANY]
- Stage: [Discovery / Proposal / Negotiation / Closing]
- Product I'm selling: [PRODUCT]
- Contacts touched (name, role, days since last touch): [LIST]
</context>
<task>
Use Lusha to pull the full verified buying group. Apply the deal-stage coverage framework:
- Discovery → Proposal: must have technical evaluator + end user
- Proposal → Negotiation: must have economic buyer
- Negotiation → Closing: must have economic buyer + procurement gate
- Closing → Won: must have economic buyer signed + executive sponsor briefed
Output:
- Touched contacts (role + last-touch recency)
- Critical gaps (musts missing for current stage)
- Stale threads (touched but silent 14+ days at active stage)
- Prescribed next touches with verified contact details and a one-line angle
For each gap, specify which role family is missing and which contact at the account fills it.
</task>
<constraints>
- Coverage requirements are deal-stage dependent
- Each prescribed touch needs a specific angle, not generic outreach
- Flag any contact in the buying group who has been touched but gone silent 14+ days
</constraints>See the full workflow with a live demo →
Prompt 10 — Stage-gate readiness check before advancing a deal
The forecast-hygiene prompt. Run this the moment before a rep updates a CRM stage — confirm the coverage actually justifies the advance, or surface the gaps that should be closed first.
<context>
I'm about to advance a deal to the next stage. Run a readiness check before I do — does the buying group coverage actually justify the advance?
The deal:
- Prospect company: [COMPANY]
- Current stage: [CURRENT]
- Target stage: [TARGET]
- Product: [PRODUCT]
- Contacts touched: [LIST]
- Reason I want to advance: [ONE-LINE WHY]
</context>
<task>
Use Lusha to pull the verified buying group. Apply the stage-gate framework for the target stage.
Return one of:
- ADVANCE — coverage meets requirements; proceed with the stage update
- HOLD, close one gap — close the listed specific gap first
- HOLD, significant gap — coverage is structurally insufficient; deal may be stage-inflated
For HOLD decisions, prescribe the next 1-2 touches:
- Contact, role they fill
- One-line angle
- Timeline before the advance becomes legitimate
If the rep's "reason for advancing" doesn't match the actual coverage (e.g., end user enthusiasm but economic buyer not touched), flag the disconnect honestly.
</task>
<constraints>
- The framework is not negotiable — Proposal-stage deal without economic buyer is not ready for Negotiation
- A HOLD decision protects forecast accuracy
- Be clear which decision applies
</constraints>See the full workflow with a live demo →
Prompt 11 — Find buying signals on target accounts
The signal-based pipeline intelligence layer. Scan target accounts for real buyer-side events — funding, leadership, M&A, hiring surges — and rank for outreach priority.
<context>
I want to scan target accounts for buying signals in the last [WINDOW — e.g., 90 days] and rank them by signal intensity for outreach priority.
My target accounts:
[PASTE — domains or company names]
</context>
<task>
For each account, use Lusha's signals layer to retrieve activity in the window:
- Financial events (funding rounds, IPO, M&A, strategic investments)
- Leadership events (executive hires, promotions, departures)
- Hiring surges by department
- Product launches and partnerships
- Headcount growth and web traffic shifts
For each account:
Account | Signal types fired | Specific signals (dates, sources) | Signal intensity score | Recommended action
Apply intensity scoring:
- HOT — 3+ signal types fired, including one STRONG signal (leadership, funding, M&A)
- WARM — 1-2 signal types fired
- QUIET — no signals in window
Sort by intensity (HOT first). Surface HOT accounts for priority outreach this week.
</task>
<constraints>
- Score based on signal density (breadth of types) plus signal recency (last 30 days weights heavier)
- A QUIET account is intelligence too — surface the count so I know the scan covered the full list
- Surface source article URLs for news-based signals
</constraints>See the full workflow with a live demo →
Prompt 12 — Decision-maker validation pre-close
The final pre-signature check. Has the signer departed? Did a new C-suite role get created? Did the acquirer freeze contracts? Catch the structural change before the contract goes out.
<context>
I'm about to send a contract for signature. Validate decision makers and structural state at the prospect before send.
The deal at contract stage:
- Prospect company: [COMPANY]
- Planned signer: [NAME, TITLE]
- Contract value (annual): [DOLLAR AMOUNT]
- Contract term: [LENGTH]
- Buying group worked with: [LIST]
- Last meaningful touch with the signer: [DATE]
</context>
<task>
Validate three things:
1. SIGNER VALIDATION
- Still at the prospect?
- Current title matches contract?
- Job start date — recent enough that authority may not yet apply?
- Seniority appropriate for the contract value?
2. BUYING GROUP VALIDATION
- Each contact's current title still matches my notes?
- Anyone departed or changed roles since last touch?
3. STRUCTURAL CHANGES at the prospect (last 30-90 days)
- Executive departures in the contract approval chain
- Leadership hires creating new approval routing
- M&A (especially as acquired party — triggers contract freezes)
- Security incidents (may trigger new procurement scrutiny)
Return one of:
- SEND — validated, no structural changes; contract goes out today
- HOLD, verify one thing first — minor issue, specific verification needed
- HOLD, structural change — significant change affects contract path; surface what changed and the next move
</task>
<constraints>
- Validation is binary on each check — don't soften with "probably still there"
- If the signer has departed, surface the replacement candidate
- Hold the rep accountable to the framework — late-stage emotional commitment makes objective validation harder
</constraints>See the full workflow with a live demo →
The pattern across all 12 prompts
The 12 prompts above span three different RevOps workflows — CRM hygiene, lead routing and ICP work, forecast accuracy and pipeline health — but share one structural pattern: the verified data layer is what makes the prompt usable at scale. Generic AI prompts produce plausible content. These prompts produce verified records — with email confidence grades, current titles, DNC flags, named signal events, and stage-appropriate buying group coverage.
For RevOps specifically, the difference shows up in four measurable ways:
Verified data isn’t a nicety for RevOps. It’s the difference between systems that scale and systems that need constant rework.
- Bounce rate on campaign sends drops as continuous validation replaces quarterly cleanup projects
- Lead-to-sales conversion rises when scoring runs on verified data instead of self-reported form fills
- Forecast accuracy improves when stage advancement is gated by real coverage, not rep optimism
- Renewal slippage declines when decision-maker validation runs before contracts go out
More in this series:
The 12 best Claude prompts for sales in 2026
The 10 best Claude prompts for B2B marketing in 2026
