客户成交提案与报价方案

客户成交提案与报价方案解决什么问题

在 B2B 销售周期中，手动拼凑一份「买方可直接阅读」的提案文档往往非常痛苦。团队通常需要从 ROI 计算表、产品定价 PDF、客户案例库和实施排期表里捞取信息，再手工缝合成一份 Word 或 PDF。这不仅耗时，还容易出现口径不一致——比如 ROI 假设和报价单脱节，或者执行摘要写成了枯燥的产品功能列表，没能打动真正的经济买家。

该技能的目标是把这件事结构化、自动化。它不像普通文案工具那样直接润色，而是扮演一个懂业务的销售工程师角色，确保输出的每一份提案都逻辑自洽、数据可追溯。

核心机制：Deal 的工作流

该技能（规范名 @user_fccf428b/deal-proposal）内置了一套严格的 Steps 工作流，强制在写第一个字之前先完成上下文对齐：

• 背景收集 (Step 0)：在动笔前，技能会主动询问缺失的输入信息，包括潜在客户公司、规模、行业、核心痛点、关键利益相关者、评估中的竞品以及相关客户案例。它还会扫描仓库中现有的定价材料以保持一致性。
• 价值框架 (Step 1)：撰写执行摘要。要求仅限 3 句话回答：买方有什么问题？我们如何解决？预期结果是什么？禁止使用产品功能语言，必须使用业务结果语言。
• 问题与解决方案映射 (Step 2 & Step 3)：具体化买方痛点（现状、不行动的成本、为什么是现在），并通过表格将买方需求、产品能力与证据进行一一对应。
• 财务与时间规划 (Step 4-6)：生成报价表、实施时间线和 ROI 模型。如果缺乏硬数据，必须使用范围值并明确引用假设，杜绝编造数据。
• 收尾与交付 (Step 7)：以清晰的下一步行动结束，确保 Champion（内部支持者）可以在没有你在场的情况下，直接将文档分享到公司内部。

适用边界与工程注意事项

该技能的输出格式受 docs/output-kit.md 严格约束，采用框线图骨架和压缩文本风格。

一个重要的工程约束是行数限制：设计目标是 40 行 CLI 输出。如果提案内容超过 40 行，技能会自动将完整提案作为附件，并委派给 /atlas-report 处理。这意味着它更适合生成结构紧凑的执行摘要级提案，而非数百页的标书。

此外，技能依赖你提供高质量的输入（如真实的竞品名称、具体的业务痛点）。如果你只丢给它一句“帮我写个报价”，它虽然能生成文档，但很难保证 ROI 模型的说服力。它的最佳实践是配合 Agent 在完整的调研上下文中运行。