sales-skills/sales-proposal-page

Write a Qwilr Proposal Page

Help the user write and structure a Qwilr proposal page — from section planning through copy and interactive element configuration. Qwilr replaces static PDF proposals with interactive web-based pages that include quote blocks, embedded content, and real-time engagement tracking.

Step 1 — Gather context

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

Ask the user:

1. What are you proposing? (product/service, scope, price range)
2. Who is the buyer? (title, company, industry, company size)
3. Where is this deal?
   • A) Early — they're evaluating options
   • B) Mid — they've seen a demo, now need a formal proposal
   • C) Late — verbal yes, need the paperwork
   • D) Renewal or expansion of existing deal
4. Which Qwilr features do you want to use?
   • A) Quote block with pricing table (interactive line items, optional add-ons)
   • B) Simple text-based proposal (no interactive pricing)
   • C) Full deal room with multiple pages (for instead, hand off: /sales-deal-room {your question})
   • D) Not sure — recommend what fits

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 — Generate page blueprint

Design a section-by-section page structure mapped to Qwilr block types. A strong Qwilr proposal typically follows this flow:

| Section | Qwilr Block Type | Purpose | |---|---|---| | Cover / Hero | Splash block | First impression, prospect's name/logo, one-line value prop | | Executive Summary | Text + Image block | Why this matters to them specifically (2-3 paragraphs max) | | Problem & Solution | Text block or Accordion | Frame the pain, present your solution mapped to their needs | | Scope of Work | Text block or Accordion | What's included, deliverables, timeline | | Pricing | Quote block | Interactive pricing table with line items | | Timeline & Milestones | Text block | Key dates, phases, dependencies | | About Us / Team | Text + Image block | Credibility — relevant team members, case study snippets | | Next Steps / CTA | Accept block | Clear call to action — accept the proposal, sign, or book a call |

Adapt this structure based on the deal context:

• Early-stage deals: Lead heavier on problem/solution, lighter on detailed scope
• Late-stage deals: Lead with scope and pricing, lighter on problem framing
• Renewals/expansions: Lead with results achieved, then expansion scope and pricing. Use Qwilr's isOptional: true on expansion line items (new modules, add-ons, additional seats) so the buyer can self-select what to add beyond the base renewal. This gives the CFO/budget holder control while making the upsell frictionless.
• Technical buyers: Add a technical architecture or integration section
• Executive buyers: Add an ROI/business case section

Step 3 — Write the copy

Write actual copy for each section, not just placeholders. Follow these principles:

• Executive Summary: 2-3 paragraphs max. Lead with their problem, not your product. Reference specific things from their situation (company name, goals they mentioned, pain points from discovery).
• Problem & Solution: Mirror their language back to them. Map each pain point to a specific capability.
• Scope: Use clear deliverables with enough detail that both sides know what "done" looks like, but not so much that it reads like a contract.
• Pricing copy: Write the framing text above the quote block — this is where you anchor value before they see numbers.
• CTA: Be specific about what happens after they accept (kickoff call within 48 hours, implementation begins week of X, etc.).

Use {{token}} syntax for any fields the user might want to auto-populate via the Qwilr API later (e.g., {{company_name}}, {{contact_first_name}}, {{deal_amount}}).

Step 4 — Configure interactive elements

If the proposal includes a quote block, design the pricing structure:

Quote block configuration

• Sections: Group line items logically (e.g., "Platform License", "Implementation", "Add-Ons")
• Line items: Each item needs a name, description, and price
  • Use fixedCost type for most items
  • Mark add-ons as isOptional: true so the buyer can select/deselect
  • Set quantity ranges where buyers should choose volume (seats, units)
  • Apply discounts where appropriate (percentage or fixed amount)
• Billing: Specify oneOff or recurring (monthly/quarterly/annual) per item
• Tax: Include tax configuration if applicable

Interactive features to consider

• Optional line items: Let buyers self-select add-ons — this increases deal size while giving them control
• Quantity selectors: For per-seat or per-unit pricing, let buyers adjust quantity
• Discount display: Show the discount visibly to reinforce the deal they're getting
• Section subtotals: Help buyers understand cost breakdown by category
• Features lists: Add feature descriptions to line items for context

Step 5 — Generate API payload (optional)

If the user wants to create the page programmatically via the Qwilr API, generate a POST /pages JSON payload with blocks, tokens, and quote sections. See references/qwilr-api-proposals.md for the full payload structure, field reference, and endpoint list.

Key points:

• Run GET /blocks/saved first to discover available block IDs
• Set isPublished: false to review before sending
• Use tokens to substitute CRM data into {{token}} placeholders
• Configure quote sections with line items, optional add-ons, and billing frequency

Gotchas

• Don't generate walls of text. Qwilr is a visual, web-based platform — not a Word doc. Use Qwilr block types (Splash, Accordion, Quote blocks) to break up content. If a section runs longer than 3 paragraphs, restructure it into an Accordion or split it into sub-sections.

• Don't forget the interactive pricing/quote block. Claude defaults to writing pricing as plain text. Qwilr's quote block is the product's key differentiator — use it for any proposal that includes pricing. Configure line items, optional add-ons, and quantity selectors.

• Don't skip the CTA. Every proposal needs a clear call to action using Qwilr's Accept block. Don't end with "let us know your thoughts" — end with "Accept this proposal" or "Book your kickoff call."

• Don't make the proposal too long. Web proposals are not PDFs. Buyers skim. A strong Qwilr proposal is 5-8 sections. If it's longer, consider moving detailed content to a deal room (/sales-deal-room) instead.

• Don't forget {{token}} placeholders. If the proposal might be auto-generated via API later, use {{company_name}}, {{contact_first_name}}, etc. throughout — not hardcoded values.

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

Examples

Example 1: Late-stage SaaS proposal with interactive pricing

User says: "I need a Qwilr proposal for Acme Corp — verbal yes already, $48k/yr for our analytics platform plus an optional onboarding package. Mid-size fintech, buyer is their VP of Data."

Skill does:

1. Recognizes a Late-stage deal — leads with scope and pricing, keeps problem framing light.
2. Builds a page blueprint: Splash cover with Acme's name, a short Executive Summary tied to their data goals, a concise Scope of Work, then a Quote block.
3. Writes the section copy, including the value-anchoring framing text above the quote block.
4. Configures the quote block: a "Platform License" section at $48k/yr billed recurring annual, plus an "Onboarding" line item marked isOptional: true so the VP can self-select it.
5. Closes with an Accept block CTA naming the kickoff timeline.

Result: A 5-section Qwilr page with an interactive, buyer-selectable pricing table and a clear accept-to-sign CTA — ready to paste into Qwilr or push via the API.

Example 2: Early-stage deal, blank page

User says: "I'm staring at a blank Qwilr page. Marketing agency pitching a brand refresh to an e-commerce startup that's still comparing vendors. Around $20k."

Skill does:

1. Identifies an Early-stage deal — weights the structure toward problem/solution, lighter on detailed scope.
2. Proposes a blueprint that opens with the buyer's pain, maps each pain point to a capability, and uses an Accordion to keep the solution scannable.
3. Drafts the Executive Summary and Problem & Solution copy mirroring the prospect's language.
4. Adds a simple Quote block with the $20k engagement and one optional add-on, then an Accept block CTA.

Result: A persuasive, skimmable proposal structure with real copy that frames the problem before the price.

Example 3: Renewal with expansion upsell via the API

User says: "Generate the Qwilr API payload for a renewal — base $30k, plus three optional expansion modules at $5k each. I'll auto-fill the company name from HubSpot."

Skill does:

1. Treats it as a Renewal/expansion — leads with results achieved, then expansion scope.
2. Uses {{company_name}} and {{contact_first_name}} token placeholders throughout the copy.
3. Notes that GET /blocks/saved should run first to discover block IDs, then builds a POST /pages payload with isPublished: false.
4. Configures quote sections: a base renewal line item plus three expansion modules each set isOptional: true.
5. Maps tokens so HubSpot data substitutes into the {{...}} placeholders.

Result: A ready-to-send JSON payload (per references/qwilr-api-proposals.md) that creates an unpublished, token-driven renewal page with self-select expansion upsells.

Troubleshooting

The generated proposal reads like a wall of text or a Word doc

Cause: Copy was written as long prose instead of being mapped to Qwilr block types, so it ignores the platform's visual, web-based format.

Solution: Restructure any section longer than 3 paragraphs into an Accordion or split it into sub-sections, and map content to Splash, Text+Image, and Quote blocks. Aim for 5-8 sections total; move overflow detail to a deal room (/sales-deal-room).

Pricing rendered as plain text instead of an interactive quote

Cause: Claude defaults to writing pricing as a text table, skipping Qwilr's quote block — its key differentiator.

Solution: Move any priced proposal into a Quote block. Group line items into sections, mark add-ons isOptional: true, set quantity ranges for per-seat pricing, and specify oneOff vs recurring billing per item.

API call to create the page fails or references unknown block IDs

Cause: The POST /pages payload was built without first discovering the available saved block IDs, or it published immediately with no review step.

Solution: Run GET /blocks/saved to retrieve valid block IDs before composing the payload, set isPublished: false so the page can be reviewed before sending, and confirm tokens match the {{token}} placeholders in the copy. See references/qwilr-api-proposals.md for the full field reference.

Before recommending a specific platform skill

This skill covers a strategy domain across many platforms. Before pointing the user to any specific platform skill (any /sales-{platform} listed in ## Related skills, e.g., /sales-mailshake, /sales-klaviyo, /sales-apollo), read that platform skill's actual SKILL.md first. The 1-line description in ## Related skills is enough to identify a candidate — it's not enough to commit to it or to write a prompt that invokes it well.

How to read it:

• If ~/.claude/skills/{skill-name}/SKILL.md exists locally, Read it.
• For sales-* skills, WebFetch directly from this repo: https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md — e.g., for sales-mailshake: https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md.
• For non-sales-* skills (third-party), look up {org}/{repo} in ~/.claude/skills/sales-do/references/skill-sources.md if installed and fetch the same skills/{skill-name}/SKILL.md path under that repo.

After reading, ground your recommendation in something concrete from the SKILL.md (its scope, a sub-flow, its argument-hint shape, or a "Do NOT use for..." negative trigger). Align any generated invocation with the platform skill's argument-hint. If the platform skill turns out not to fit the user's situation, swap to another or handle the question here directly rather than recommending a poor fit.

Related skills

• /sales-proposal-analytics — Track engagement after sending (who viewed, which sections, when to follow up)
• /sales-qwilr-automation — Automate proposal creation from CRM data via the Qwilr API
• /sales-deal-room — For complex multi-stakeholder deals that need multiple pages
• /sales-proposal-template — Design reusable templates for your whole team
• /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