More Resources
Prompt

Find the new champion when yours moves on

Built by: Lusha
Time to build: 1 min
Difficulty: Easy
Tools: Claude ▪ Lusha

A Claude prompt that fires when your customer champion leaves — surfacing the verified replacement candidates at the customer account, ranked by the likelihood that each one is inheriting the scope your champion left behind. The output is a short list of named contacts with validated email and phone, cross-checked against each person’s individual record so you don’t reach out to someone who also moved on.

The 30-60 day window between “champion left” and “new person owns the renewal” is when CSM action matters most. Built for that window.

Once Lusha is connected in Claude, the connector runs in the background — no special syntax needed. Just name your departed champion and the customer, then run.

Images on this webpage are for illustrative purposes only. Any named individuals shown in live demo outputs are real, with last names abbreviated for privacy.

The prompt

Open in Claude Open in ChatGPT 
<context>
My champion at an existing customer just left the company. Find the verified replacement candidates (people in the same function and at the same or similar seniority) so I can re-engage before the renewal cycle reaches them first.

My departed champion:
- Name: [DEPARTED CHAMPION'S NAME]
- Former title at the customer: [TITLE]
- Customer account: [CUSTOMER NAME / DOMAIN]
- Function they owned: [Sales / RevOps / Engineering / etc.]
</context>

<task>
1. Use Lusha to find current contacts at the customer account who match the function and seniority of my departed champion. Pull 4-6 candidates including same-function peers and one level up (if the champion was VP, also surface the C-suite owner of the function).
2. CRITICAL: cross-validate each candidate. For each contact returned by the company search, look up their individual record to confirm:
   - Their current employer is still the customer (catches contacts who also moved)
   - Their job start date and title align with someone actively in the role
   - Their previous job is consistent with internal progression or external hire
3. For each verified candidate, return:
   - Full name and current title
   - Validated email
   - Direct dial or mobile (with DNC flag where applicable)
   - Tenure in current role (from job start date)
   - Previous job (signals trajectory)
   - Inheritance likelihood: HIGH / MEDIUM / LOW based on scope, seniority, and tenure
4. Flag any candidate whose individual record shows they ALSO moved to a different company. The company search may still list them if Lusha's data hasn't fully refreshed. Surface this honestly and exclude from the replacement candidates.
5. If no clean candidate emerges in the function, surface the one-level-up contact (the C-suite owner of the function) as the right initial point of re-engagement.
</task>

<constraints>
- Cross-validation is the critical step. A company search may return contacts whose individual records show they moved on. Do not list them as candidates without confirming current employment.
- Inheritance likelihood is a judgment based on tenure, scope, and seniority, not a Lusha-returned field. Surface the reasoning so the user can adjust.
- Do not invent contacts or fabricate inheritance signals.
- If the function returns zero genuine candidates (everyone in the function also moved or the role is empty), say so plainly and surface the executive sponsor as the re-engagement starting point.
</constraints>

What you'll get back

Input: Departed champion — Tori M., former Head of RevOps at a productivity SaaS (moved to a business planning SaaS). Function — RevOps. Customer account — [Productivity SaaS].

Output: 3 RevOps leaders returned by the initial company search. After cross-validation, 1 verified replacement candidate remains. The other 2 contacts ALSO moved to different companies — Lusha’s company-side data still lists them at [Productivity SaaS], but their individual records show current employment elsewhere. Below is the real result from running the prompt against the live Lusha connector.

Verified replacement candidate

ContactCurrent titleTenureInheritance likelihood
Dan R. Head of Sales Strategy and Operations at [productivity SaaS]Confirmed currentHIGH — same function family (sales-side ops), in-seat, scope likely overlaps with the departed Head of RevOps role

Cross-validation flags (CANDIDATES TO EXCLUDE)

ContactCompany search saysIndividual record actually saysStatus
Tori M. Global Head of Revenue Operations at [productivity SaaS]Now at a business planning SaaS (the departed champion you already know about)Already gone — your starting point
Namrata R.Head of Revenue Strategy and Operations at [productivity SaaS]Now VP of Revenue Strategy and Operations at an AI infrastructure SaaS (since Jan 2025)Also moved — exclude from candidates

Re-engagement starting point

Dan R. is the verified replacement candidate. He is in a Sales Operations / Revenue Operations function at the customer account with confirmed current employment. The original Head of RevOps role appears to have either been absorbed into his scope or the company is operating without a dedicated Head of RevOps replacement. A skip-level note: the prompt also looked for a VP Sales or CRO at the account as the executive owner of the RevOps function — Lusha’s data returned zero results for that title at the company. The customer’s GTM leadership may be structured differently (founder-led, smaller team, or with C-suite titles not yet indexed in Lusha’s catalog for this account). The re-engagement starting point is Dan directly; surface the relationship to him with the original champion’s transition as context.

Two credits consumed for the company search plus one cross-validation lookup. The other cross-validation reused contact data already verified earlier in the gallery.

Why use Lusha in Claude

A champion leaving the customer is the single highest-impact event in a CSM’s pipeline. The 30-60 day window between “your contact moved on” and “the new person owns the renewal” is when relationship work compounds the most. Three patterns repeat across every champion-replacement workflow.

The company search alone is not enough. Lusha’s company-side data can lag the contact-side data by weeks or months. A contact whose individual record shows they moved to a new employer may still appear in the previous company’s contact list until the next refresh cycle. The demo above is the textbook case — two of three RevOps contacts returned by the company search have already moved to different employers. A CSM who reaches out to them assumes they’re still the right person; they’re not. The cross-validation step is what catches this.

Inheritance likelihood is the right lens, not just seniority. The replacement for a Head of RevOps isn’t always another Head of RevOps. Sometimes the scope gets absorbed by an adjacent function leader (Head of Sales Operations, in this example). Sometimes the role gets restructured and reports into Marketing or Finance. The prompt surfaces inheritance likelihood — HIGH / MEDIUM / LOW — based on scope overlap, current tenure, and seniority. That’s a judgment call the rep can adjust, not a hard label from a Lusha field.

Empty results are data, not failure. When the cross-validation pass reveals that the function has no clean replacement candidate, the right next move is to escalate one level up — to the C-suite owner of the function — and re-engage the customer relationship from there. The prompt surfaces this case directly. A CSM walking into a renewal cycle without any visibility into who replaced their champion is the worst possible position. Knowing the role is structurally absent and starting at the executive level is materially better.

Data drawn from 300M+ verified contacts and millions of company records under GDPR, CCPA, SOC 2, ISO 27701, ISO 31700, and TRUSTe.

FAQ

  • How is this different from the multi-thread map prompt?

    The multi-thread prompt is proactive — it builds the relationship map before anything breaks, with the champion still in seat. This prompt is reactive — it fires when the champion has already left and the CSM needs to find the replacement. The multi-thread map is the insurance policy; this prompt is what you run when the insurance gets called.

  • Why does the prompt cross-validate every candidate?

    Lusha’s data refreshes in cycles. A contact’s individual record may show their current employer as Company X, while the previous employer’s contact list still lists them. Both data points are real Lusha records; the individual record is the more current truth. Cross-validation is the difference between reaching out to someone who actually owns the renewal and reaching out to someone who left six months ago. The prompt does the cross-check automatically.

  • What if my champion's replacement is brand new and not yet in Lusha's catalog?

    Brand new hires (less than 30 days in role) sometimes haven’t been indexed yet. The prompt will surface the next-best candidate (executive sponsor or adjacent function leader) and flag that the function appears to have a gap. Re-run the prompt in 30-45 days to catch the new hire when they’re indexed. In the meantime, the executive sponsor is the right starting point for re-engagement.

  • How is "inheritance likelihood" calculated?

    It’s a Claude-side judgment, not a Lusha field. The reasoning considers: scope overlap between the replacement’s title and the champion’s former title, tenure in current role (someone three years in is less likely to absorb new scope than someone six months in), and seniority match (a Director replacing a VP usually means scope expansion in progress). The prompt surfaces the reasoning so the user can override.

  • Can I run this proactively, before my champion leaves?

    For proactive mapping, use the multi-thread prompt instead. This prompt is built around an event — the champion’s departure — and shapes its output around the 30-60 day window after that event. Running it without the trigger doesn’t add information beyond what the multi-thread map gives you.

  • What if the champion moved to a competitor's customer?

    The prompt surfaces the champion’s new employer as part of the cross-validation pass. If the new employer is itself a prospect for the CSM’s company, that’s a separate opportunity. For finding the right buyer at the champion’s new employer, use the buyer-persona expansion prompt in the prospecting gallery.

Related Prompts

Ready to run this?

One data connection. Works in Claude, ChatGPT, your CRM, or any agent you build.

Start for free Read the Docs