第10章 基础交付与客户沟通
本章导读
第二篇最后一章，讲FDE基础工作流的收尾环节——交付与客户沟通。方案做出来、工作流跑起来，不等于项目成功。客户认不认、能不能验收、价值能不能传递到位，全靠交付与沟通。本章讲解决方案文档的写法、Demo制作技巧、客户汇报话术、项目验收标准。读完本章，你应当能独立输出方案文档、完成Demo演示、顺畅推动项目验收。
§10.1 交付不是终点，是价值兑现
许多新手FDE以为"东西做完了就交付了"，这是误解。交付的本质是让客户认可并使用，价值才算兑现。
一个反例：FDE搭完系统，把文档发给客户就结束。客户看不懂文档、不会用系统、没感受到价值，最后项目烂尾。技术上线了，价值没兑现。
正确的交付观：交付是一段持续的沟通与赋能过程，包含文档、Demo、汇报、培训、验收多个动作，目标是让客户"看得懂、用得起、认得值"。
§10.2 解决方案文档写作
方案文档是FDE的核心交付物之一。它既是给客户看的（说服与对齐），也是给团队看的（执行依据）。
10.2.1 标准结构
方法论框10-1：方案文档标准七段结构
- 背景与目标：客户现状、要解决什么、预期效果。
- 需求理解：复述调研发现，证明你懂客户。
- 方案设计：技术架构、Skill/工作流设计、关键流程图。
- 实施计划：阶段划分、里程碑、排期、人员。
- 效果测算：预期效果与量化方法。
- 风险与应对：主要风险与预案。
- 报价与商务：费用构成、付费模式（如适用）。
七段不是死板模板，可按项目调整，但七项信息缺一不可。
10.2.2 写作原则
结论先行：每段开头给结论，再展开。客户没耐心看长篇推导。
业务语言：少用技术术语，必须用时要配通俗解释（参考第4章术语转译）。
数据说话：效果用数字，不用"显著提升"“大幅降低"这类虚词。
图化优先：架构图、流程图、效果对比图，比文字更易理解。
可执行：团队读完能直接干，客户读完能做决策。
10.2.3 常见问题
问题一：堆技术细节。 客户不关心你用什么模型，关心能解决什么问题。技术细节放附录，正文讲业务价值。
问题二：效果不量化。 “提升效率"不如"从110分钟降到30分钟，提升73%"。
问题三：回避风险。 不写风险显得不专业，写了风险不写应对显得不可靠。风险与应对必须成对出现。
问题四：方案与报价脱节。 方案写很大，报价很小，客户怀疑偷工；方案很小，报价很大，客户觉得贵。方案与报价要匹配。
§10.3 Demo制作技巧
Demo是方案的可视化证明。一个好的Demo，比十页方案文档更有说服力。
10.3.1 Demo的目标
Demo不是产品全功能展示，而是用最小可运行版本证明核心价值。目标只有一个：让客户看完说"这就是我要的”。
10.3.2 Demo制作原则
方法论框10-2：Demo制作四原则
- 聚焦核心价值：只演示最打动客户的那一个点，不堆功能。
- 真实数据：用客户真实业务数据（脱敏），不用玩具数据。
- 完整闭环：演示从输入到输出的完整流程，不卡半截。
- 可交互：让客户能亲手试，体验感强于被动看。
10.3.3 Demo脚本设计
Demo不是随便点点，要有脚本。脚本包含：
- 开场：一句话说清这个Demo解决什么问题。
- 场景：设定一个客户熟悉的业务场景。
- 演示：按业务流程走一遍，每步说明在做什么、为什么这么做。
- 结果：展示输出，对比改进前后。
- 收尾：一句话总结价值，引出讨论。
脚本要演练，演练到流畅自然，不卡壳不看稿。
10.3.4 Demo的常见坑
坑一：功能太多。 想展示所有功能，结果每个都浅尝辄止，客户没记住任何亮点。聚焦一个核心价值讲透。
坑二：用玩具数据。 “今天天气真好"这类Demo数据，客户无感。必须用客户真实场景数据。
坑三：现场翻车。 Demo没演练，现场网络断了、模型超时、数据出错。要准备离线备份与录屏兜底。
坑四：只演示不互动。 客户被动看，参与感弱。关键步骤让客户亲手操作。
§10.4 客户汇报与沟通话术
汇报是FDE的高频动作。会做不会说，价值打折扣。
10.4.1 汇报的三类场景
场景一：方案汇报。 向客户介绍方案，争取认可与立项。 场景二：进度汇报。 项目进行中的定期同步。 场景三：效果汇报。 项目验收时呈现成果。
三类场景话术侧重不同，但有几个通用原则。
10.4.2 通用汇报原则
先讲价值再讲技术。 客户先关心"能解决我什么问题”，再关心"怎么解决”。开场讲价值，技术放后面。
用客户语言。 客户是销售总监就讲业绩影响，是运营总监就讲效率提升，是CFO就讲成本节约。同一项目，对不同受众讲不同重点。
主动管理预期。 不夸大效果、不回避局限。把"能做到什么"和"做不到什么"讲清楚，避免后期落差。
准备应对质疑。 客户会问"效果不稳定怎么办"“数据安全怎么保证"“跟现有系统怎么集成”。提前准备答案，被问时不慌。
10.4.3 应对质疑的话术
方法论框10-3：应对质疑的"承认+事实+方案"三步
- 承认：先承认客户担忧合理，不急于反驳。
- 事实：给数据或案例证明实际表现。
- 方案：说明应对措施与兜底机制。
示例（客户问"AI效果不稳定怎么办”）：
- 承认：“您担心稳定性，这个担心很合理，AI确实存在效果波动。”
- 事实：“我们在灰度阶段测了500条样本，准确率稳定在92%以上。”
- 方案：“同时我们设置了置信度阈值，低于0.7的自动转人工，不会让不稳定结果直接到客户面前。”
三步走，质疑变信任。
§10.5 项目验收
验收是项目正式收尾的节点。验收不规范，后期扯皮多。
10.5.1 验收标准
验收标准要在项目启动时就与客户对齐，不能到验收时才谈。标准包含：
- 功能验收：方案承诺的功能是否全部实现。
- 效果验收：效果指标是否达成（用§9.7的四维度量化）。
- 稳定性验收：试运行期间的可用性、错误率。
- 文档验收：操作手册、运维说明、培训记录是否齐全。
10.5.2 验收流程
方法论框10-4：验收五步流程
- 预验收：FDE内部先按标准自检，确保达标。
- 试运行：客户真实环境跑1-2周，收集数据。
- 验收汇报：向客户呈现试运行数据，对照标准。
- 签字确认：双方对验收结论签字。
- 移交：交付文档、权限、培训，正式移交运维。
10.5.3 验收的注意事项
注意一：标准要可量化。 “效果良好"无法验收，“准确率≥90%“可以验收。标准必须数字化。
注意二：试运行要真实。 试运行用真实流量与数据，不能用模拟数据糊弄。
注意三：遗留问题要清单化。 验收时难免有遗留问题，要列清单、定责任人、定解决时间，不能口头承诺。
注意四：验收不等于结束。 验收后还有维护期，要约定维护内容、响应时间、费用。
§10.6 交付与沟通的常见误区
误区一：“做完就交付”。 交付是价值兑现过程，不是技术上线动作。
误区二：“方案越厚越专业”。 客户没耐心看厚方案，精炼到位才是专业。
误区三：“Demo越多功能越好”。 聚焦核心价值，功能多反而稀释重点。
误区四：“汇报只讲成绩”。 只讲成绩不讲风险，客户发现风险后信任崩塌。主动暴露风险反而增信。
误区五：“验收标准临场谈”。 标准必须前置对齐，临场谈必扯皮。
本章小结
- 交付观：交付是让客户"看得懂、用得起、认得值"的价值兑现过程，不是技术上线。
- 方案文档：七段结构，结论先行、业务语言、数据说话、图化优先、可执行。
- Demo：聚焦核心价值、真实数据、完整闭环、可交互，配脚本演练。
- 汇报话术：先价值后技术、用客户语言、主动管理预期、承认+事实+方案应对质疑。
- 验收：标准前置对齐且可量化，预验收→试运行→汇报→签字→移交五步走。
思考题
- 用方法论框10-1的七段结构，为你做过（或观察过）的一个项目写一份方案文档大纲。
- 用方法论框10-2的四原则，为一个AI能力设计一个Demo脚本。
- 用"承认+事实+方案"三步，准备一个客户可能质疑的问题的回答。
- 列出一个项目验收时可能出现的5个遗留问题，各给一个处理方案。
延伸阅读
- 本书第三篇第11章将讲全流程项目交付SOP，是本章交付环节的系统化升级。
- 第15章讲商业价值设计与付费模式，与本章效果测算衔接。
- 经典商务沟通与方案写作资料（如金字塔原理），可作方法论补充。
第二篇结束。 完成本篇六章，你已掌握FDE基础工作流：方法论、调研、技术工具、Skill搭建、工作流自动化、交付沟通。第三篇将进入成长进阶，从单项目执行升级到全流程独立交付。