TLDR: FinTech deals stall for reasons that don’t show up in the CRM — a signer who left during a six-month cycle, a compliance layer added post-NDA, an acquisition that froze every vendor contract in the building. These seven Claude prompts are built to catch those signals before they kill the deal: three for identifying risk before the standup, two for auditing buying group coverage, and three for validating stage advancement and close readiness. All run on Lusha’s verified contact and company data inside Claude.
FinTech sales cycles are long. Six months is a fast close. Twelve to eighteen months is normal for enterprise. During that time, the deal changes in ways no CRM field captures: the CISO who championed the evaluation departs and the security review restarts. The prospect gets acquired and every vendor contract in the building goes on ice. A compliance mandate triggers a stack re-evaluation that routes the deal through a procurement layer the rep has never met. The contact who signed the NDA is now SVP at a different company.
None of that surfaces in a pipeline review built from CRM data. A rep updates the stage, logs a call note, and the deal looks like it’s moving — until it isn’t.
These seven prompts are built for FinTech sales teams and RevOps leaders who need to see what’s actually happening at prospect accounts, not just what got logged. Organized into three workflows: detecting deal risk before it compounds, auditing buying group coverage against the current deal stage, and validating that a deal is ready to advance before the CRM says it is.
All seven run on Lusha’s verified contact and company data.
Connect Lusha to Claude in two minutes →
Deal risk detection (Prompts 1–3)
In a six-month FinTech sales cycle, the account changes between touchpoints. A contact goes dark, an acquisition gets announced, a funding event shifts the buying mandate. These three prompts are built to surface those changes before the standup — not from CRM notes, but from what’s actually happening at the prospect account right now.
Prompt 1 — Run the weekly pipeline review and flag every deal at risk
Before the Monday standup, this prompt scans every active deal for structural account risk via Lusha — a departed CFO, an acquisition where the prospect is the acquired party, a headcount contraction in the buying team — and checks meeting cadence per deal via Google Calendar. For FinTech pipeline specifically, the acquisition signal is the one to watch: when a prospect gets acquired, vendor contracts typically freeze within weeks, and deals that were tracking to close get routed to the acquirer’s procurement process. A deal that shows RED on both account risk and engagement risk gets a double-RED flag — those are the ones to act on before the standup.
<context>
I want to run a weekly pipeline review before my team standup. I need to know which deals have a risk signal worth flagging — not from CRM health scores, but from what's actually happening at the prospect accounts right now.
My pipeline:
- Deal list: [PASTE DEAL NAME, COMPANY, STAGE, ACV, OWNER — one per line OR "pull from my calendar"]
- Team size: [NUMBER OF REPS]
- Focus: [ALL DEALS / CLOSE THIS QUARTER / SPECIFIC STAGE]
- What I want to flag: [ALL RISKS / STUCK DEALS / MISSING MEETINGS / STRUCTURAL CHANGES]
</context>
<task>
1. For each deal in the list, use Lusha to scan the prospect account for structural changes in the last 30 days:
- Executive departure or new hire in the buying function (CFO, CTO, CRO, VP of the relevant department)
- M&A activity where the prospect is the acquired party
- Significant headcount contraction in the team being sold into
- Any signal that typically re-routes or freezes vendor decisions
2. For each deal, check Google Calendar for meeting activity:
- When was the last meeting with this account?
- Is there a next meeting scheduled?
- Flag any deal where the last meeting was more than 21 days ago with nothing on the calendar — that's a stuck deal
3. Rate each deal on two axes:
ACCOUNT RISK (from Lusha signals):
- RED: structural change that directly threatens the deal
- AMBER: signal worth watching but not immediately threatening
- GREEN: no structural signals detected
ENGAGEMENT RISK (from Calendar):
- RED: no meeting in 21+ days, nothing scheduled
- AMBER: last meeting 11–20 days ago, next meeting not confirmed
- GREEN: active meeting cadence, next meeting on the calendar
4. Return a pipeline health report:
- Summary line: X deals reviewed, X RED, X AMBER, X GREEN
- RED deals first — account risk, engagement risk, and one recommended action for each
- AMBER deals — flagged with the specific signal or gap
- GREEN deals — listed only, no detail needed
- One question to ask each RED deal owner in the standup
5. Flag any deal where both account risk and engagement risk are RED — these are the deals most likely to slip the quarter.
</task>
<constraints>
- Flag only signals Lusha actually returns. Don't infer risk from deal age or rep tenure.
- The standup question for each RED deal must be specific to the risk — not "how's this deal going?" but "who's your relationship with now that Marcus left?"
- Keep the report to one screen. This is a standup tool, not a board deck.
- If a deal has no Lusha signal and an active meeting cadence, it's GREEN. Don't manufacture risk.
</constraints>Prompt 2 — Post a deal risk alert to Slack when a prospect gets acquired
In FinTech, an acquisition is the single most common deal killer that no CRM flag will catch. When a prospect gets acquired, vendor contracts freeze within weeks — typically pending the acquirer’s procurement review — and deals that were tracking to close get routed to a process the rep has never touched. This prompt monitors every account in the active pipeline for acquisition signals via Lusha, assesses each event as FREEZE RISK, RE-ROUTE RISK, or OPPORTUNITY, and posts a Slack alert to the relevant channel before the rep finds out on a discovery call. No signal means no post — it only fires when there’s something to act on.
<context>
I want to post a deal risk alert to our sales Slack channel when a prospect or customer gets acquired — before the rep discovers it on a call. The signal should go to the deal owner and their manager the same day it's detected.
My accounts to monitor:
- Account list: [PASTE COMPANY NAMES — or "check my active pipeline"]
- Slack channel: [CHANNEL NAME — e.g. #deal-alerts or #revenue-team]
- Deal owners: [REP NAME PER ACCOUNT — or "find from context"]
</context>
<task>
1. For each account, use Lusha's signals layer to check for M&A activity:
- Has the company been acquired as the target entity?
- Has the company announced a merger?
- Has there been a significant ownership or parent company change?
- Note: acquisition as the acquirer is a positive signal — only flag acquired-as-target
2. For each account where M&A is detected:
- Confirm the signal via Lusha: who acquired them, approximate timing
- Assess the deal impact:
- FREEZE RISK: vendor contracts often frozen during integration
- RE-ROUTE RISK: procurement and approval paths change after acquisition
- OPPORTUNITY: if the acquirer is also a prospect or customer, flag the relationship angle
- Find any new contacts introduced by the acquisition
3. Draft a Slack alert for each flagged account:
- Start with the impact, not the news
- State what was detected and when
- State the most likely deal impact
- Name one specific action the rep should take before their next touch
- Tag the deal owner and manager
- Under 80 words, formatted for Slack with *bold* key fields
4. Post the alert to the specified Slack channel.
5. If no M&A signals detected: no post needed.
</task>
<constraints>
- Only post when Lusha confirms M&A activity.
- Acquired-as-acquirer is not a risk signal — only acquired-as-target gets an alert.
- The recommended action must be specific: not "follow up" but a concrete next step.
- One alert per account per signal event.
</constraints>Prompt 3 — Find out why your deal went quiet
In a six-to-eighteen-month FinTech cycle, a deal going quiet doesn’t mean the same thing every time. A contact who stopped replying is a different problem from a compliance layer added after the NDA, which is a different problem from an acquisition that froze the contract. Sending the same re-engagement email regardless of which one it is is why most follow-ups fail. This prompt checks Lusha for structural changes at the account since the last touch, pulls the Gmail thread to see who sent the last email and what was said, and returns one of four diagnoses — CONTACT GONE, INTERNAL BLOCKER, ENGAGEMENT DROP, or MY DROP — each with a different prescribed next action. If re-engagement is the right move, it drafts the email from the actual thread: no generic check-ins, no circling back.
<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 I was talking to changed roles, left, or gone elsewhere?
- Any executive changes in the buying function (new CRO, CFO, CTO, VP of the relevant department)?
- Any M&A activity — acquisition, merger, or restructure?
- Any significant headcount changes in the team we were selling into?
- Any funding event (positive — may unlock budget; or down round — may freeze it)?
2. Pull my last email thread with this contact from Gmail:
- What was the last thing discussed?
- Who sent the last email — me or them?
- Is there an unanswered email on either side?
- Did I make a commitment I haven't followed through on?
- Was there any signal of hesitation, objection, or delay in the last exchange?
3. Based on what Lusha and Gmail return, diagnose why the deal went quiet:
- CONTACT GONE — the person I was talking to left or changed roles
- INTERNAL BLOCKER — a structural change at the account (M&A, reorg, budget freeze) stalled the deal
- ENGAGEMENT DROP — no structural change, but the thread went cold — likely a priority or interest shift
- MY DROP — the last unanswered email was mine and I haven't followed up
4. Based on the diagnosis, prescribe one clear next action:
- CONTACT GONE: use Lusha to find the new owner and draft a re-entry email
- INTERNAL BLOCKER: identify who now owns the decision and what the right re-entry timing is
- ENGAGEMENT DROP: draft a direct re-engagement email that names the silence and asks a specific question
- MY DROP: draft a short follow-up that picks up the thread without over-explaining the gap
5. If re-engagement is the right move, draft the email:
- Under 100 words
- Reference something specific from the last thread
- One direct question or ask at the end
- No "just checking in", no "hope you've been well", no "circling back"
</task>
<constraints>
- Base the diagnosis on what Lusha and Gmail actually return. Don't guess.
- If the contact is still at the company and there's no structural change, don't manufacture a reason the deal went quiet — call it an engagement drop and treat it as such.
- The re-engagement email must reference something real from the Gmail thread. A generic email is not acceptable output.
- If the deal is genuinely dead (contact gone, no clear successor, M&A freeze, 90+ day silence), say so — don't dress it up as re-engageable.
</constraints>Buying group coverage (Prompts 4–5)
FinTech enterprise deals don’t have one buyer — they have five. The business owner who wants the product, the compliance team who needs to approve it, the security team who will run their own evaluation, procurement who controls the contract, and the economic buyer who signs off on budget. Having two contacts at an account isn’t coverage. It’s a gap with false confidence. These two prompts map the actual verified state of every required role in the buying group — per deal and across the named account base.
Prompt 4 — Audit multi-thread coverage on an open deal
The forecast-protection prompt for FinTech AEs. Maps verified contacts in every required buying group role against the current deal stage, flags the gaps that predict slip, and prescribes the next 2–3 touches needed to protect the forecast. In FinTech deals specifically, the compliance and procurement gates are the ones most often missing from the CRM — because reps don’t get introduced to them until the deal hits legal review, which is already too late. This prompt surfaces those gaps at Proposal, not at Negotiation.
<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 / domain: [COMPANY]
- 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]
</context>
<task>
1. Use Lusha to pull the verified buying group at the prospect company, organized by role family:
- Economic buyer (CFO, VP Finance, or C-suite owner of the function)
- Technical evaluator (CTO, VP Engineering, Solutions Engineering leadership for product-led evaluations)
- End user (the function leader who will own the day-to-day use — VP Sales, VP Marketing, etc.)
- Influencer (RevOps, procurement, sometimes IT — the operators who shape the decision around the named buyers)
- 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 stage — must have: technical evaluator touched. Should have: end user + at least one influencer. Optional: economic buyer.
- Proposal stage — must have: economic buyer + technical evaluator + end user. Should have: influencer (especially procurement and RevOps).
- Negotiation stage — must have: economic buyer + procurement (or finance gate). Should have: executive sponsor.
- Closing stage — must have: economic buyer signed off + executive sponsor briefed. Should have: end user confirmed for rollout.
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)
- Acceptable gaps (optional for current stage — for context)
5. Prescribe the next 2-3 touches in priority order, with verified contact details and a one-line angle per touch.
6. Flag any contact in the buying group who has been touched but has gone quiet for more than 14 days at the current deal stage. Stale threads in active deals are forecast risk.
</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. If a role family is empty at the prospect, flag it as a structural gap that may require manual research.
- The audit is a tool for the AE's judgment, not a replacement for it. Surface the gaps; let the AE decide which to close first.
</constraints>Prompt 5 — Map the buying group and audit your deal coverage
FinTech enterprise deals don’t get lost because a rep wasn’t working hard enough — they get lost because the rep was working the wrong people. The compliance team who needs to approve the vendor contract, the procurement gate who controls the PO, the executive sponsor who signs off on budget: none of them show up in the CRM until it’s too late to build the relationship. This prompt uses Lusha to map the full verified buying group by role family — economic buyer, technical evaluator, end user, influencer, executive sponsor — compares it against who’s already been touched, applies the deal-stage gap framework, and prescribes the next two or three touches with verified contact details and a one-line angle each. It also flags any contact in the buying group who’s been touched but gone silent for more than 14 days — stale threads in active FinTech deals are forecast risk, not just a relationship management issue.
<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 — VP Sales, VP Marketing, etc.)
- Influencer (RevOps, procurement, IT — operators who shape the decision around the named buyers)
- 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 (procurement and RevOps).
- Negotiation — must have: economic buyer + procurement or finance gate. Should have: executive sponsor.
- Closing — must have: economic buyer signed off + executive sponsor briefed. Should have: end user confirmed for rollout.
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)
- Acceptable gaps (optional for current stage — for context)
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 in the buying group who has been touched but has gone quiet for more than 14 days at the current deal stage. Stale threads in active deals are forecast risk.
</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. If a role family is empty at the prospect, flag it as a structural gap that may require manual research.
- The audit is a tool for the AE's judgment, not a replacement for it. Surface the gaps; let the AE decide which to close first.
</constraints>Stage advancement and close readiness (Prompts 6–7)
FinTech deals get stage-inflated more than almost any other vertical. A compliance meeting looks like progress. A security review creates CRM activity that doesn’t translate to deal motion. A procurement introduction gets logged as a positive development while the actual economic buyer still hasn’t been touched. These three prompts check whether a deal is actually ready to advance, whether the close plan is built on verified data, and whether the pipeline exposure number for leadership is accurate.
Prompt 6 — Stage-gate readiness check before advancing a deal
The forecast-hygiene prompt. Run this before a rep updates a stage in the CRM — confirm the coverage actually justifies the advance, or surface the gap that should be closed first. In FinTech specifically, the Negotiation → Closing gate is where deals most often get stage-inflated: reps move deals to Closing because a commercial discussion happened, not because the economic buyer and procurement have both been confirmed. This prompt makes that check explicit before the CRM update happens.
<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>Prompt 7 — Decision-maker validation pre-close
The final pre-signature check for FinTech deals. In a six-to-eighteen-month sales cycle, the signer can change more than once. This prompt validates three things before the contract goes out: the planned signer is still at the company and still has signing authority for this contract value, the buying group the rep has been working is still current, and there are no structural changes at the prospect in the last 30–90 days that would freeze or re-route the deal. The M&A check matters most in FinTech — when a prospect gets acquired, the first thing the acquirer typically does is pause all vendor contracts pending review. Catching that before the contract goes out saves the close.
<context>
I'm about to send the contract for signature on a deal. Before I do, I want to validate the decision makers — confirm the signing authority is current, the buying group roles are correct, and nothing has changed at the prospect that would re-route the contract.
My deal at contract stage:
- Prospect company / domain: [COMPANY]
- Planned signer (name, title): [NAME, TITLE]
- Contract value (annual): [DOLLAR AMOUNT]
- Contract term: [LENGTH]
- Buying group I've been working with (name, role): [LIST]
- Date of last meaningful touch with the signer: [DATE]
- Stage in CRM: [Negotiation / Closing]
</context>
<task>
1. Use Lusha to validate the planned signer:
- Confirm the signer's current title matches what's on the contract
- Confirm the signer is still at the prospect company (catches departures that happened during the deal)
- Check the signer's seniority level against the contract value (a $250K annual contract typically requires VP or higher signing authority; $1M+ typically requires C-suite)
- Surface the signer's job start date — if they joined recently, their authority may not yet cover this contract size
2. Validate the buying group roles I've been working with:
- Confirm each contact's current title matches my notes
- Flag any contact who has departed, been promoted, or changed roles since the last touch
- Surface anyone in the buying group whose role change means their position on the contract approval chain has shifted
3. Use Lusha's signals layer to scan the prospect for structural changes since my last meaningful touch:
- Executive departures (especially anyone in the contract approval chain — CRO, CFO, CSTO, CTO)
- Leadership hires (anyone new in the approval chain who may want to review)
- M&A as the acquired party (acquired companies often freeze contracts during integration)
- Security incidents (may trigger new procurement scrutiny)
- Major reorganizations (changed reporting lines = changed approval routing)
4. Return a clear pre-close decision:
- SEND — signer validated, buying group current, no structural changes. Safe to send the contract today.
- HOLD — verify one thing first — minor issue caught (stale contact info, recent change worth confirming, signer's authority at this dollar amount uncertain). Prescribe the specific verification.
- HOLD — structural change — significant change at the prospect that materially affects the contract path. Surface what changed and the right next move (re-route the contract, re-validate with new owner, pause for procurement re-check).
5. If the planned signer has departed, surface the verified replacement candidate (using the find-new-champion logic) and recommend re-validation before sending.
</task>
<constraints>
- Validation is binary on each check — the contact is at the company or they aren't, the title matches or it doesn't. Don't soften with "probably still there."
- The signer authority check is approximate (Lusha doesn't return signing limits), but seniority + recent role can flag the obvious mismatches.
- Do not invent contacts, roles, or signals. Surface only what Lusha returns.
- A SEND decision means the contract can go out today. A HOLD decision means specific verification first. Be clear which.
</constraints>The pattern across all prompts
The seven prompts above cover three different pipeline acceleration problems — deal risk detection, buying group coverage, and stage and close readiness — but share one structural pattern: the verified data layer is what makes each output actionable, not just informative.
Generic AI prompts produce plausible analysis of the data that already exists in the CRM. These prompts go outside the CRM — to Lusha’s verified contact records, signal layer, and company data — and surface what the CRM doesn’t know. In FinTech pipeline specifically, the difference shows up in four places:
- Structural account risk gets caught before the standup. An acquisition, a CISO departure, a headcount contraction in the buying team — none of those get logged in the CRM by the rep, because the rep doesn’t know they happened. The weekly pipeline review prompt (Prompt 1) runs that scan before the meeting, not after the deal slips.
- Coverage gaps get fixed at Proposal, not at Negotiation. The compliance and procurement contacts in a FinTech deal are the ones most often missing from the CRM — because reps don’t get introduced to them until legal review. The multi-thread coverage prompt (Prompt 4) surfaces those gaps at the right stage, when there’s still time to build the relationship.
- Stage advances reflect actual coverage, not rep optimism. A compliance meeting is not a stage advance. A security review is not a stage advance. The stage-gate prompt (Prompt 6) checks whether the buying group actually justifies the move before the CRM gets updated — which is the only point where finding the gap still helps.
- Pre-close validation catches what long cycles create. In an eighteen-month deal, the signer can change, the approval chain can shift, and an acquisition can freeze the contract. The decision-maker validation prompt (Prompt 7) runs that check before the contract goes out — when acting on it still saves the close.
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.
- Run the weekly pipeline review and flag every deal at risk →
- Post a deal risk alert to Slack when a prospect gets acquired →
- Find out why your deal went quiet →
- Audit multi-thread coverage on an open deal →
- Map the buying group and audit your deal coverage →
- Stage-gate readiness check before advancing a deal →
- Decision-maker validation pre-close →
All seven are part of the Lusha Pipeline Acceleration Gallery — a library of Claude prompts built for every role in a revenue team.
