1.7 为什么大家都努力，公司仍然卡住

云枢科技的销售和项目团队因为一笔延期订单争了起来。

销售说：“不答应客户的时间，这单根本签不下来。”项目经理说：“答应的时候没有问我们，最后却要我们承担延期。”

两边都不是不负责任。销售的奖金主要看签约金额，项目团队的考核看按时交付和毛利。公司用两个不同的目标，把他们推向了冲突。

我不先劝大家合作，而是看谁能决定什么

我把那笔订单中的几个决定写下来：是否承诺定制、能否打折、什么时候上线、客户要准备什么、延期后怎么办。

然后我逐项问：谁提出，谁有权批准，谁执行，结果不好时谁承担后果。

我发现销售可以承诺时间，却不掌握交付产能；项目经理承担延期，却无法在签约前拒绝不具备条件的项目；财务关心毛利，却到合同审批末期才看到额外工作。

问题不是“沟通不够”，而是决定权和后果没有放在同一处。

最直接的建议是让销售和项目每周多开一次会。但如果销售仍能单独承诺时间，项目仍只能在签约后看到订单，会议只会更早重复同一个冲突。

云枢科技后来规定，非标准范围和特殊上线时间在对客户承诺前，由销售提供客户价值，售前与项目提供工作量和产能，拥有相应权限的负责人批准。资料不齐时可以继续沟通，但不能进入正式承诺。

这不是要求所有订单都多人审批。标准产品按现有规则顺畅进行，只有超出范围的事件才进入共同决定。

制度可能要求员工“以客户为中心、跨部门协作”，但奖励和惩罚会更直接地告诉他什么最重要。

当销售只为合同额负责，他自然倾向于把风险留到以后；当项目经理只为利用率负责，他可能不愿让团队花时间帮助售前；当客户成功只看工单关闭数，复杂问题可能被快速关闭却没有真正解决。

FDE 设计新流程时，必须同时检查指标。不改变让旧行为合理存在的激励，只增加一个 AI 工具，员工会用新工具继续追求旧目标。

销售指标因此增加承诺质量与交接结果，项目团队也不再只看人员排满，而要支持重要商机的早期判断。指标不是越多越好，关键是不能奖励一个岗位把成本和风险推给下游。

改变指标由经营与人力负责人决定，不是 FDE 或系统自动完成。员工要提前知道评价如何变化，并能指出自己无法控制的结果。

如果 AI 自动生成报价，谁批准价格？如果它判断项目可以启动，谁为资料缺失负责？如果它提醒风险却没人处理，谁决定升级？

我让 AI 全栈工程师在每个高风险动作旁显示责任人、批准条件和超时后的去向。AI 可以准备建议和留下记录，不能成为“系统自己决定的”这种说法的借口。

AI 整理客户要求和相似项目，规则识别标准范围，人负责特殊承诺。负责人超时未处理时，系统升级或保持未承诺，不会自动把沉默当作批准。

我用标准订单、特殊定制、负责人休假和承诺后发现错误四种事件走关键决定表。每种情况都要知道谁有事实、谁能批准、谁执行、怎样纠正。

上线后看承诺返工、毛利偏差、审批等待和部门争议。若员工仍通过私聊寻找“愿意承担的人”，说明正式责任没有真正成立。

关键决定	谁提供事实	谁有权决定	谁承担执行结果	YS-24-017 当时的缺口
客户要求是否属于标准能力	售前、产品	售前负责人或产品负责人	售前、项目	售前只写了个人判断
非标准接口是否接受	客户、售前、项目	项目或产品负责人	项目团队	没有人在对客前必须回答
额外工作怎样定价	项目、财务	销售负责人和财务授权人	销售、项目	接口工作没有进入报价
客户条件是否足够	客户、销售、项目	项目负责人	客户与项目团队	合同义务过于宽泛
项目何时可以启动	合同、资源、客户条件	项目负责人	项目团队	签约被误认为自然可以启动

这张表并不意味着每笔订单都增加五次审批。标准情况可以按预先确认的规则继续，超出范围时才找到有权承担后果的人。

它还暴露了一个新问题：决定表写得再清楚，如果每个人拿到的客户、合同和项目事实不是同一版本，责任人也无法可靠判断。下一节我会沿着同一位客户检查公司到底相信哪条记录：同一个客户为什么有四个版本。