1.8 同一个客户为什么有四个版本

经营会上，销售说一位客户状态正常，项目经理说客户正在要求延期，客户成功说对方已经表达不满，财务则说尾款逾期四十天。

四个人说的是同一家公司，却像在谈四个客户。

我把四个“正常”放到同一条时间线上

销售的“正常”表示商机仍有续约可能；项目系统的“正常”表示当前计划尚未正式改期；客户成功已经记录两次投诉；财务则依据合同判断尾款逾期。

它们不全是错误，而是在回答不同问题。真正危险的是经营会上把这些状态当成同一种客户健康。我们先保留各自含义，再定义谁负责形成跨部门的客户经营判断。

我原先想统一成一个状态，后来意识到强行合并会丢掉信息。共同客户身份可以统一，不同岗位的专业判断需要保留来源和解释。

销售在 CRM 里维护商机，项目团队用项目系统，客户成功看工单，财务使用财务软件。聊天群和个人表格里还有大量补充信息。

我没有问哪个系统最好，而是逐个事实确认：客户正式名称以哪里为准，合同范围由谁修改，项目完成需要谁确认，付款到账以哪条记录为准。

能被公司用于批准、付款、评价或对客户承诺的记录，我把它叫作经营事实。白话就是：公司做重要决定时，最终相信哪一条。

客户名称重复，不一定需要更聪明的匹配算法，可能是没人负责合并；项目状态过期，不一定是系统不能更新，可能是员工更新后没有任何好处；政策文件冲突，可能是没有人宣布旧版本失效。

所以我会同时记录四件事：事实在哪里产生，谁维护，谁可以修改，改变后谁必须知道。

只有来源没有负责人，数据会慢慢过期；只有负责人没有使用规则，大家仍会各自解释。

客户正式名称由客户资料负责人维护，合同范围以签署版本为准，当前交付计划由项目负责人确认，到账由财务记录。客户健康则不是从任一系统直接复制，而是由客户负责人结合使用、项目、投诉和付款作判断。

事实错误、判断不同和资料过期要分别处理。事实错误可以纠正，判断不同需要责任人解释，资料过期则要追问为何没有及时更新。

系统不只是软件。报价审批规则、合同模板、项目启动条件和财务制度都会决定信息怎样流动。

如果制度要求三人批准，而软件只记录最后一人的名字，真实过程就消失了。反过来，如果软件允许任何人修改客户付款状态，再严格的制度也难以执行。

FDE 要把软件、表格、文档、聊天和制度放在一起看。

我还会问系统不可用时大家依赖什么、员工离职后哪些事实会消失、制度变化后旧模板如何失效。正式软件之外的工作不是旁枝，而是公司真实运行的一部分。

AI 可以跨资料查找、比较版本和提示冲突，但不能把所有文件当成同样可信。它还必须遵守权限：销售能看的合同内容，不代表所有员工都能看；一份会议纪要也不能推翻已经签署的合同。

我交给 AI 全栈工程师的任务，是为几个重要事实标明权威来源、当前负责人、可见范围和更新时间。遇到冲突时，系统应把两条记录并列展示并交给责任人确认，不能悄悄选择一个。

我选一位集团客户，请销售、项目、客户成功和财务分别找到合同主体、当前承诺、项目状态、投诉和付款。每条都要能回到来源、时间和维护人。

再制造一条冲突记录，观察系统是否保留分歧、限制无权查看并交给正确的人。若 AI 给出一个流畅的综合答案却无法解释依据，这张地图还没有保护经营决定。

经营事实	公司最终依据什么	谁能确认或修改	当前冲突样本	AI 遇到冲突怎样做
客户与合同主体	客户主记录和已确认合同主体	销售、法务	CRM 是集团，合同是子公司	并列显示，停止自动合并
客户目标	有来源的客户原话与销售确认	销售、客户负责人	AI 摘要把意向写成承诺	分开原话、整理和人工确认
合同范围	已签署合同及有效附件	法务、授权业务岗位	方案更新后附件没有同步	指出版本差异，不覆盖合同
项目状态	项目负责人确认的计划和事实	项目负责人	系统“正常”，客户群正在讨论延期	显示状态含义和最后确认时间
应收与收款	财务 ERP	财务	CRM 复制了过期的收款状态	显示财务无法确认，不能猜测

我原本想把四个“正常”合成一个客户健康分数。事实地图让我停了下来：客户身份可以统一，销售机会、项目风险、客户情绪和财务逾期仍然是不同判断。它们需要共同展示，却不能失去各自来源。

这张事实地图也进入云枢科技已填写商业系统图。接下来五节会暂时离开云枢科技，学习不同类型公司的商业逻辑。这样进入别的企业时，我们不会把一套 SaaS 服务公司的判断直接套过去。第一种是订阅生意：订阅生意为什么最怕客户不用。