sales-skills/sales-proposal-template

Design Reusable Qwilr Proposal Templates

Help the user design a system of reusable Qwilr templates that their whole sales team can use — with standardized structure, consistent branding, and token-ready fields for API/CRM auto-population.

Step 1 — Gather context

If references/learnings.md exists, read it first for accumulated knowledge.

Ask the user:

1. What does your team sell?

   • Product/service description, typical deal sizes, buyer personas

2. How many distinct deal types do you have?

   • A) One product, one buyer type — just need one template
   • B) 2-3 variations (e.g., SMB vs. enterprise, or different products)
   • C) 4+ variations (verticals, regions, product lines)
   • D) Not sure — help me figure it out

3. What's broken with proposals today?

   • A) Every rep builds from scratch — inconsistent quality
   • B) We have templates but they're outdated or hard to customize
   • C) Proposals take too long to create
   • D) Pricing is presented inconsistently
   • E) We're starting fresh — no templates exist yet

4. How do you want reps to use these templates?

   • A) Manually in Qwilr — pick a template, customize, send
   • B) Auto-generated from CRM data via API
   • C) Both — auto-generated with manual customization
   • D) Not sure — what do you recommend?

If the user's request already provides most of this context, skip directly to the relevant step. Lead with your best-effort answer using reasonable assumptions (stated explicitly), then ask only the most critical 1-2 clarifying questions at the end — don't gate your response behind gathering complete context.

Step 2 — Template strategy

Based on the context, design the template system:

How many templates do you need?

Use the minimum number of templates that covers your deal types. A good rule of thumb:

| Scenario | Templates needed | |---|---| | One product, one buyer | 1 master template | | One product, SMB + Enterprise buyers | 2 templates (different depth/formality) | | Multiple products, same buyer | 1 template per product | | Multiple products + buyer segments | Matrix — but cap at 5-6 and use conditional sections |

Fixed vs. variable sections

Every template should have:

Fixed sections (same across all proposals):

• Company intro / "About Us" — consistent brand story
• Team / contact section — auto-populated per rep
• Legal / terms section — standard terms, rarely changed
• CTA / acceptance section — standard accept flow

Variable sections (customized per deal):

• Executive summary — tailored to each prospect's situation
• Problem/solution framing — adapted to the buyer's pain points
• Scope of work — specific to the deal
• Pricing / quote block — deal-specific line items and amounts

Conditionally included sections (used for some deals, not others):

• Case studies — pick the one most relevant to the prospect's industry
• Technical architecture — only for technical buyers
• ROI / business case — only for enterprise or executive buyers
• Security & compliance — only when procurement requires it

Step 3 — Template blueprints, token design, and rollout

Read references/template-guide.md for the full build reference — the per-template blueprint format (a section-by-section Fixed / Variable / Conditional table), fill-in-the-blank copy frameworks for the variable sections (executive summary, problem/solution), the standard + custom substitution-token catalog for CRM auto-population with per-token team guidelines, and the asset-library + team-rollout plan.

Walk the user through it in order:

1. Blueprint each section as fixed, variable, or conditional — fixed content is reused verbatim, variable content is customized per deal.
2. Give reps copy frameworks, not blank boxes for the variable sections (an executive-summary and problem/solution fill-in template) so quality stays consistent.
3. Design auto-populated CRM tokens (company, contact, rep, deal amount) with sensible fallback defaults so a raw {{token}} never leaks to the buyer; keep judgement-heavy sections manual.
4. Build a supporting asset library — case studies tagged by industry, headshots, logos, pricing presets.
5. Roll out: build → document a one-pager per template → train in a short live session → test with 2-3 reps → iterate on engagement data (/sales-proposal-analytics) → automate CRM auto-generation (/sales-qwilr-automation).

Gotchas

• Don't make templates too rigid. Templates should give reps a strong starting point, not a straitjacket. If reps can't easily customize the executive summary, scope, and pricing for their specific deal, they'll stop using the template. Use fill-in-the-blank frameworks, not fixed copy.

• Don't forget variable placeholders. Every template should use {{token}} syntax for fields that will be auto-populated (company name, contact info, rep info, deal amount). Claude sometimes writes templates with hardcoded example values instead of tokens.

• Don't design for one deal type when the team handles multiple. Ask how many distinct deal types exist before building templates. A single template for "SMB SaaS" and "Enterprise Financial Services" will serve neither well. But also don't over-segment — most teams need 2-4 templates, not 15.

• Don't forget mobile responsiveness. Qwilr pages are web-based and will be viewed on phones and tablets. Avoid designs that depend on side-by-side layouts or wide tables that break on small screens. Test the template on mobile before rolling out.

• Don't create templates without a rollout plan. A great template that reps don't know about or don't know how to use is wasted effort. Always include guidance on when to use each template and how to customize the variable sections.

• Self-improving: If you discover something not covered here, append it to references/learnings.md with today's date.

Examples

Example 1: Two-template system for SMB vs. Enterprise

User says: "Every rep on my team builds proposals from scratch and they all look different. We sell a SaaS platform to both small businesses and big enterprises. Help me build templates the whole team can reuse."

Skill does:

1. Gathers context — confirms one product, two distinct buyer types (SMB, Enterprise), and that the core problem is inconsistent rep-built proposals.
2. Recommends 2 templates (not 1, not 15): an SMB template that's shorter and more direct, and an Enterprise template with added ROI/business-case and security/compliance conditional sections.
3. Produces a blueprint table per template — Cover (Splash, variable), Executive Summary (Text, variable with a fill-in-the-blank framework), Pricing (Quote block, variable), About Us (Fixed), Team (auto-populated via {{rep_name}}), Next Steps (Accept block, fixed).
4. Adds copy frameworks so the variable Executive Summary and Problem/Solution sections give reps a strong starting point instead of a blank page.
5. Lays out the 6-step rollout: build with saved blocks, document a one-pager per template, train in a 30-min session, test with 2-3 reps, iterate, then automate.

Result: Two reusable Qwilr templates with standardized structure, consistent branding, token-ready fields, and a rollout plan — reps stop building from scratch and proposals look consistent across the team.

Example 2: Token design for CRM auto-population

User says: "We already have a Qwilr template but reps still hand-type the company name, contact, and pricing every time. I want to wire it to our CRM so it auto-fills."

Skill does:

1. Maps the standard token set to CRM fields — {{company_name}}, {{contact_first_name}}, {{rep_name}}, {{deal_amount}}, {{close_date}} — and flags these as "always auto-populate, never manual."
2. Adds deal-type custom tokens like {{industry}}, {{seat_count}}, and {{pain_point}}, tagging which are semi-auto (verify) vs. always-manual (human judgment).
3. Recommends fallback/default values so an empty CRM field never renders raw {{token}} text on the live page.
4. Hands off the actual CRM-to-Qwilr wiring to /sales-qwilr-automation, since template design and automation plumbing are separate jobs.

Result: A token map the team can drop into their template, with clear rules for what auto-fills vs. what reps must write — eliminating hand-typed fields and raw-token bugs.

Example 3: Starting from zero with vertical-specific templates

User says: "We're a brand-new sales team, no templates at all. We sell into healthcare, fintech, and retail and each vertical cares about different things."

Skill does:

1. Identifies 3+ deal-type variations but caps template count at 5-6, recommending one base template plus conditional sections rather than three fully separate templates.
2. Defines fixed sections (About Us, legal terms, acceptance flow) once, then per-vertical conditional sections — security & compliance for healthcare/fintech, a retail-relevant case study from the case-study library.
3. Recommends an asset library to build alongside: 3-5 case studies tagged by industry, a headshot library, customer logos, and quote-block presets.
4. Provides copy frameworks tailored so each vertical's Problem/Solution section speaks to that industry's pain points via {{industry}} and {{pain_point}} tokens.

Result: A single maintainable template family that flexes across three verticals through conditional sections and a tagged asset library — without the maintenance burden of fifteen one-off templates.

Troubleshooting

Reps ignore the new templates and keep building from scratch

Cause: The templates are too rigid — reps can't easily customize the executive summary, scope, or pricing for their specific deal, so it's faster to start over than to fight the template.

Solution: Loosen the variable sections. Replace any fixed copy in the Executive Summary, Scope, and Pricing with fill-in-the-blank frameworks that give reps a strong starting point they can edit. Keep only genuinely standard content (About Us, terms, acceptance flow) locked as fixed.

The live proposal shows raw {{token}} text to the prospect

Cause: A token references a CRM field that's empty for that deal, and no fallback/default value was set, so the placeholder renders literally on the page.

Solution: Set sensible default values for every optional token so an empty field degrades gracefully instead of leaking {{token}} syntax. Reserve auto-population strictly for fields that are reliably present (company name, contact, rep info, deal amount) and mark the rest as semi-auto so reps verify before sending.

Too many templates and no one knows which to use

Cause: The system was over-segmented — a separate template per product/buyer/region combination — so reps can't tell which one applies and adoption collapses.

Solution: Cap the count at 5-6. Collapse near-duplicate templates into one base template with conditional sections, and document a clear "Use when" line per template so reps can pick the right one in seconds. Most teams need 2-4 templates, not fifteen.

Related skills

• /sales-proposal-page — Write a single proposal from scratch (not from template)
• /sales-qwilr-automation — Connect templates to CRM for auto-generation
• /sales-proposal-analytics — Track which templates get the best engagement
• /sales-deal-room — Design multi-page deal rooms (may need their own templates)
• /sales-content — General sales enablement content creation
• /sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do