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