2.4 我怎样用四条线还原一笔延期订单

一笔项目延期后，云枢科技最初把原因写成“客户数据准备不及时”。我沿着订单复盘，发现公司在签约前从未明确告诉客户要准备哪些数据，付款条件又与验收绑在一起。

只看项目任务，我会把责任推给客户。把四条线放在一起，故事才完整。

第一条线：客户经历了什么

我记录客户每次收到的承诺、需要作出的决定和等待。客户认为数据接入包含在服务里，所以从未安排内部 IT 提前准备。

销售、售前、项目、研发和财务分别完成了哪些动作，交接前需要什么条件，实际等了多久。我尤其标出返工和重复解释。

报价有没有覆盖额外工作，公司何时开始投入，发票和付款依赖什么。项目延期不仅影响时间，也让公司继续垫付人力。

客户原话、方案、合同和项目计划对“数据接入”写法不同。每次修改由谁确认、下游是否知道，是我重点查的地方。

四条线重叠后，真正问题变成：签约前没有把客户条件变成共同确认的事实，而不是一句“客户配合不好”。

项目负责人最先提出增加一个“客户数据就绪”检查项。我一开始觉得合理，但把时间轴往签约前拉，才发现客户从未被告知需要准备专门的接口账号，销售也不知道这会增加交付成本。

如果只在项目阶段增加检查，交付会更早发现问题，却仍然无法改变已经签下的承诺。断点第一次发生在方案与合同阶段，修复必须提前到那里。

客户第一次提出需求时，公司开始投入售前；方案承诺数据接入时，成本估算没有变化；合同签署后，项目才向客户索要技术条件；验收延迟后，尾款也随之推迟。

我不把四条线画成四张互不相干的流程图，而是按同一时间轴放在一起。这样一个信息变化如何引起工作返工、客户等待和现金推迟会直接显现。

销售提供客户承诺，项目团队还原实际工作，财务说明成本与付款，数据负责人帮助找记录。我负责追问不一致；AI 可以按时间整理大量消息和文档，但每条关键事实都保留来源，由相应岗位确认。

我们又选了一笔按时交付的相似订单。它在签约前就有技术确认会，合同附件中明确客户准备事项，项目交接时没有重新解释。

对比让我看见，成功并非项目经理更努力，而是早期事实和责任更完整。若只有失败样本，团队容易把每个异常都解释成偶然；有了正常样本，改造目标就变成可以复制的工作条件。

我请相关负责人沿图回答：第一次不一致在哪里，当时谁有机会发现，造成了什么客户、工作和资金后果，下一条真实订单要在哪个事件改变。

如果答案仍是“加强协作”，图还没有完成。云枢科技最终决定在非标准方案发出前确认客户准备事项和预计成本，未经确认不能进入合同。这是一项能被执行和验证的改变。

AI 可以帮助把不同系统记录按时间对齐，但必须保留来源和冲突。我不会让它自动推断责任。

事件	客户经历	公司工作	钱怎样变化	事实怎样变化
初次需求	希望三个月上线并接入旧系统	销售和售前投入	已发生成交成本	客户转述接口可用
对客方案	看到“完成数据接入”	售前发现标准方式可能不适用	报价没有增加成本	风险留在个人文档
合同签署	认为云枢科技负责完成	公司承担70万元合同责任	收首款，后续投入开始	客户义务写得宽泛
项目启动	被要求取得第三方授权	项目重新确认并返工	成本继续增加	“已确认”被证明不完整
延期验收	等待替代方案	项目延期42天	尾款不能按计划收回	项目与财务风险恶化

顺利对照订单在对客前完成技术确认，并把客户准备事项写入合同附件。第一次差异因此落在“风险被发现以后，有没有进入共同决定”。完整四线材料见诊断证据包。

下一节不再使用“协作不好”概括这个位置，而是把它写成能够分派责任和继续验证的断点：我怎样给断点取一个能行动的名字。