build-business-case

构建商业论证

将零散的客户证据转化为以客户为核心、可用于决策的价值论证。本技能负责商业论证的逻辑与草拟；它不是通用的产品定位、演示文稿设计工作流，也不是回写工作流。

从客户出发，而非从产品出发。每次运行都遵循以下链条：

客户背景 -> 账户原生锚点 -> 工作流 -> 用例 -> 价值驱动因素 -> 指标 -> 量化影响 -> 叙述 -> 适用时进行公开资料调研

如果证据不足以支撑可信的计算结果，就提供明确标注的结构性论证，并列出使其达到财务审核要求所需的最精简验证计划。

通用技能说明

强制要求：如果尚未纳入上下文，请阅读并严格遵循 plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices。

关键依赖类别

仅使用能实质性提升论证质量的途径。

• [阻塞项] ~~CRM，用于获取权威的账户、商机、负责人、阶段、金额、成交时间、联系人和商务背景信息。除非权威账户和商务背景信息已有依据，否则这会阻止生成特定客户／账户的论证；通用场景论证可以不依赖它。
• ~~会议记录，用于获取探索阶段的证据、利益相关者的表述、工作流痛点、异议、量化主张、决策和验证缺口
• ~~知识与文件，用于获取账户计划、资料包、探索笔记、以往的价值论证、证明材料和账户原生指标
• ~~销售情报，仅在公司、匹配度、利益相关者或市场背景能弥补具体证据缺口时使用

仅当公开资料调研能强化战略重点、高管表述、运营压力或“为何是现在”时才使用。优先选择由公司控制的资料、投资者资料、监管资料和其他一手来源。绝不能让公开资料或信息补充内容取代客户确认的痛点、工作流指标、决策流程或由 CRM 维护的权威信息。

参考资料加载

SKILL.md 负责常规的客户优先流程、证据顺序、注意事项和默认材料包。只有在额外细节确有必要时才加载参考资料：

• 当输入零散、用户指定了输出模式，或需要了解完整的必需内容要求时，使用 references/input-and-output.md。
• 当复杂论证需要扩展版的客户到价值流程及示例时，使用 references/workflow.md。
• 当量化、置信度标注、证据冲突或价值类别逻辑需要更多细节时，使用 references/value-model-and-evidence.md。
• 仅当需要格式化材料、精确的演示文稿／输出要求或行为测试时，使用 references/output-and-presentation.md。

工作流指南

1. 确定客户和决策锚点

• 必须指定客户／账户／场景，以及工作流、计划、痛点、指标目标或决策背景。只要信息足够，可根据粘贴的笔记、链接、导出内容或锚点明确的对话线程继续处理。
• 如果推断出的必需锚点存在歧义，最多读取三个来源，进行范围受限的检索，提供最多五个具体候选项，并在广泛补充信息之前请用户选择。
• 将类似公司名称的名称视为可能的账户锚点。如果有 ~~CRM 可用，在依赖间接背景信息前，先确定账户和匹配的商机。
• 如果客户和工作流两者都太模糊，无法形成稳定假设，则只提出最精简的澄清问题。

2. 优先寻找账户原生依据

• 从用户提供的指标、笔记、链接或导出数据入手。否则，在广泛搜索前，先寻找信号最强的账户原生资料：在 ~~Knowledge & Files 中精确匹配查询，例如 [customer] business case、value case、ROI、pilot target 或 expansion path；然后查找匹配的 ~~CRM 商机；再查找相关的 ~~Meeting Transcripts。
• 优先获取最有力的依据。信号强的资料会包含具名客户、工作流、决策受众、商业利害、指标、紧迫性或注意事项。
• 仅在需要验证工作流痛点、审批路径、预算归属、时间安排、风险或面向客户的后续跟进等重要缺口时，才查阅相关来源。
• 保留账户原生证据中的商业依据，包括试点金额、扩展路径、目标价值、预算范围、成交时间和付费试点条款。如果 CRM 信息不完整，应保留有来源支持的事实，并单独指出 CRM 缺口。
  • 示例：已从 ~~Knowledge & Files 来源资料包确认：试点目标为 SGD 420K，扩展路径为 SGD 1.8M。~~CRM 中缺少：商机阶段、负责人和成交日期。
• 一旦核心论据得到支持，就结束第一轮搜索；不要仅因还有其他来源，就继续进行低收益搜索。
• 对于具名上市公司，除非用户禁用了此操作，或账户原生依据已回答重要的“为何是现在”问题，否则应进行有针对性的公开一手资料检索。用其强化战略重点和高管措辞，但绝不要因此延迟形成第一个有用的论据，也不要用它取代账户原生证据。

3. 构建客户价值逻辑

• 在介绍卖方能力前，先说明客户目标、业务压力、相关买方或团队、限制条件以及实际工作流。
• 用业务语言描述工作流：参与者、步骤、交接、瓶颈、工具、关键绩效指标，以及理想结果。
• 优先选择一至三个用例。对每个用例，说明工作流问题、问题为何当下重要、谁关注、支持证据以及仍需验证的内容。
• 将每个用例对应到适用的最少几个价值类别：Enhanced Productivity、Cost Reduction、Risk Reduction、Revenue Acceleration 和 Time to Market。
• 明确呈现因果链：工作流变更 -> 运营影响 -> 业务成果 -> 指标。

4. 只量化证据能够支持的内容

• 将重要主张和输入标记为 Known、Inferred、Assumed 或 Missing。
• 来源相互冲突时，按以下顺序采用证据：客户提供的指标；产品遥测数据或使用数据；需求发现或会议记录证据；~~CRM、~~Knowledge & Files 或内部账户笔记；公开一手资料；类似成功案例或方向性基准。
• 对于可供财务评估的论据，应展示公式、输入、来源/标签、低位/基准/高位情景、注意事项和置信度。可参考以下公式模式：
  • 生产力：用户数 x 每周期任务数 x 每项任务节省的时间 x 人工成本 x 采用率
  • 成本：当前成本基线 - 未来成本基线
  • 风险：避免的事件数 x 每起事件的平均成本 x 置信系数
  • 收入：受影响的收入池 x 改善率 x 置信系数
  • 上市时间：周期时间缩短量 x 提前发布或部署的价值
• 如果缺少必需输入，应保持计算结构化：展示公式，标出缺失输入，说明目前可以从方向上得出的结论，并列出使论据可供财务评估所需的最少问题。

5. 起草便于决策的方案

• 将运营影响转化为客户的业务成果，然后说明卖方解决方案为何适合该工作流和买方需求。
• 将公开战略背景与账户原生证据分开。类似成功案例只能用来支持假设，不能作为该客户的证据。
• 在有可用链接时，为重要主张添加有用的可点击链接；只有在没有稳定链接时，才使用纯文本来源标签。

后续步骤选项

完成初稿后，从以下选项中提供最相关的后续步骤。给出一个明确的衔接建议，而非选项列表。除非你非常确信其他选项更有用，否则只能从以下选项中建议：

• 根据用户的指导完善案例，或弥补最小范围的重要验证缺口。
• 生成供审阅的客户版高管摘要或价值叙述。
• 生成供审阅的内部支持者沟通要点或客户团队内部说明。
• 构建价值模型表格或可直接用于电子表格的模型结构。
• 内容审阅完成后，将案例整理成简明的会议预读材料或决策文档。

应避免的后续步骤：

• 在用户审阅内容并明确提出要求之前，保存、分享、发布、创建文档或更新系统。

模式

• Default Package — 以下完整商业案例。
• Structural Case — 客户和工作流明确，但缺少可信的量化输入时使用。
• Finance-Ready Case — 有来源可靠的输入，可支持公式及低、中、高情景时使用。
• Focused Output — 用户只要求高管摘要、ROI 表格、客户版叙述、差异化优势或验证问题时使用；同时简要说明证据情况和缺口。

输出格式

默认套餐使用此结构。

# Business Case: [Customer / Initiative]

## Executive Summary
[Customer objective, why now, priority workflow/use cases, likely value story, seller fit, and confidence.]

## Strategic Initiatives
- [Known/Inferred/Assumed/Missing: initiative + source]

## Key Challenges
- [Customer or workflow challenge + evidence label/source]

## Priority Workflows
- **[Workflow]:** [Actors, bottleneck, KPI, and why it matters]

## Priority Use Cases
1. **[Use case]** — [Problem, buyer/team, why now, evidence, validation gap]

## Value Hypothesis by Use Case
| Use Case | Value Bucket | Causal Chain | Evidence Posture | Confidence |
| --- | --- | --- | --- | --- |
| [Use case] | [Exact bucket] | [Change -> effect -> outcome -> metric] | [Known/Inferred/Assumed/Missing] | [High/Medium/Low] |

## Metrics and Assumptions
| Metric / Input | Value | Label | Source | Why It Matters |
| --- | --- | --- | --- | --- |
| [Input] | [Value or Missing] | [Known/Inferred/Assumed/Missing] | [Link/label] | [Formula role] |

## ROI or Value View
| Use Case | Formula | Low | Base | High | Caveats |
| --- | --- | --- | --- | --- | --- |
| [Use case] | [Formula] | [Value/Structural] | [Value/Structural] | [Value/Structural] | [Gap/confidence] |

## Solution Differentiators
- [Differentiator tied to workflow, buyer need, and expected business effect]

## Proof Points or Analogous Wins
- **Account-native proof:** [Evidence or Missing]
- **Analogous / public support:** [Evidence, clearly not customer proof]

## Caveats and Open Questions
- [Most important validation gap and smallest next collection step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

规则

• 不得编造客户数据、买方、工作流负责人、工具、审批、商务条款、ROI 或来源链接。
• 不得将公开的战略表述、基准数据或类似案例的成果说成经客户确认的影响。
• 不得用精致的措辞掩盖数据缺失；应说明案例属于结构性案例还是财务就绪型案例，以及原因。
• 优先选择一到三个用例，并仅保留能说明决策依据的最少价值类别。
• 此工作流仅供读取。除非用户在后续步骤中明确提出要求，否则不得发布、发送、分享、创建文档或更新 CRM。

失败处理

如果没有可信的客户或工作流依据，应说明阻碍，并询问最少量的缺失信息。如果无法使用可选信息渠道，应继续使用最有力且有根据的证据，并明确说明由此带来的置信度限制。