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

1. 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:

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.

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-proposal — For general (non-Qwilr) proposal strategy and pricing
• /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