同一家公司在客户关系系统里有两个账户，在客户数据平台里被合成一个客户，交易系统还保留着旧名称。业务人员打开三个页面，仍不知道该信哪一条。
先确定每个关键信息由谁负责，再决定系统之间怎样匹配和同步。
不同系统，各自回答不同问题
客户关系系统负责公司、联系人和销售服务过程；客户数据平台负责多来源身份匹配与行为整理；交易系统负责订单、支付和退款事实。
它们可以互相引用，但不应随意覆盖原始记录。订单金额以交易记录为准，联系人职位可能由销售确认，行为事件继续保留来源平台和发生时间。
图中的主记录是一组经过批准的字段责任。一个客户可以引用多个来源，同时保留每条信息从哪里来。
用一个虚拟冲突说明怎样判断
系统里出现“华东某科技有限公司”和“某科技华东分公司”。两条记录共用联系电话，但统一社会信用代码不同，交易账户也分别存在。
只凭电话相同就自动合并，可能把两个法律主体的订单、授信和联系人放到一起。正确做法是先标为候选匹配，由销售或客户资料负责人核对企业证件和业务关系，再决定是否关联。
如果只是旧名称与新名称变化，可以保留旧ID和更名依据，让历史订单仍能追溯。
合并之后必须能够拆回
匹配规则会出错。系统要保存旧ID、匹配依据、操作人、时间和受影响的下游标签。发现误合并时，不仅要拆开主记录，还要修正被错误合并的权益、标签和报表。
表格可以帮助梳理一次冲突，却难以持续控制谁能修改关键字段，也难以让所有下游系统同步修正。
DeepSeek的候选匹配提示词
比较授权的客户账户、身份记录和交易账户。优先使用统一社会信用代码、已确认联系方式和明确业务关系提出候选匹配。每条建议说明使用了哪些字段、有哪些冲突、需要谁确认。信息不足时标记为待核实，不自动合并、删除或覆盖原记录。
最后要形成一张字段责任表：谁创建、哪套记录为准、多久更新、谁能修改、冲突怎样处理。做到这里，三个ID才不会继续制造第四个版本。