028 · 方案演示与价值表达
用 WorkBuddy 制作客户问题与产品能力匹配表
需求访谈结束后，销售很容易直接进入“写方案”。客户说效率低，就把所有自动化功能都放进去；客户说需要系统，就默认现有产品能够解决。这样写出的方案看起来完整，却可能把客户没有确认的问题当成需求，也可能承诺产品尚未具备的能力。
在正式方案之前，先用 WorkBuddy 建一张内部匹配表，把客户原话、业务影响、目标、产品能力、适用条件、证据和缺口放在同一行。销售、售前和交付团队可以先对齐事实，再决定方案写什么。
场景价值
匹配表连接需求发现和方案设计。它帮助团队回答：客户真正要解决什么；问题造成什么影响；希望达到什么结果；哪些现有能力可以支持；使用这些能力需要什么条件；还有哪些需求无法覆盖。
这张表是内部判断工具，不是直接发给客户的销售方案。
开始前准备
- 已经复核的需求访谈纪要和客户原话；
- 客户现状、目标、约束和优先级；
- 产品或服务能力清单；
- 每项能力的适用条件、限制、版本和交付方式；
- 已核实的案例、演示结果或产品说明；
- 售前、产品和交付负责人的确认规则。
资料中如果混有销售推测，要提前标注。未经客户确认的潜在需求不能与明确需求写在同一层级。
具体步骤
第一步：整理客户问题和原始依据
从会议纪要、邮件和沟通记录中提取客户明确描述的问题，保留原话、来源和时间。相同问题可以归并，但不能为了表达专业而改变客户意思。
把销售推测和待核实内容放到单独清单。
第二步：写清问题的影响和目标
对每个问题记录影响的业务环节、人员、时间、成本、风险或客户体验，以及客户明确希望达到的结果。客户没有给出数据时保持定性描述，不自行编造收益数字。
继续记录预算、时间、技术环境、合规和组织协同等约束。
第三步：匹配候选产品能力
根据能力清单寻找可能支持该问题的产品、服务或实施动作。匹配结果分为可直接支持、需要配置、需要定制、需要合作方、暂不支持和待确认。
同一能力可以对应多个问题，但每次都要说明具体作用，不能只把产品功能列表复制进表格。
第四步：补充适用条件和证据
记录能力生效需要的数据、系统、权限、人员、流程和实施条件，并附产品说明、演示结果、已核实案例或内部负责人确认。
只有宣传口号、没有可验证依据的能力不能写成已经具备。
第五步：识别缺口与冲突
列出客户目标无法覆盖、范围不清、不同资料互相矛盾以及超出标准交付的内容。对需要定制或第三方支持的部分，记录评估负责人和截止日期。
缺口不是必须隐藏的信息。提前暴露缺口，可以避免方案、报价和合同阶段出现错误承诺。
第六步：组织内部评审
销售确认客户问题和优先级，售前或产品确认能力与限制，交付确认实施条件和范围。评审后将每行标记为已确认、待补证据、待客户澄清或不进入方案。
只有通过确认的内容才进入正式方案初稿。
可直接交给 WorkBuddy 的要求
请根据需求纪要、客户原话、产品能力清单和适用条件，制作一份内部使用的客户问题与产品能力匹配表。
逐项整理客户问题、原话和来源，再写明业务影响、客户目标、优先级和已知约束。明确需求、销售判断和待确认事项必须分开。
对每个问题匹配候选能力，并标记为“可直接支持、需要配置、需要定制、需要合作方、暂不支持或待确认”。
每项能力写清适用条件、限制和证据来源。不能把宣传描述当成已验证能力，不能补写客户没有提出的需求。
列出未覆盖需求、范围冲突、需要内部评估和需要客户澄清的问题。
最后生成销售、售前、产品和交付的评审清单。
本表仅用于内部评审，未经确认的内容不要进入客户方案、报价或合同。
完成后应得到什么
- 带客户原话和来源的问题清单；
- 问题影响、客户目标、约束和优先级；
- 产品能力、适用条件和证据的逐项对应；
- 未覆盖需求、定制事项和范围冲突；
- 需要客户澄清和内部评估的问题；
- 通过销售、售前和交付确认的方案输入。
结果检查
逐行回到会议纪要核对客户原话，确认没有把销售判断写成客户需求。再由产品或售前检查能力名称、版本、适用条件和限制，由交付检查实施资源和范围。
重点检查收益数字、案例、接口、数据要求、定制功能、交付周期和第三方依赖。没有证据或负责人确认的内容必须保留待确认标记。
异常处理
客户要求很模糊时，不急着匹配功能，先生成澄清问题。多个能力都可能解决同一问题时，列出差异、条件和取舍，不自行选择。现有产品无法覆盖核心需求时，如实记录缺口并评估是否继续投入。
不同内部团队对能力判断不一致时，保留各自依据，交给明确负责人决策，不能让 WorkBuddy 合并成一个折中结论。
WorkBuddy 能力边界
WorkBuddy 可以从材料中提取问题、整理对应关系、发现缺口和生成评审清单。它无法验证客户未公开的真实目标，也不能确认产品一定适用、定制一定可行或项目一定能交付。
客户需求、产品能力、实施范围和对外承诺分别由销售、售前、产品和交付负责人确认。