Turn discovery notes into a proposal draft and ROI proof

Create one working folder or Google Doc for the deal before drafting begins. Pull the Sybill or Gong call summary, transcript snippets, HubSpot deal fields, buyer emails, pricing guidance, implementation constraints, proposal template, and approved proof points. Add a short source index that labels what came from the buyer, what came from CRM, what came from internal teams, and what is still missing. QA check: do not proceed until pricing, legal terms, timeline commitments, and delivery assumptions are either approved or clearly marked as open.

Use Claude to turn the source packet into a facts, assumptions, and open questions table. Require evidence for every confirmed fact, such as transcript language, CRM notes, buyer emails, or internal pricing guidance. Mark reasonable assumptions separately from unsupported assumptions so the proposal does not accidentally present guesses as truth. QA check: anything tied to price, timeline, integration effort, legal terms, or customer outcomes must be validated before it appears in buyer-facing copy.

Analyze this proposal source packet and separate confirmed facts from assumptions.

Source packet:
{{proposal_source_packet}}

Output a table with:
1. Confirmed fact
2. Evidence source
3. Reasonable assumption
4. Unsupported assumption
5. Open question
6. Who should validate it
7. Whether it can appear in buyer-facing copy

Rules:
- Do not infer pricing, timelines, legal terms, implementation effort, or outcomes
- Mark uncertain items as open questions
- Quote buyer language only when it is present in the source material.

Use the confirmed buyer evidence to write a short problem narrative before writing any proposal sections. Include current state, pain, business impact, cost of inaction, desired future state, and success criteria. Keep the buyer’s wording where it is useful, but avoid over-quoting or turning transcript fragments into a dramatic story. QA check: the rep should be able to read the narrative and say, “Yes, this is what the buyer actually told us.”

Using only confirmed facts and buyer language, write a proposal problem narrative.

Confirmed facts table:
{{facts_assumptions_open_questions}}

Discovery notes or transcript excerpts:
{{buyer_discovery_notes}}

Output:
1. Current state
2. Pain or friction
3. Business impact
4. Cost of inaction
5. Desired future state
6. Success criteria
7. Buyer language worth preserving
8. Claims that still need validation

Keep it specific, plainspoken, and grounded in the source material.

Create a pain-to-scope table in Google Docs before drafting the proposal. For each proposed service, capability, feature, or phase, show the buyer pain it addresses, the evidence source, expected impact, proof point, dependency, and open question. Remove or move to an appendix any scope item that does not connect to buyer evidence or a required implementation step. QA check: no major scope item should survive unless it has a buyer problem, an internal rationale, and an owner for validation.

Create a pain-to-scope table for this proposal.

Buyer problem narrative:
{{buyer_problem_narrative}}

Proposed scope options:
{{proposed_scope_options}}

Proof library:
{{approved_proof_points}}

Output columns:
1. Buyer pain or desired outcome
2. Evidence from discovery
3. Proposed scope item
4. Expected impact
5. Proof point
6. Dependency or risk
7. Open question
8. Include, revise, or remove

Do not include scope items that lack buyer evidence or a clear implementation rationale.

Create a simple Google Sheets model with value drivers such as time saved, revenue lift, cost avoided, risk reduction, adoption improvement, or cycle-time reduction. Use conservative, base, and upside ranges instead of a single exact ROI claim. Add columns for assumption source, required buyer input, confidence level, and validation owner. QA check: if the buyer has not validated an assumption, label it clearly in both the sheet and the proposal.

Create ROI assumptions for this proposal.

Buyer problem narrative:
{{buyer_problem_narrative}}

Confirmed facts:
{{confirmed_facts}}

Available metrics or benchmarks:
{{available_metrics}}

Output a table with:
1. Value driver
2. Calculation logic
3. Required buyer input
4. Conservative range
5. Base range
6. Upside range
7. Evidence source
8. Confidence level
9. Assumptions needing buyer validation

Do not invent metrics. Use placeholders for buyer inputs that are not yet known.

Review case studies, customer quotes, screenshots, product metrics, implementation examples, and security or integration proof. Choose only the proof points that support the buyer’s specific pain, industry, technical concern, or success criteria. For each proof point, note where it should appear: executive summary, scope section, ROI section, implementation plan, or appendix. QA check: remove generic logo slides unless they support the decision this buyer needs to make.

Select the most relevant proof points for this proposal.

Buyer problem narrative:
{{buyer_problem_narrative}}

Pain-to-scope table:
{{pain_to_scope_table}}

Proof library:
{{proof_library}}

For each selected proof point, provide:
1. Proof item
2. Buyer pain or risk it supports
3. Why it belongs
4. Where it should appear in the proposal
5. Permission or approval status
6. Any wording restrictions

Do not select proof that is impressive but unrelated.

Use Claude to create a proposal outline from the narrative, scope map, ROI assumptions, and proof list. The outline should include executive summary, buyer context, recommended approach, scope, assumptions, ROI model, proof, timeline, roles and responsibilities, open questions, and next steps. Add a note beside each section showing which source material supports it. QA check: get the rep or sales engineer to approve the outline before generating polished copy.

Create a proposal outline for this buyer.

Buyer problem narrative:
{{buyer_problem_narrative}}

Pain-to-scope table:
{{pain_to_scope_table}}

ROI assumptions:
{{roi_assumptions}}

Selected proof points:
{{selected_proof_points}}

Output sections:
1. Executive summary
2. Buyer context
3. Recommended approach
4. Scope by phase or capability
5. ROI assumptions
6. Proof points
7. Timeline
8. Roles and responsibilities
9. Open questions
10. Next steps

For each section, include the source material that supports it and any review risks.

Use Claude to write the first proposal draft in Google Docs from the approved outline. Keep assumptions, open questions, buyer inputs needed, and validation items visible instead of hiding them in polished language. Write in a consultative tone that connects each recommendation back to the buyer’s stated pain. QA check: scan the draft for unsupported numbers, invented commitments, vague benefits, and anything delivery or legal has not approved.

Write the first proposal draft using this approved outline and source material.

Approved outline:
{{proposal_outline}}

Source packet:
{{proposal_source_packet}}

Brand voice:
{{brand_voice}}

Rules:
- Use buyer-specific language
- Label assumptions clearly
- Keep open questions visible
- Do not invent pricing, legal terms, timelines, integrations, or commitments
- Do not overpromise outcomes
- Make every major recommendation traceable to buyer evidence

Output a complete proposal draft with section headings and review notes.

Use Claude and Canva to create a one-page executive summary that the buyer champion can forward internally. Include the buyer problem, why now, recommended path, expected impact range, proof point, decision needed, and next step. Keep the page skimmable and avoid cramming the full proposal into a visual summary. QA check: ask whether the page still makes sense if it is forwarded without your email or sales call narration.

Turn this proposal into a one-page executive summary.

Proposal draft:
{{proposal_draft}}

Buyer problem narrative:
{{buyer_problem_narrative}}

ROI assumptions:
{{roi_assumptions}}

Selected proof points:
{{selected_proof_points}}

Output:
1. Buyer problem
2. Why now
3. Recommended approach
4. Expected impact range
5. Proof point
6. Decision needed
7. Next step
8. Short design notes for Canva

Keep copy concise enough for a one-page visual.

Route the draft to the account owner, sales manager, sales engineer, delivery owner, and anyone responsible for pricing, security, or legal terms. Ask reviewers to comment directly in Google Docs using a checklist for buyer accuracy, scope feasibility, unsupported claims, pricing assumptions, delivery risk, legal risk, and missing next steps. Resolve comments before sending instead of relying on the rep to explain issues live. QA check: the final version should have no unresolved comments on scope, price, implementation timeline, or commitments.

Create an internal proposal review checklist for this draft.

Proposal draft:
{{proposal_draft}}

Known open questions:
{{open_questions}}

Review for:
1. Buyer accuracy
2. Scope feasibility
3. Unsupported claims
4. Pricing assumptions
5. Delivery risk
6. Legal or security risk
7. Missing next steps
8. Implementation ownership
9. Claims that need evidence

Return a checklist reviewers can use in Google Docs comments.

Draft the proposal send email after the proposal is reviewed, not before. Reference the discovery conversation, state what the proposal is designed to solve, mention any assumptions that need validation, and recommend a live walkthrough. Keep the email short enough that the buyer understands the purpose without reading the full proposal first. QA check: the email should make it clear what feedback you want and what meeting should happen next.

Write a proposal send email.

Buyer context:
{{buyer_context}}

Proposal summary:
{{proposal_summary}}

Open assumptions to validate:
{{open_assumptions}}

Recommended next step:
{{recommended_next_step}}

Rules:
- Keep it under 160 words
- Reference the buyer's key priority
- State what the proposal covers
- Recommend a walkthrough
- Mention validation needs without sounding uncertain
- Do not over-explain the full proposal in the email.

After the buyer reviews the proposal, log questions, objections, requested edits, decision-process changes, and which sections created confusion. Update HubSpot with the buyer’s response and save the lessons in the proposal template or proof library. Use Claude to summarize what should change in future proposals, including better discovery questions, stronger proof, clearer ROI inputs, or sections to remove. QA check: every proposal should leave behind at least one improvement to the proposal system, even if the deal does not close.

Analyze buyer feedback on this proposal.

Proposal sent:
{{proposal_draft}}

Buyer feedback:
{{buyer_feedback}}

Deal outcome or next step:
{{deal_outcome}}

Output:
1. What confused the buyer
2. What mattered most
3. Which assumptions were challenged
4. Which proof points worked
5. Which sections should be improved
6. Better discovery questions for next time
7. Updates to proposal template
8. Updates to proof library

Be specific and separate one-off deal feedback from reusable lessons.