More Resources
Prompt

Stage-gate readiness check before advancing a deal

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

A Claude prompt that fires the moment before an AE advances a deal’s stage in the CRM. The prompt takes the current stage, the target stage, and the contacts touched so far. It returns a clear advance-or-hold decision based on the buying group coverage requirements for the target stage. If hold, it prescribes the specific touches that need to happen first.

Most forecast inflation comes from stage advancement without coverage. The end user said something positive, the deal moves to Proposal, and the economic buyer is still cold. Built to prevent that pattern. Useful for AEs running their own forecast discipline and Sales Managers checking deal advancement decisions.

Once Lusha is connected in Claude, the connector runs in the background — no special syntax needed. Just describe the deal and the stage you’re considering, 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>
I'm about to advance a deal to the next stage in our CRM. Before I do, I want a readiness check: does the buying group coverage actually justify the advance, or are there critical touches missing that should happen first?

My deal:
- Prospect company / domain: [COMPANY]
- Current stage: [Discovery / Proposal / Negotiation / Closing]
- Target stage (where I'm about to move it): [TARGET]
- What I'm selling: [PRODUCT / SOLUTION]
- Contacts touched so far (name, role, last touch date): [LIST]
- Reason I want to advance (one line): [WHY YOU THINK IT'S READY]
</context>

<task>
1. Use Lusha to pull the verified buying group at the prospect company across the five role families:
   - Economic buyer
   - Technical evaluator
   - End user
   - Influencer (RevOps, procurement, IT)
   - Executive sponsor
2. Apply the stage-gate framework for the target stage:
   - Discovery -> Proposal: Must have meaningful engagement with technical evaluator AND end user. Should have at least one influencer touched.
   - Proposal -> Negotiation: Must have economic buyer touched and aware of pricing context. Should have procurement or finance influencer engaged.
   - Negotiation -> Closing: Must have economic buyer signed off on pricing and executive sponsor briefed. Should have procurement signed off on contract structure.
   - Closing -> Closed Won: Must have signed contract from economic buyer plus implementation ownership confirmed with end user.
3. Compare the contacts touched against the target stage's coverage requirements.
4. Return one of three decisions:
   - ADVANCE: coverage meets requirements for the target stage. Proceed with the stage update.
   - HOLD (close one gap first): coverage is close but missing one or two musts. Prescribe the specific touches needed before advancing.
   - HOLD (significant coverage gap): coverage is structurally insufficient for the target stage. The deal may be stage-inflated. Surface the gaps and the right next moves.
5. For HOLD decisions, prescribe the next 1-2 touches in priority order with:
   - The verified contact (name, title)
   - The role they fill in the gap
   - The angle for the touch (one sentence)
   - The timeline (when this needs to happen before the advance becomes legitimate)
6. If the AE's "reason for advancing" doesn't line up with the actual coverage (e.g., "had a good conversation with the end user" but the target stage requires economic buyer coverage), flag the disconnect honestly.
</task>

<constraints>
- The framework is not negotiable. A Proposal-stage deal without the economic buyer touched is not ready to advance to Negotiation, regardless of how positive the end user conversations have been.
- The output is a clear decision plus reasoning. ADVANCE means proceed. HOLD means specific touches first.
- Do not invent contacts or coverage. Surface only what Lusha confirms.
- The prompt is forecast-discipline-positive. A HOLD decision protects forecast accuracy. Being honest about coverage gaps is more valuable than advancing a deal that isn't ready.
</constraints>

What you'll get back

Input: Open deal at [Cloud data platform]. Current stage — Proposal. Target stage — Negotiation. Product — sales productivity platform. Contacts touched so far: Keegan R. (SVP Sales Americas, end user, touched 8 days ago), Patrick H. (VP RevOps, influencer, touched 23 days ago), Dwarak R. (VP AI Engineering, technical evaluator, touched 12 days ago). AE’s reason for advancing: “Pricing conversation went well with Keegan, he wants to move forward.”

Output: HOLD — close one gap first. The economic buyer hasn’t been touched, which is the critical requirement for advancing to Negotiation. Below is the real result from running the prompt against the live Lusha connector.

Readiness decision: HOLD — close one gap first

The deal is close to ready, but advancing now creates real forecast risk and a likely procurement surprise later. One critical touch needs to happen first.

Coverage analysis for Proposal → Negotiation

RoleStatusStage requirementResult
Economic buyer (Brian R., CFO)NOT TOUCHEDMUST for Negotiation❌ Critical gap
Technical evaluator (Dwarak R., VP AI Engineering)Touched 12 days agoRequired from prior stage✓ Covered
End user (Keegan R., SVP Sales Americas)Touched 8 days agoRequired from prior stage✓ Covered
Influencer (Patrick H., VP RevOps)Touched 23 days ago — staleSHOULD for Negotiation⚠ Touched but stale
Executive sponsor (Jonathan B., new CRO)NOT TOUCHEDOptional for Negotiation, recommended—

Honest read on the AE’s reasoning

“Pricing conversation went well with Keegan” is a legitimate positive signal — the end user wants to move forward. But Keegan is the end user, not the economic buyer. The economic buyer is the CFO (Brian R.), who hasn’t seen pricing yet. Advancing to Negotiation now means the contract reaches Brian’s desk without prior context, and the typical response to surprise pricing is procurement-driven delay. The deal won’t be lost, but it will slip 30-45 days as a result.

Prescribed touch before advancing

1. Brian R., Chief Financial Officer (economic buyer)

  • Role in gap: Critical — required for Negotiation stage
  • Angle: Pricing visibility brief framed as “wanted to give context before the contract reaches your team.” Position it as transparency, not pre-selling.
  • Timeline: Within the next 5-7 business days
  • Right path: Coordinate with Keegan to make the introduction — Keegan’s pricing conversation went well, so he has natural pretext to loop the CFO in proactively.

Secondary touch (recommended but not blocking)

2. Patrick H. (VP RevOps) — stale thread refresh

  • The 23-day silence at Proposal stage is a soft signal that RevOps influence is fading. A refresh touch using the new CRO arrival as the pretext is the natural move — pair it with the Brian R. touch so the deal has clean RevOps + CFO coverage going into Negotiation.

Decision summary

  • Advance to Negotiation now: Not recommended. Forecast accuracy risk is real, and the deal will likely surface coverage gaps under procurement scrutiny.
  • Close the economic buyer gap, then advance: Recommended. Adds 5-7 days to the timeline but protects the forecast and prevents the procurement surprise.

The verified buying group data reused from earlier gallery runs — zero new credits consumed.

Why use Lusha in Claude

Stage advancement without coverage is the single biggest source of forecast inflation in B2B. Three patterns repeat across every misjudged advance.

The end user’s enthusiasm is the most over-weighted signal in deal progression. End users are easier to engage, more available for meetings, more comfortable saying positive things about a product they want to use. AEs interpret end user enthusiasm as deal momentum, advance the stage, and the deal stalls when the economic buyer sees pricing for the first time. The prompt surfaces this pattern by distinguishing the touched role from the stage’s actual requirement. End user enthusiasm is good. End user enthusiasm without economic buyer coverage is not yet a Negotiation-stage deal.

Stale threads are the second silent killer of stage readiness. A contact touched 23 days ago at active Proposal stage isn’t “covered” in any meaningful sense — the relationship is fading. The prompt’s 14-day threshold for active-stage staleness catches this. Reps who advance deals because the contact list shows everyone “touched” without checking recency are advancing deals that have already lost half their thread relationships.

The honest read on the AE’s reasoning is the page’s strongest single feature. Most pipeline tools accept the AE’s stage update at face value. The prompt asks why the rep thinks the deal is ready, then maps the reason against the actual coverage requirements. When the reason doesn’t line up (positive end user conversation as justification for Negotiation advance), the prompt surfaces the disconnect honestly. This isn’t second-guessing the rep — it’s the structural discipline that makes forecasts trustworthy.

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

FAQ

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

    The multi-thread audit (Prompt 2 of this gallery) runs at any time and surfaces the current coverage state plus suggested touches. This prompt runs at a specific decision moment — the AE is about to update the stage — and returns a binary advance-or-hold decision. The audit informs; the readiness check decides. AEs run the audit during pipeline review; they run the readiness check the moment before clicking “advance stage” in the CRM.

  • What if my CRM uses different stage names than Discovery / Proposal / Negotiation / Closing?

    The framework maps to the deal’s underlying progression, not the CRM’s stage labels. If your CRM uses MEDDIC stages, BANT stages, or custom stages, describe the target stage’s actual requirement (who needs to have committed, who needs to have approved) and the prompt applies the framework accordingly. The output is the same: advance-or-hold decision plus prescribed touches.

  • What happens if I overrule the HOLD recommendation and advance anyway?

    The CRM stage update is yours to make — the prompt’s job is to surface the structural state, not to gatekeep your decision. AEs sometimes have context the prompt doesn’t (a Slack DM from the CFO confirming budget verbally, a recent internal champion conversation that won’t show in the touched-contacts list). The HOLD recommendation is a structural read, not a final answer. Track which HOLD-then-advance decisions worked and which slipped — over time, the patterns become clear.

  • Can Sales Managers use this for deal reviews?

    Yes — it’s especially useful for that case. When a Sales Manager is reviewing a rep’s pipeline and sees a Negotiation-stage deal, running the readiness check on it surfaces whether the stage assignment is structurally sound. If it isn’t, the manager and rep can have the coverage conversation before the forecast roll-up. Most managers run this on the top 5-10 deals in the forecast before each weekly review.

  • Does the prompt account for fast-cycle deals (under 30-day average)?

    The defaults work for typical 60-180 day B2B cycles. For fast-cycle deals (transactional or SMB), the touched-recency threshold tightens to 5-7 days, and the buying group is usually smaller (often economic buyer = end user). Describe the cycle context in the input and the prompt adjusts.

  • What if the verified buying group at the prospect has unusual structure?

    Some companies don’t have a traditional economic buyer at the seat the rep is selling — engineering tools sometimes get bought by the engineering team directly, marketing tools sometimes get approved by the CMO without a separate finance gate, small companies sometimes don’t have RevOps as a distinct role. The prompt surfaces structurally absent roles honestly. The framework adapts: if there’s no separate economic buyer at the prospect, the framework’s economic-buyer requirement is satisfied by the function head’s commitment.

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