Sales teams, Account executives, Founders, Consultants, Sales managers
Prepare the Required Inputs listed in the Workflow Prompt. Use as much detail as necessary.
1. Copy the Workflow Prompt.
2. Paste it into your AI tool.
3. Replace the "Required Inputs"
4. Run the prompt.
Get access to this workflow and 1000+ others designed to save hours and get better results with AI.
You are a sales proposal architect. Your task is to create a reusable proposal structure that helps buyers understand the problem, evaluate the recommendation, trust the path, and take the next decision step.
### Required Input
- Offer: [What the proposal is for]
- Buyer Type: [Role, company type, decision maker or evaluator]
- Sales Stage: [Post-discovery, after demo, formal RFP, renewal, expansion, pilot]
- Proposal Goal: [What the proposal must achieve, e.g. secure pilot, win approval, align stakeholders]
- Deal Complexity: [Simple, mid-complexity, enterprise, multi-stakeholder]
- Required Content: [Pricing, scope, timeline, proof, legal notes, technical section, case studies]
- Tone: [Formal, executive, consultative, concise]
### Input Validation
Review all inputs before creating the structure. If offer, buyer type, proposal goal, sales stage, or required content are missing or vague, ask specific clarification questions. Pause and wait for clarification before generating the final output.
### Instructions
Design a proposal structure that supports buyer decision-making, not just seller presentation. The section order should move logically from context and need to recommendation, value, implementation, proof, risks, investment, and decision path.
Tailor the structure to deal complexity. A simple deal should not require a long enterprise proposal. A complex deal may need stakeholder alignment, implementation detail, risk handling, and business case support.
For each section, explain its purpose, what to include, what to avoid, and how long it should be. Include optional sections only when they serve a decision need.
Ensure the structure makes the proposal usable for people who did not attend the sales calls. Include enough context for internal forwarding without making the document bloated.
Add guidance on where to place pricing, proof, scope, risks, and next steps. Include common mistakes that weaken proposals.
### Output
Provide the proposal template in this format:
1. Proposal Strategy Summary
2. Recommended Section Order
3. Section-by-Section Template: Purpose, Content to Include, Content to Avoid, Suggested Length
4. Required Sections
5. Optional Sections by Deal Type
6. Where to Place Pricing and Scope
7. Where to Place Proof and Risk Reduction
8. Internal Champion Forwarding Notes
9. Common Proposal Structure Mistakes
10. Final Proposal Review Checklist
Create a shorter structure for simple low-complexity deals.
Required inputs used:
Offer: Customer onboarding automation platform with implementation support
Buyer Type: COO and Head of Customer Success at a 150-person B2B SaaS company
Sales Stage: After demo and discovery
Proposal Goal: Win approval for a paid pilot that can expand into full rollout
Deal Complexity: Mid-complexity, multi-stakeholder
Required Content: Executive summary, problem context, recommended pilot scope, implementation plan, timeline, success criteria, pricing, proof, risks, stakeholder responsibilities, and next steps
Tone: Executive and consultative
The proposal should help stakeholders who attended the demo and stakeholders who did not. It should move from business context to recommended pilot, value, delivery plan, risk controls, investment, and decision path. Because the goal is a paid pilot rather than full enterprise rollout, the proposal should be focused enough to approve quickly while still giving operations, customer success, and finance confidence.
The structure should avoid overwhelming the buyer with every feature. It should show why the pilot is the right next step, how success will be measured, what each side must do, and how the buyer can decide whether to expand.
Section: Cover Page
Purpose: Make the proposal easy to identify and forward.
Content to Include: Buyer company name, proposal title, seller name, date, proposal owner, and confidentiality note if appropriate.
Content to Avoid: Long slogans or generic marketing claims.
Suggested Length: 1 page.
Section: Executive Summary
Purpose: Give senior stakeholders the decision logic quickly.
Content to Include: Current issue, recommended pilot, expected business outcomes, why now, and requested decision.
Content to Avoid: Feature lists, technical detail, or generic company background.
Suggested Length: 0.5 to 1 page.
Section: Buyer Context and Current Challenge
Purpose: Show that the recommendation is based on the buyer’s situation.
Content to Include: Growth in onboarding volume, manual coordination pain, visibility gaps, inconsistent handoffs, and stakeholder priorities from discovery.
Content to Avoid: Unverified assumptions or exaggerated pain.
Suggested Length: 0.5 to 1 page.
Section: Recommended Pilot
Purpose: Explain what is being proposed and why a pilot is the right next step.
Content to Include: Pilot duration, teams included, workflows included, systems involved, and intended decision after pilot.
Content to Avoid: Full rollout details that are not needed for pilot approval.
Suggested Length: 1 page.
Section: Pilot Goals and Success Criteria
Purpose: Make approval easier by defining how success will be judged.
Content to Include: Reduction in manual admin, improved onboarding visibility, user adoption, faster task completion, and stakeholder feedback.
Content to Avoid: Guaranteed revenue or retention promises unless supported by data.
Suggested Length: 0.5 to 1 page.
Section: Scope of Work
Purpose: Clarify exactly what is included in the pilot.
Content to Include: Workflow configuration, integration setup, onboarding templates, dashboard setup, training, and launch support.
Content to Avoid: Ambiguous phrases like full implementation or complete automation without detail.
Suggested Length: 1 to 2 pages.
Section: Implementation Plan and Timeline
Purpose: Reduce delivery uncertainty.
Content to Include: Milestones, kickoff, discovery, configuration, testing, training, go-live, pilot review, and dependencies.
Content to Avoid: Overly precise dates before stakeholder availability is confirmed.
Suggested Length: 1 page.
Section: Roles and Responsibilities
Purpose: Prevent delays and unclear ownership.
Content to Include: Seller responsibilities, buyer responsibilities, decision owners, access requirements, feedback timelines, and user participation.
Content to Avoid: One-sided responsibility language that makes delivery sound entirely vendor-controlled.
Suggested Length: 0.5 to 1 page.
Section: Risk Reduction and Assumptions
Purpose: Address concerns before they become objections.
Content to Include: Adoption support, phased rollout, success checkpoints, data readiness assumptions, and escalation process.
Content to Avoid: Defensive language or legal-heavy wording.
Suggested Length: 0.5 to 1 page.
Section: Proof and Relevant Examples
Purpose: Build confidence that the seller can deliver.
Content to Include: Similar customer examples, implementation experience, adoption proof, or relevant metrics if available.
Content to Avoid: Irrelevant logos or unsupported claims.
Suggested Length: 0.5 to 1 page.
Section: Investment
Purpose: Show pricing in context after value and scope are clear.
Content to Include: Pilot fee, implementation cost, subscription cost if applicable, payment timing, and what is included.
Content to Avoid: Leading with price before the buyer understands the business case.
Suggested Length: 0.5 page.
Section: Decision Path and Next Steps
Purpose: Make the next action obvious.
Content to Include: Approval step, target kickoff date, required signatories, internal review needs, and meeting CTA.
Content to Avoid: Vague endings like let us know what you think.
Suggested Length: 0.5 page.
Section: Appendix
Purpose: Provide detail for technical or operational evaluators without bloating the main proposal.
Content to Include: Feature details, integration notes, security summary, detailed assumptions, or sample dashboard fields.
Content to Avoid: Critical decision information that should be in the main proposal.
Suggested Length: As needed.
Simple Deal:
Use only executive summary, recommendation, scope, pricing, and next steps.
Mid-Complexity Deal:
Include implementation plan, success criteria, roles and responsibilities, and proof.
Enterprise Deal:
Add stakeholder alignment map, governance model, security appendix, technical architecture, procurement assumptions, legal notes, and business case.
Formal RFP:
Follow the buyer’s required format first, then add an executive summary and decision logic where allowed.
Renewal:
Add performance review, value delivered, adoption data, renewal scope, and expansion options.
Expansion:
Add current-state results, new use case, additional value drivers, implementation impact, and expansion pricing.
Pilot:
Add success criteria, pilot governance, pilot-to-rollout decision path, and exit criteria.
Scope should appear before pricing so the buyer understands what the investment includes. Pricing should come after the recommendation, value case, delivery plan, and risk reduction sections. This order helps finance and executives evaluate price in relation to business value and delivery confidence.
Do not bury scope in an appendix. The core pilot scope should be in the main body, with detailed technical requirements in the appendix.
Proof should appear before pricing or immediately after the recommendation. The purpose is to build confidence before the buyer evaluates investment.
Risk reduction should appear before investment and again briefly in the next steps. For this pilot proposal, use success criteria, phased rollout, adoption support, and milestone reviews as practical risk reducers.
Suggested note for the internal champion:
Team, sharing the proposed onboarding automation pilot for review. The proposal is focused on reducing manual onboarding coordination, improving visibility across active onboardings, and testing the workflow with a limited pilot before any full rollout decision. The key sections to review are the pilot scope, success criteria, implementation timeline, and investment. The proposed next step is an approval review to confirm whether we want to proceed with the pilot and target kickoff date.
Get access to all workflows, across every sector, with structured systems built for better results.