Check whether the proposal addresses what the prospect asked for
Images on this page are for illustrative purposes only. Example outputs in this play are illustrative — the structure, fields, and format reflect real Lusha, Gmail, and Google Drive connector output, but were not pulled from a live session. Run the prompt with your own data and connectors to see live results. Personal details in any live examples are masked or abbreviated for privacy.
A proposal that misses something the prospect explicitly asked for stalls the deal. This Claude prompt pulls every question, concern, and commitment from the Gmail thread, reads the proposal from Google Drive, and returns a COVERED / PARTIAL / MISSING verdict per item before anything goes out. Lusha confirms the send-to contact is still at the company. Run it before every proposal send.
The prompt
This prompt may contain placeholders — look for [BRACKETS] and fill them in.
<context>
I'm about to send a proposal. Before it goes out, I want to check whether it actually addresses everything the prospect asked for, raised as a concern, or was promised during the sales process. I don't want the prospect to reply pointing out something I missed.
My proposal:
- Prospect name and company: [NAME, COMPANY]
- Proposal doc: [GOOGLE DRIVE LINK OR "SEARCH DRIVE FOR LATEST PROPOSAL FOR [COMPANY]"]
- Thread to check against: [GMAIL THREAD SUBJECT OR "CHECK GMAIL FOR ALL THREADS WITH [COMPANY]"]
- What I sell: [PRODUCT / SOLUTION]
</context>
<task>
1. Search Gmail for all threads with this prospect and company:
- Every specific question the prospect asked that needs to be answered
- Every concern or objection raised — even if addressed verbally on a call
- Every commitment made by the rep — "I'll include X in the proposal", "we'll show Y pricing"
- Any competitor mentioned that should be addressed
- Any specific technical requirement stated
2. Pull the proposal from Google Drive:
- Read the full document
- Identify all sections and what each one covers
3. Cross-reference thread against proposal:
For each item extracted from Gmail, check whether the proposal addresses it:
- COVERED: the proposal addresses this clearly
- PARTIAL: the proposal mentions it but doesn't fully address it
- MISSING: the proposal does not address this at all
4. Return a pre-send gap report:
- COVERED items: brief confirmation — no action needed
- PARTIAL items: what's missing from the section and suggested addition
- MISSING items: what needs to be added before sending, with suggested language
5. Overall verdict:
- READY TO SEND: all items covered or minor partials only
- NEEDS UPDATES: specific gaps that should be fixed before sending
- DO NOT SEND: critical item missing that would likely cause the prospect to reject or question the proposal immediately
6. Use Lusha to confirm the send-to contact is still at the company in the same role before anything goes out.
</task>
<constraints>
- Every MISSING item must have a specific suggested addition — not just "add a section about X."
- If a concern was raised on a call but not in email: flag that it may be in the proposal already since it was discussed verbally. Don't assume it's missing.
- DO NOT SEND is reserved for critical omissions — a missing pricing section, a missing integration the prospect specifically required, a missing term they said was a dealbreaker.
- Under no circumstances send the proposal if Lusha shows the contact has left the company.
</constraints>What you'll get back
The situation: An AE has a proposal ready to send to D.R. at Ashford Platforms. The deal has been through two discovery calls and multiple email threads. Running the pre-send check before hitting send.
Items extracted from Gmail threads
- D.R. asked: “Does this integrate natively with HubSpot?”
- D.R. asked: “Can you show a pricing breakdown by user tier?”
- Rep committed: “I’ll include a ZoomInfo comparison section since you mentioned evaluating them.”
- D.R. raised: “Our legal team will need to review the data processing terms before we sign.”
- D.R. stated: “GDPR compliance is a hard requirement — we have EU customers.”
Gap report
✅ COVERED — GDPR compliance: Section 4 of the proposal covers data processing, EU data residency, and includes the GDPR certification link. Fully addressed. — HubSpot integration: Section 3 confirms native HubSpot integration with connector documentation referenced. Covered.
⚠ PARTIAL — Pricing by user tier: Section 5 includes pricing but shows only the standard tier. D.R. specifically asked for a tier breakdown. Add a table showing the per-user price at 50, 100, and 200+ seat levels before sending.
❌ MISSING — ZoomInfo comparison: The rep committed to including this. No competitive section appears in the proposal. Suggested addition: “Add a one-page comparison table to the appendix covering data coverage, verification methodology, and pricing. Reference: ‘We evaluated ZoomInfo and chose Lusha for X, Y, Z.'” — Data processing terms for legal review: The proposal doesn’t include or link to the DPA (Data Processing Agreement). D.R. flagged the legal team needs to review this before signing. Suggested addition: “Add a line in Section 6: ‘A Data Processing Agreement is available for review at [link]. Our legal team is available to schedule a review call with your team.'”
Verdict: NEEDS UPDATES
Two items must be addressed before sending: the pricing tier breakdown and the missing ZoomInfo comparison section. The legal/DPA gap is the most critical — D.R. flagged it as a pre-sign requirement and the proposal currently gives the legal team nothing to review.
Contact status (Lusha): D.R., Head of Sales Strategy and Operations, Ashford Platforms ✓ — confirmed, same role. Safe to send once updates are made.
Illustrative example — fictional company names used. Run with your own proposal and thread data to see live results.
Why use Lusha in Claude
The ZoomInfo comparison section is the finding that changes the outcome of this deal. The rep committed to including it, D.R. remembered the conversation, and a proposal that arrives without it signals either that the rep wasn’t paying attention or that the comparison was deliberately avoided. Neither reads well. The DPA gap is worse — D.R. explicitly flagged it as a pre-sign legal requirement. A proposal that doesn’t include the DPA link adds a round-trip to the close: prospect sends it to legal, legal asks for the DPA, rep sends the DPA, close date slips by two weeks. Both findings are invisible without reading the full thread history against the document. Gmail holds the thread. Drive holds the proposal. The cross-reference takes 4 minutes.
Data drawn from 300M+ verified contacts under GDPR, CCPA, SOC 2, ISO 27701, ISO 31700, and TRUSTe.
FAQ
What if the concern was raised on a Zoom call and not in email?
The prompt flags it — “this concern was mentioned on a call and may have been addressed verbally; check whether it appears in the proposal before assuming it’s missing.” The prompt doesn’t assume a call-based concern is missing — it flags it for the rep to verify. For full call context, run this play alongside the objection brief from Zoom calls.
What counts as a DO NOT SEND verdict?
A missing pricing section when the prospect asked for pricing. A missing integration that was described as a hard requirement. A missing legal or compliance clause the prospect said was a condition of signing. A proposal that arrives without these will generate an immediate reply asking for them — which delays the close and signals the rep wasn’t listening. Everything else is a NEEDS UPDATES.
Can I use this for renewals and expansion proposals as well?
Yes — the logic is the same. Gmail surfaces every conversation with the account, including the original onboarding promises, support issues raised, and expansion goals discussed. The proposal check confirms whether those items appear in the renewal or expansion document before it goes out.
What if the proposal is a PDF rather than a Google Doc?
If the PDF is stored in Drive, the prompt can access it. If the proposal is in a format Drive can’t read (encrypted, image-based scan), the prompt will flag it as unreadable and the rep needs to paste the key sections manually as context.
How is this different from just re-reading the proposal?
Re-reading the proposal checks what’s in the document. This play checks what’s in the document against what was promised in the thread. The gap is invisible if you only read one source. The ZoomInfo section in this example would pass a manual re-read — there’s no obvious gap in the proposal structure. It only shows as missing when cross-referenced against the specific commitment made in the email thread.
Ready to build this?
Get started with Lusha and set up this play in minutes.
