sales-proposal-page

撰写 Qwilr 提案页面

帮助用户撰写并构建 Qwilr 提案页面，涵盖从章节规划到文案撰写和交互元素配置的整个流程。Qwilr 用基于网页的交互式页面取代静态 PDF 提案，其中包含报价区块、嵌入式内容和实时互动跟踪。

第 1 步 — 收集背景信息

如果存在 references/learnings.md，请先阅读，了解积累的知识。

询问用户：

1. 你要提议什么？（产品／服务、范围、价格区间）
2. 买方是谁？（职位、公司、行业、公司规模）
3. 这笔交易进展到哪一步了？
   • A) 早期 — 他们正在评估各种方案
   • B) 中期 — 他们已经看过演示，现在需要正式提案
   • C) 后期 — 已口头同意，需要办理文书手续
   • D) 续约或扩展现有交易
4. 你想使用哪些 Qwilr 功能？
   • A) 带定价表的报价区块（交互式明细项，可选附加项）
   • B) 简单的文本型提案（不含交互式定价）
   • C) 完整的交易室，包含多个页面（如需此项，请转交：/sales-deal-room {your question}）
   • D) 不确定 — 请推荐合适的方案

如果用户的请求已提供大部分背景信息，请直接跳到相关步骤。 根据合理的假设，先尽力给出答案（并明确说明这些假设），然后只在末尾询问最关键的 1–2 个澄清问题；不要要求用户先补充完整背景信息才作答。

第 2 步 — 生成页面蓝图

设计按章节划分的页面结构，并对应到 Qwilr 区块类型。一个出色的 Qwilr 提案通常采用以下流程：

章节	Qwilr 区块类型	目的
封面／主视觉	Splash 区块	留下第一印象，展示潜在客户的姓名／Logo，以及一句话价值主张
执行摘要	文本 + 图片区块	说明这件事为何对他们尤其重要（最多 2–3 个段落）
问题与解决方案	文本区块或折叠面板	阐明痛点，并提出与其需求相匹配的解决方案
工作范围	文本区块或折叠面板	说明包含的内容、交付物和时间表
定价	报价区块	包含明细项的交互式定价表
时间表与里程碑	文本区块	关键日期、阶段和依赖项
关于我们／团队	文本 + 图片区块	展示可信度，包括相关团队成员和案例摘要
后续步骤／行动号召	接受区块	提出明确的行动号召 — 接受提案、签署或预约通话

根据交易背景调整此结构：

• 早期交易：重点突出问题／解决方案，减少详细工作范围的内容
• 后期交易：重点介绍工作范围和定价，减少问题阐述的内容
• 续约／扩展：先介绍已取得的成果，再说明扩展范围和定价。对扩展项目（新模块、附加项、额外席位）使用 Qwilr 的 isOptional: true，让买方可以自行选择是否在基础续约方案之外增加项目。这样既能让 CFO／预算负责人掌握主动权，也能降低追加销售的阻力。
• 技术买方：添加技术架构或集成章节
• 高管买方：添加 ROI／商业论证章节

步骤 3 — 撰写文案

为每个部分撰写实际文案，不要只放占位符。请遵循以下原则：

• 执行摘要：最多写 2–3 段。先讲客户的问题，而不是你的产品。提及客户情况中的具体内容（公司名称、他们提到的目标、在需求沟通中发现的痛点）。
• 问题与解决方案：沿用客户的表达方式。将每个痛点对应到一项具体能力。
• 范围：明确列出交付物，详细程度要足以让双方清楚什么才算“完成”，但不要写得像合同。
• 定价文案：撰写报价区块上方的引导文字——在客户看到数字前，先说明价值。
• 行动号召：具体说明客户接受后会发生什么（例如，48 小时内召开启动会议、在 X 周开始实施等）。

对于用户以后可能想通过 Qwilr API 自动填充的字段，请使用 {{token}} 语法（例如，{{company_name}}、{{contact_first_name}}、{{deal_amount}}）。

步骤 4 — 配置交互元素

如果提案包含报价区块，请设计定价结构：

报价区块配置

• 分组：按逻辑对项目分组（例如，“平台许可证”“实施”“附加项”）
• 项目：每个项目都需要名称、说明和价格
  • 大多数项目使用 fixedCost 类型
  • 将附加项标记为 isOptional: true，以便买方选择是否添加
  • 对买方可选择数量的项目（席位、单位）设置 quantity 范围
  • 适当应用折扣（百分比或固定金额）
• 计费：为每个项目指定 oneOff 或 recurring（按月／季度／年）
• 税费：如适用，包含税费配置

可考虑的交互功能

• 可选项目：让买方自行选择附加项——这样既能提高交易金额，也能让买方掌握主动权
• 数量选择器：对于按席位或按单位计价的项目，让买方调整数量
• 折扣显示：清楚展示折扣，突出买方获得的优惠
• 分组小计：帮助买方了解各类别的费用明细
• 功能列表：在项目中添加功能说明，提供背景信息

步骤 5 — 生成 API 负载（可选）

如果用户想通过 Qwilr API 以编程方式创建页面，请生成包含区块、令牌和报价分组的 POST /pages JSON 负载。完整的负载结构、字段参考和端点列表请参见 references/qwilr-api-proposals.md。

要点：

• 先运行 GET /blocks/saved，查找可用的区块 ID
• 将 isPublished: false 设为未发布状态，以便先审核再发送
• 使用 tokens 将 CRM 数据替换到 {{token}} 占位符中
• 配置报价分组，包含项目、可选附加项和计费频率

注意事项

• 不要生成大段文字。 Qwilr 是一个可视化的 Web 平台，不是 Word 文档。使用 Qwilr 的区块类型（Splash、Accordion、Quote 区块）拆分内容。如果某个部分超过 3 段，请将其重组为 Accordion，或拆分为几个小节。

• 别忘了交互式定价／报价区块。 Claude 默认会将定价写成纯文本。Qwilr 的 Quote 区块是产品的关键差异化功能，任何包含定价的提案都应使用它。配置明细项、可选附加项和数量选择器。

• 别跳过 CTA。 每份提案都需要使用 Qwilr 的 Accept 区块设置明确的行动号召。不要以“欢迎告诉我们您的想法”结尾，而应以“接受此提案”或“预约项目启动会议”结尾。

• 不要让提案太长。 Web 提案不是 PDF。买家通常会略读。优秀的 Qwilr 提案包含 5-8 个部分。如果内容更长，可以考虑将详细内容移至交易室（/sales-deal-room）。

• 别忘了 {{token}} 占位符。 如果提案日后可能通过 API 自动生成，请在全文中使用 {{company_name}}、{{contact_first_name}} 等占位符，而不是硬编码具体值。

• 持续改进：如果发现此处未涵盖的内容，请将其附加到 references/learnings.md，并注明今天的日期。

示例

示例 1：处于后期阶段、包含交互式定价的 SaaS 提案

用户说：“我需要为 Acme Corp 准备一份 Qwilr 提案——对方口头上已经同意，分析平台的价格为每年 $48k，另有可选的入门服务包。对方是一家中型金融科技公司，买方是他们的数据副总裁。”

技能执行：

1. 识别出这是后期阶段的交易——以范围和定价为重点，简要介绍问题背景。
2. 制定页面蓝图：以包含 Acme 名称的 Splash 封面开篇，接着是围绕其数据目标撰写的简短执行摘要、精炼的工作范围，然后是 Quote 区块。
3. 撰写各部分文案，包括 Quote 区块上方用于凸显价值的引导文字。
4. 配置 Quote 区块：设置一个名为“平台许可”的部分，价格为每年 $48k，按年度 recurring 计费；再添加一个名为“入门服务”的明细项，并标记为 isOptional: true，让数据副总裁可以自行选择。
5. 以 Accept 区块 CTA 收尾，并注明项目启动时间安排。

结果：一份包含 5 个部分的 Qwilr 页面，配有可由买方选择的交互式定价表格，以及清晰的接受并签署 CTA，可直接粘贴到 Qwilr 或通过 API 推送。

示例 2：处于早期阶段的交易，从空白页面开始

用户说：“我正对着一个空白的 Qwilr 页面发愁。一家营销机构要向一家仍在比较供应商的电商初创公司推介品牌焕新服务。预算大约为 $20k。”

技能执行：

1. 识别出这是早期阶段的交易——将结构重点放在问题／解决方案上，减少详细范围说明。
2. 提出一份蓝图：从买方的痛点切入，将每个痛点对应到一项能力，并使用 Accordion 让解决方案一目了然。
3. 起草执行摘要以及问题与解决方案文案，并贴合买方的表达方式。
4. 添加一个简单的 Quote 区块，列出 $20k 的项目费用和一个可选附加项，然后添加 Accept 区块 CTA。

结果：一份有说服力、便于略读的提案结构，包含实际文案，先阐明问题，再呈现价格。

示例 3：通过 API 进行续约并追加扩容销售

用户说：“生成续约用的 Qwilr API 负载——基础费用为 30,000 美元，另有三个可选扩容模块，每个 5,000 美元。我会从 HubSpot 自动填入公司名称。”

技能执行：

1. 将其视为续约／扩容场景——先介绍已取得的成果，再说明扩容范围。
2. 在文案中使用 {{company_name}} 和 {{contact_first_name}} 令牌占位符。
3. 提示先运行 GET /blocks/saved 查找区块 ID，然后构建 isPublished: false 的 POST /pages 负载。
4. 配置报价部分：包含一个基础续约条目，以及三个均设为 isOptional: true 的扩容模块。
5. 映射 tokens，使 HubSpot 数据替换 {{...}} 占位符。

结果：生成可直接发送的 JSON 负载（参见 references/qwilr-api-proposals.md），用于创建未发布、由令牌驱动的续约页面，并允许客户自行选择扩容追加项。

故障排除

生成的提案读起来像一大段文字或 Word 文档

原因：文案写成了长篇散文，没有映射到 Qwilr 区块类型，因此忽略了该平台基于网页的视觉呈现形式。

解决方案：将任何超过 3 段的部分重组为 Accordion，或拆分成多个小节，并将内容映射到 Splash、Text+Image 和 Quote 区块。总共以 5-8 个部分为宜；将多余的细节移至交易室（/sales-deal-room）。

价格显示为纯文本，而不是可交互的报价

原因：Claude 默认将价格写成文本表格，跳过了 Qwilr 的 Quote 区块——这是其关键差异化功能。

解决方案：将所有带价格的提案移至 Quote 区块。将条目分组到不同部分，将附加项标记为 isOptional: true，为按席位定价设置 quantity 范围，并为每个条目指定 oneOff 或 recurring 计费方式。

创建页面的 API 调用失败，或引用了未知的区块 ID

原因：构建 POST /pages 负载前，没有先查找可用的已保存区块 ID；或者页面立即发布，没有审核步骤。

解决方案：先运行 GET /blocks/saved 获取有效的区块 ID，再构建负载；设置 isPublished: false，以便发送前审核页面；并确认 tokens 与文案中的 {{token}} 占位符相匹配。完整字段说明请参阅 references/qwilr-api-proposals.md。

推荐特定平台技能之前

此技能涵盖跨多个平台的策略领域。在向用户推荐任何特定平台技能之前（即 ## Related skills 中列出的任何 /sales-{platform}，例如 /sales-mailshake、/sales-klaviyo、/sales-apollo），请先阅读该平台技能的实际 SKILL.md。## Related skills 中的一行描述足以识别候选项，但不足以据此确定推荐，也不足以编写能有效调用该技能的提示词。

阅读方法：

• 如果本地存在 ~/.claude/skills/{skill-name}/SKILL.md，请使用 Read 阅读。
• 对于 sales-* 技能，请从此仓库直接使用 WebFetch 获取：https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md——例如，对于 sales-mailshake：https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md。
• 对于非 sales-* 技能（第三方技能），如果已安装，请在 ~/.claude/skills/sales-do/references/skill-sources.md 中查找 {org}/{repo}，并从该仓库下相同的 skills/{skill-name}/SKILL.md 路径获取。

**阅读后，**请根据 SKILL.md 中的具体内容（其范围、子流程、argument-hint 格式，或“Do NOT use for...”负面触发条件）来提出建议。生成的调用应符合平台技能的 argument-hint。如果平台技能不适合用户的情况，请改用其他技能，或直接在此处处理问题，而不要推荐不合适的技能。

相关技能

• /sales-proposal-analytics — 发送后跟踪互动情况（谁查看了、查看了哪些章节，以及何时跟进）
• /sales-qwilr-automation — 通过 Qwilr API 根据 CRM 数据自动创建提案
• /sales-deal-room — 适用于需要多个页面的复杂多方利益相关者交易
• /sales-proposal-template — 为整个团队设计可复用的模板
• /sales-do — 不确定该使用哪项技能？该路由器会根据销售目标匹配合适的技能。安装：npx skills add sales-skills/sales --skill sales-do