5.1 黄金样章：我怎样改造商机到回款
我第一次听云枢科技介绍这个项目时，会议名称叫“销售 AI 助手讨论会”。销售希望自动整理客户需求，售前希望自动生成方案，CEO 则希望缩短销售周期。
这些要求都合理，但它们还没有说明公司究竟损失了什么。我请团队暂时关掉演示文稿，找出一笔已经签约、却让销售、项目和财务都不满意的订单。
这笔订单最后改变了项目的名字。我们不再建设“销售 AI 助手”，而是改造从商机、方案、合同、交付、验收到回款的整条经营过程。
案例说明：云枢科技、订单和数字均为虚构教学材料。它们用于展示 FDE 的工作过程，不代表真实企业成果，也不能直接替换成另一家公司的结论。
我先把一笔“已经成交”的订单重新打开
订单编号是 YS-24-017，客户是一家拥有一百多家门店的培训连锁企业。客户希望三个月内上线门店经营系统，合同金额 70 万元，验收后支付最后 21 万元。
销售把它看作一笔成功订单：客户需求明确，合同按季度计划签下。项目团队却把它列入延期名单，因为原计划 90 天的项目最终用了 132 天。财务看到的又是另一件事：验收推迟后，最后 21 万元也晚了 49 天才到账。
我先把这笔生意写成一张不用行业知识也能读懂的结果卡。
| 发生了什么 | 原计划 | 实际情况 | 对经营的影响 |
|---|---|---|---|
| 项目完成并验收 | 90 天 | 132 天 | 多投入六周人力，后续项目排期被挤压 |
| 项目总成本 | 45.5 万元 | 57 万元 | 增加接口外包与顾问返工 |
| 项目毛利 | 24.5 万元 | 13 万元 | 毛利率从计划的 35% 降至约 19% |
| 最后一笔回款 | 验收后按期支付 | 比原计划晚 49 天 | 公司先付工资和外包费，现金更晚回来 |
毛利是收入扣除这笔项目直接成本后剩下的钱。合同额没有变，不代表这笔生意仍然一样赚钱。回款推迟也不等于收入消失，但公司必须更长时间用自己的现金垫付工资和供应商费用。
到这里，我仍然不知道应该改什么。我只知道，问题已经同时影响利润、交付能力和现金，而不只是销售少填了几个字段。
六份记录讲出了六个不同版本
我让销售、售前、项目经理和财务把与这笔订单有关的记录放到同一个时间轴上。我们没有先讨论谁做错了，只看当时留下了什么。
| 时间与记录 | 原文片段 | 当时被怎样理解 | 后来发现的问题 |
|---|---|---|---|
| 4 月 3 日，销售会议纪要 | “客户旧会员系统可以提供接口。” | 客户具备接入条件 | 这是客户业务负责人转述，第三方系统商尚未确认 |
| 4 月 5 日，售前个人文档 | “标准连接方式可能不适用，需要第三方配合。” | 售前准备以后再确认 | 文档没有进入共同评审，销售和项目都没看见 |
| 4 月 11 日，对客方案 | “完成会员数据接入。” | 客户理解为云枢科技负责打通 | 没写谁提供账号、数据和第三方授权 |
| 4 月 18 日，合同附件 | “客户提供项目所需资料与权限。” | 法务认为已经写了客户义务 | 没有资料清单、负责人和最晚提供时间 |
| 4 月 22 日，销售交接单 | “接口：已确认。” | 项目经理以为可以直接开始 | “确认”的人、来源和确认内容都不存在 |
| 5 月 7 日，项目群消息 | “第三方暂不开放接口。” | 被归为客户配合问题 | 公司此前从未要求客户取得第三方书面同意 |
销售记录、售前判断、对客方案、合同和项目交接都提到了“接口”，但它们说的不是同一件事。有人说的是技术上可能连接，有人说的是客户愿意配合，有人说的是合同已经承诺交付。
我请现场每个人回答一个问题：“在 4 月 18 日签约以前，哪一份记录能够证明第三方已经同意提供接口？”
没有人能找到。
这时我才把“客户不配合”从结论改成一个待验证说法。客户确实没有及时提供接口，但公司也没有在承诺前把客户需要完成的条件说清楚。
我差点把问题修在了错误的位置
项目负责人最先提出，在项目启动时增加一张“客户准备清单”。我一开始觉得这是最快的改法：至少项目团队可以更早发现缺失。
但如果清单第一次出现时合同已经签完，项目经理只能更早知道自己做不到，不能改变公司已经作出的承诺。问题仍然会变成返工、加价争议或延期。
销售负责人则希望让 AI 自动从会议纪要中找出“接口”“定制”“数据迁移”等风险词。这能减少遗漏，却仍然没有回答谁来确认、依据什么确认，以及确认结果怎样进入方案和合同。
我把最初的三个判断写在白板上：
| 判断 | 支持它的现象 | 不能解释的地方 | 我的结论 |
|---|---|---|---|
| 项目启动检查不完整 | 项目开始后才发现账号和权限缺失 | 无法改变已经签下的范围和价格 | 需要改，但太晚 |
| 销售记录不完整 | 客户条件经常只在会议纪要里 | 记录完整也不代表有人作出有效决定 | 是一部分，不是根因 |
| 非标准承诺在对客前无人确认 | 风险已被售前发现，却未进入共同决定 | 需要更多订单证明不是偶然 | 最值得继续验证 |
这一步很重要。FDE 不是听到第一个合理解释就开始建设，而是要知道这个解释能解释什么、解释不了什么。
十二笔订单让我看见了重复模式
一笔失败订单只能说明这件事发生过，不能说明应该改造整条流程。我又抽出十一笔相近订单，其中既有按期完成的，也有延期、亏损和逾期回款的。
“非标准”表示客户需要的内容超出了公司已经明确报价和交付的方法，例如特殊接口、额外数据迁移或新的验收方式。“承诺前确认”表示方案发给客户以前，已经有人确认公司能否做、客户要准备什么、需要多少成本。
| 订单 | 类型 | 承诺前是否确认 | 签约后是否改范围 | 计划 / 实际验收 | 回款情况 |
|---|---|---|---|---|---|
| YS-24-003 | 标准 | 不需要例外确认 | 否 | 88 / 87 天 | 按期 |
| YS-24-006 | 标准 | 不需要例外确认 | 否 | 90 / 94 天 | 按期 |
| YS-24-009 | 非标准 | 是 | 否 | 110 / 112 天 | 晚 3 天 |
| YS-24-012 | 标准 | 不需要例外确认 | 否 | 85 / 89 天 | 按期 |
| YS-24-017 | 非标准 | 否 | 是 | 90 / 132 天 | 晚 49 天 |
| YS-24-021 | 非标准 | 否 | 是 | 100 / 141 天 | 晚 37 天 |
| YS-24-028 | 标准 | 不需要例外确认 | 否 | 90 / 119 天 | 晚 28 天 |
| YS-24-031 | 非标准 | 否 | 是 | 120 / 160 天 | 晚 45 天 |
| YS-24-036 | 非标准 | 是 | 否 | 96 / 101 天 | 按期 |
| YS-24-041 | 非标准 | 否 | 是 | 105 / 137 天 | 晚 31 天 |
| YS-24-044 | 标准 | 不需要例外确认 | 否 | 90 / 91 天 | 按期 |
| YS-24-049 | 非标准 | 否 | 是 | 95 / 126 天 | 晚 34 天 |
十二笔订单不能证明整个公司的因果关系，但它们给出了清晰的诊断方向：七笔非标准订单中，五笔没有在承诺前完成确认；这五笔全部在签约后改变范围，并且都推迟了验收。两笔提前确认的非标准订单虽然周期较长，却没有发生无偿返工。
YS-24-028 是一个重要反例。它是标准订单，也延期了 29 天，原因是客户更换项目负责人。这个反例提醒我，提前确认非标准承诺不会消灭所有延期，也不能把以后所有问题都归到销售阶段。
我把诊断结论写得很克制：云枢科技目前最值得先改变的，不是所有销售活动，而是非标准要求从发现到对外承诺之间缺少共同决定。
一次争论帮我选出了目标方案
项目负责人希望所有方案都由项目团队评审。销售负责人反对，他认为标准订单也等待评审，会让公司错过客户采购窗口。财务负责人又补充说，仅仅判断“能不能做”还不够，额外工作如果没有进入报价，项目仍然会亏损。
我没有要求大家立即达成抽象共识，而是把三个方案放到同一张表里。
| 方案 | 好处 | 会制造的新问题 | 决定 |
|---|---|---|---|
| 所有方案都增加项目审批 | 最稳妥，项目能提前看见 | 标准订单也排队，项目团队成为新瓶颈 | 不采用 |
| AI 找到风险词后提醒销售 | 上线快，能减少部分遗漏 | 提醒不等于决定，仍可能被直接忽略 | 只作为辅助 |
| 标准订单走快速通道，非标准要求进入例外决定 | 把专业时间用在高风险订单上 | 必须维护标准能力和明确决定人 | 采用 |
我们最后约定：标准能力、标准价格和已经批准的客户条件可以继续推进；出现特殊接口、未发布能力、额外实施工作、特殊付款或合同责任时，订单停在“额外承诺待决定”。
AI 负责整理差异、找到来源并把问题送给正确的人。售前确认产品能力，项目负责人确认工作量和客户条件，财务确认价格与成本，法务确认合同责任。没有一个“万能审批人”，也没有让 AI 替这些岗位承担后果。
我把目标流程写成六个能被观察的状态
我没有从页面和按钮开始，而是先写清一笔订单在什么事实成立后才能继续。
| 订单状态 | AI 可以准备什么 | 人必须决定什么 | 进入下一步的证据 |
|---|---|---|---|
| 客户目标待确认 | 整理客户原话、来源和缺失问题 | 销售确认目标、决定人和时间要求 | 有来源的客户目标记录 |
| 方案能力待核对 | 对照标准能力，标出差异 | 售前确认标准或非标准 | 能力判断与确认人 |
| 额外承诺待决定 | 汇总工作量、客户条件和已有报价 | 项目、财务或法务分别作决定 | 接受、拒绝、另行报价或延后 |
| 合同条件待确认 | 比较方案、报价、合同中的差异 | 有权岗位批准价格、范围和责任 | 已批准版本及批准记录 |
| 交接待接收 | 生成带来源的交接材料 | 项目和财务确认能否接收 | 范围、客户条件、验收和付款完整 |
| 可以启动 | 提示仍未完成的准备事项 | 项目负责人确认启动 | 项目和客户所需条件已经满足 |
如果客户主体在 CRM 和合同中不一致，订单保持原状态；如果财务系统暂时不可用，付款事实显示“无法确认”；如果批准人不在线，系统按约定升级，但不能把等待自动变成同意。
这张状态表后来成为 AI 全栈工程师理解任务的核心。它比“做一个销售工作台”更有用，因为工程师能够知道系统何时开始、何时停止、谁能改变什么事实。
我写出的不是功能清单，而是一份业务任务书
把目标流程确认后，我才写第一页任务书。下面是当时的填写结果，而不是留给读者的空白模板。
| 项目 | 云枢科技的填写内容 |
|---|---|
| 任务名称 | 签约前承诺核对与签约后共同交接 |
| 为什么现在做 | 41% 的项目发生未充分计价的范围变化；样本显示非标准承诺与延期、毛利损失和回款推迟反复相连 |
| 第一阶段改变什么 | 非标准方案发给客户前必须完成能力、工作量、客户条件和价格决定；签约后项目与财务接收同一份材料 |
| 首批使用者 | 4 名销售、2 名售前、2 名项目经理、1 名财务人员 |
| 第一阶段包含 | 整理来源、发现缺失、比较差异、例外分派、待确认交接单和过程记录 |
| 第一阶段不包含 | 自动写最终报价、对客户发送内容、批准折扣、接受合同、修改项目完成和财务事实 |
| 试点停止条件 | 错误承诺进入对客材料、客户资料越权、AI 内容覆盖已确认事实，或故障后无法恢复原流程 |
完整版本还包括状态、数据来源、权限、验收用例、试点范围和经营观察。我把它单独保留为一份可以逐项审查的示范件：云枢科技“商机到回款”已填写执行包。
AI 全栈工程师第一次交回的理解并不合格
工程师第一次复述任务时写道：“系统读取客户纪要，自动识别风险，生成完整交接单并同步 CRM。”
这段话看起来很接近需求，实际上混淆了三件事：识别出风险不代表风险已经解决；生成完整文字不代表事实完整；同步 CRM 也没有说明可以写入哪些状态。
我把 YS-24-017 的六份记录重新交给工程师，只问三个问题：
- “客户可以提供接口”是谁确认的事实？
- 售前写下“可能不适用”以后，订单应该停在哪里？
- 如果销售坚持按原方案发给客户，系统可以阻止什么，又必须把决定交给谁？
第二版复述变成了：“系统保留销售原话和售前判断，不把两者合成一个确定结论；非标准要求进入待决定状态；只有对应负责人确认后，批准结果才能进入方案和交接材料。”
我这才允许进入方案设计。让工程师先复述不是形式，而是在建设成本还很低时暴露误解。
我没有让团队用最顺利的订单演示
第一次验收时，我把六种情况装进信封，让工程师和业务人员现场抽取。每种情况都写明已知事实、系统应该做什么、绝不能做什么以及由谁判断。
| 情况 | 系统应有表现 | 绝不能发生 | 判断人 |
|---|---|---|---|
| 标准需求且资料完整 | 整理来源，生成待确认材料 | 自动发给客户 | 销售、售前 |
| 客户没有确认第三方接口 | 标出缺失，并停在能力核对 | 写成接口已经具备 | 售前、项目 |
| 产品没有客户要求的能力 | 进入额外承诺待决定 | 写成公司可以交付 | 产品、项目 |
| CRM 与合同客户主体不同 | 停止合并，要求确认主体 | 自行选择一个名称 | 销售、法务 |
| 财务系统暂时不可用 | 显示付款事实无法确认 | 显示没有逾期风险 | 财务 |
| 用户要求直接发送报价 | 保留草稿并指向价格审批 | 自动批准和发送 | 销售负责人、财务 |
其中“客户主体不一致”第一次没有通过。系统根据名称相似度自动选择了集团公司，工程师认为这能减少人工操作。法务负责人指出，签合同和承担付款义务的是具体公司，名称相似不能替代主体确认。
我们没有把它记录成“模型答案不够准”，而是修改了业务规则：只要合同主体与客户主记录不一致，系统必须停下，保留两份来源并交给有权的人确认。修正后的情况进入以后每个版本都要重新运行的验收样本。
我用十二周试点决定扩大、保持还是停止
试点没有一开始就获得写入所有系统的权限。
- 第 1—2 周：只运行十笔历史订单，验证能否找出已知断点；
- 第 3—6 周：进入少量新订单，只整理和提醒，不改变原系统事实；
- 第 7—12 周：业务人员确认结果后，才允许写入“已确认”和“待决定”等有限状态。
为了说明应该怎样读试点数据，下面保留这套虚构案例中的教学观测。它不是对真实企业的收益承诺。
| 十二周后看到的现象 | 应该怎样解释 |
|---|---|
| 20 笔试点订单中，18 笔持续使用新流程 | 采用基本成立，但仍要调查两笔为什么回到旧表格 |
| 非标准要求都留下了决定记录 | 过程控制成立，不等于经营结果已经改善 |
| 项目接收后重新追问范围的订单从对照样本的 14 笔降至 5 笔 | 交接返工方向改善，需要继续观察更大样本 |
| 出现 3 次客户主体冲突，系统均停下并转人工 | 停止规则有效，不应把人工接管当成失败 |
| 没有发现错误承诺被自动发送 | 保护条件暂时通过，仍需持续回归 |
| 大多数试点订单尚未走到验收和付款 | 不能提前宣布回款或 ROI 已改善 |
我们因此决定保持小范围运行，并扩大到下一批同类非标准订单；没有开放自动发报价，也没有声称 AI 已经改善公司整体现金流。
这个决定看起来不够激动人心，却比“上线两周节省几百小时”更可信。价值流指标需要等业务对象真正走到终点以后才能下结论。
换一家公司，不能只替换系统名称
如果这是一家制造设备公司，“非标准承诺”还可能涉及原材料、产线能力、安装条件和变更成本；如果是一家零售企业，商机到回款可能变成选品、促销、履约和结算；如果是一家专业服务公司，关键约束可能是专家时间、项目范围和客户验收。
可以迁移的是我的工作顺序：跟着一笔生意走到底，比较成功与失败样本，找到第一次断开，设计例外决定，再把它写成可验收的任务。
不能直接迁移的是云枢科技的状态、负责人、数字和审批方式。FDE 到一家新公司后的第一项工作，永远不是复制这份执行包，而是找到那家公司真正交换价值和承担风险的方式。
读完这个案例，我希望你看见的是一条证据链
这次改造不是从“公司需要一个 Agent”开始，而是沿着下面这条证据链推进：
一笔延期订单 → 六份相互冲突的记录 → 十二笔对照样本 → 一个可行动的断点 → 三个竞争方案 → 六个业务状态 → 一份执行包 → 六类验收情况 → 十二周试点决定
任何一步都可能推翻前一步。订单样本不支持假设时，我要改诊断；业务岗位无法承担决定时，我要改流程；验收暴露越权时，我要改规则；经营结果尚未出现时，我不能提前宣布成功。
下一节：我怎样把市场热度变成有效商机。