The best Claude prompts for AEs and closers

The work that happens between “verbal yes” and “signed contract” isn’t in a CRM. It’s in the gap — the two weeks where the deal sits in legal review, where a contact goes quiet, where someone new shows up on the signing call you didn’t expect. By the time you find out about the CFO who left or the acquisition that just closed, the deal is already at risk.

These four Claude prompts are built for that gap. They run on Lusha’s verified contact and company data — so every output is based on what’s actually true at the account right now, not what your CRM last logged. Each one takes under two minutes to run and returns something specific you can act on before the next call.

You need the Lusha connector in Claude for all four. Some also use Google Calendar and Gmail — connect them once and they run in the background.

PROMPT 1 — Validate every attendee before the signing call

The signing call is the last moment to catch a problem before ink. A signer who left three weeks ago, a procurement review triggered by a security incident, an approval path that changed when Finance restructured — none of it shows up on the calendar invite. This prompt reads the invite, validates everyone on it, and returns a clear decision: GO IN CLEAN, GO IN BUT RAISE ONE THING, or HOLD THE SIGNATURE.

Tools: Lusha + Google Calendar

→ Full play page and example output

<context>
I have a contract-review or signing call coming up. Before I join, I want to validate everyone on it and make sure nothing has changed at the account that would re-route the contract. Use my Google Calendar to find the call and the people on it, and use Lusha to validate them.

My deal:
- The expansion or contract I'm closing: [WHAT'S BEING SIGNED]
- Contract value (annual): [DOLLAR AMOUNT]
- Contract term: [LENGTH]
- Who I think the signer is: [NAME, TITLE — or "find it from the invite"]
</context>

<task>
1. Find my next contract-review or signing call on Google Calendar. Pull the external attendees from the invite.

2. Identify the likely signer from the attendees. Use Lusha to validate them:
   - Confirm their current title and that they're still at the company
   - Check their seniority against the contract value (a $250K annual contract typically needs VP or higher, $1M+ typically needs C-suite)
   - Confirm they're reachable (verified email or phone) in case a pre-call touch is needed

3. Validate the rest of the attendees with Lusha:
   - Confirm each one's current title and role
   - Flag anyone whose role has changed since the deal started, or who sits in the approval chain but wasn't expected on the call

4. Use Lusha's signals layer to scan the account for structural changes that would re-route the contract:
   - Executive departures or hires in the approval chain (CRO, CFO, CSTO, CTO)
   - M&A as the acquired party (often freezes contracts)
   - Security incidents (may trigger tighter procurement review)
   - Major reorganizations (changed reporting lines mean changed approval routing)

5. Return a clear pre-call decision:
   - GO IN CLEAN — everyone validated, no structural changes.
   - GO IN, BUT RAISE ONE THING — minor issue worth confirming on the call itself.
   - HOLD THE SIGNATURE — structural change that should be resolved before ink.
</task>

<constraints>
- Validation is binary — the person is at the company or they aren't, the title matches or it doesn't.
- Do not invent contacts, roles, or signals. Surface only what Lusha returns.
- Keep it to one screen.
</constraints>

PROMPT 2 — Map the buying group and audit your deal coverage

AEs touch the people they know and call it multi-threaded. The buying group is bigger than that. This prompt maps every role in the buying function at your prospect — economic buyer, technical evaluator, end user, influencer, executive sponsor — and tells you exactly which ones you’re missing at your current deal stage. A missing economic buyer at Discovery is fine. The same gap at Proposal is a problem. The prompt knows the difference.

Tools: Lusha + Gmail

Full play page and example output → 

<context>
I have an open deal. I want to audit my multi-thread coverage against the full verified buying group at the prospect — surface the gaps that matter at my current deal stage, and identify the next two or three touches I should make.

My open deal:
- Prospect company: [COMPANY NAME]
- Deal stage: [Discovery / Proposal / Negotiation / Closing]
- What I'm selling: [PRODUCT / SOLUTION]
- Contacts I've already touched (name and role): [LIST]
- Days since last touch with each: [LIST OR "CHECK GMAIL"]
</context>

<task>
1. Use Lusha to pull the verified buying group at the prospect company, organised by role family:
   - Economic buyer (CFO, VP Finance, or C-suite owner of the function being sold to)
   - Technical evaluator (CTO, VP Engineering, Solutions Engineering leadership)
   - End user (the function leader who will own day-to-day use)
   - Influencer (RevOps, procurement, IT)
   - Executive sponsor (the C-suite owner of the broader business unit)

2. Compare the buying group against the contacts already touched.

3. Apply the deal-stage gap framework:
   - Discovery — must have: technical evaluator touched. Should have: end user + at least one influencer.
   - Proposal — must have: economic buyer + technical evaluator + end user. Should have: influencer.
   - Negotiation — must have: economic buyer + procurement or finance gate. Should have: executive sponsor.
   - Closing — must have: economic buyer signed off + executive sponsor briefed.

4. Output a coverage audit:
   - Touched contacts and their role in the buying group
   - Critical gaps (musts missing for current stage)
   - Important gaps (shoulds missing for current stage)

5. Prescribe the next 2-3 touches in priority order, with verified contact details from Lusha and a one-line angle per touch.

6. Flag any contact who has gone quiet for more than 14 days at the current deal stage.
</task>

<constraints>
- Coverage requirements are deal-stage dependent. A discovery-stage deal without the economic buyer touched is normal. A proposal-stage deal without the economic buyer touched is a critical gap.
- Each prescribed next touch must include a specific angle — not generic "reach out to the CFO."
- Do not invent contacts or roles. Surface only what Lusha returns.
</constraints>

PROMPT 3 — Find out why your deal went quiet

A deal goes quiet for one of four reasons: the contact left, something structural changed at the account, the prospect deprioritized it, or you dropped the thread. Each one has a different fix. This prompt diagnoses which one it is — using Lusha to check what changed at the account and Gmail to check what was last said — and prescribes one specific next action. If re-engagement makes sense, it drafts the email from the actual thread, not a template.

Tools: Lusha + Gmail

Full play page and example output→

<context>
A deal I was progressing has gone quiet. I need to find out what changed — at the account or in the buying group — and decide whether to re-engage, escalate, or walk away.

My deal:
- Prospect company: [COMPANY NAME]
- Deal stage when it went quiet: [Discovery / Proposal / Negotiation]
- Last meaningful interaction: [DATE OR "CHECK GMAIL"]
- Who I was talking to: [NAME, TITLE]
- What we were selling: [PRODUCT / SOLUTION]
- Deal value: [DOLLAR AMOUNT]
</context>

<task>
1. Use Lusha to check what changed at the account since my last touch:
   - Has the contact changed roles, left, or gone elsewhere?
   - Any executive changes in the buying function?
   - Any M&A activity?
   - Any significant headcount changes?
   - Any funding event?

2. Pull my last email thread with this contact from Gmail:
   - What was the last thing discussed?
   - Who sent the last email?
   - Is there an unanswered email on either side?
   - Any signal of hesitation or delay in the last exchange?

3. Diagnose why the deal went quiet:
   - CONTACT GONE — the person left or changed roles
   - INTERNAL BLOCKER — M&A, reorg, or budget freeze stalled the deal
   - ENGAGEMENT DROP — thread went cold, likely a priority or interest shift
   - MY DROP — the last unanswered email was mine

4. Prescribe one clear next action based on the diagnosis.

5. If re-engagement is the right move, draft the email:
   - Under 100 words
   - Reference something specific from the last thread
   - One direct question at the end
   - No "just checking in", no "circling back"
</task>

<constraints>
- Base the diagnosis on what Lusha and Gmail actually return. Don't guess.
- The re-engagement email must reference something real from the Gmail thread.
- If the deal is genuinely dead, say so — don't dress it up as re-engageable.
</constraints>

<context>
I have a QBR or executive review coming up. I want to walk in knowing who's in the room, what's changed at their company since we last met, and what narrative to lead with.

My meeting:
- Company: [COMPANY NAME]
- Meeting type: [QBR / Executive Review / Business Review / Renewal Review]
- My goal: [CLOSE / EXPAND / RENEW / BUILD EXEC RELATIONSHIP]
- Meeting date: [DATE OR "CHECK CALENDAR"]
- Attendees: [NAMES AND TITLES OR "PULL FROM CALENDAR INVITE"]
</context>

<task>
1. Find the meeting on Google Calendar. Pull the external attendees.

2. Validate each attendee with Lusha:
   - Confirm current title and that they're still at the company
   - Flag anyone whose role has changed since the last meeting
   - Flag anyone new to the meeting
   - Note each person's likely lens: financial, technical, operational, or strategic

3. Scan the account for changes via Lusha's signals layer:
   - Executive moves in Finance, IT, or the relevant business unit
   - Headcount changes in the team using the product
   - M&A activity or funding events

4. Identify the decision-maker, the likely skeptic, and the likely champion in the room.

5. Build a one-screen pre-meeting brief:
   - One-paragraph account summary
   - Recommended narrative tied to a specific account signal
   - Top two or three questions to ask
   - One thing not to say given what's changed at the account
</task>

<constraints>
- Base everything on what Lusha and Calendar actually return.
- The recommended narrative must connect to a specific signal — not a generic value prop.
- One screen only.
</constraints>