客户主数据模型怎么设计？三张卡一套关系的技术方案

一家公司 CRM 里同时存在三个「XX科技有限公司」，分别归三个销售管，各自跟进了两个月——直到客户方采购总监打来电话问「你们公司到底谁负责我们」。这类故事的根源不是销售乱建，是系统没有主数据设计。客户主数据模型（MDM 的客户域）解决的就是一个问题：让每家企业实体在你的系统里只有一个身份。这篇把一套适合中小企业的轻量方案拆开讲。

一、为什么客户主数据是一切的地基

销售自动化、漏斗分析、客户画像、离职交接，所有这些高级玩法都建立在一个朴素前提上：关于同一个客户的所有数据能挂到同一个身份下。前提不成立，下游全是灾难。

• 重复建档 → 报表里同一客户被算成三家，客户数虚高；
• 身份不唯一 → 跟进记录、商机、合同散落多处，交接即断片；
• 口径不一致 → 财务按主体记账、销售按集团统计，月度会对不上。

所以主数据先行不是技术洁癖，是业务刚需。业界成熟做法（分层建模、黄金记录、上下游分发）在大企业有重型 MDM 平台承接，中小企业用三张卡一套关系就能覆盖八成需求。

二、三张卡：客户、联系人、商机

模型的骨架是三张卡，分别回答三个问题：客户是谁（主体）、跟谁谈（人）、谈到哪了（事）。

1. 客户卡：一张卡等于一个法人主体

核心字段：客户编号（全局唯一 ID）、全称、统一社会信用代码、行业、规模、母公司。铁律：信用代码作为自然键参与查重，同一代码只能存在一张客户卡。集团客户的每个子公司各自建卡，用母公司字段关联，既独立核算又能按集团汇总。

2. 联系人卡：人是人，客户是客户

最常见的建模错误是把联系人姓名直接写进客户卡——联系人跳槽了，客户卡上的历史就断了。正确做法：联系人独立成卡，字段含姓名、职务、角色（决策人/影响人/把关人/教练）、手机号、偏好备注，通过客户编号挂靠。人动只改挂靠，客户资产不动。

3. 商机卡：事随客户走

商机字段：商机名、阶段、预计金额、预计成交日、输单原因，同样挂客户编号。同一客户多笔并行商机互不干扰，阶段推进留时间戳，这是后面做转化率分析的数据来源。

三、一套关系：外键只认客户编号

三张卡怎么连成网？规则只有一条：联系人、商机、合同、回款，所有下游数据都通过客户编号外键挂接，绝不通过名称匹配。名称是给人看的，编号是给系统用的。

这条规则落地后，常见的复杂场景都顺了：联系人离职，挂靠改到新客户，原客户历史完整保留；两个销售各建了一张卡，合并后下游数据自动归拢；集团维度统计，按母公司字段向上汇总即可。

四、四道护栏：把脏数据挡在写入端

数据治理的最高境界不是下游清洗，是写入端拦截。四道护栏，配置成本低，收益极大。

从同类项目经验看，四道护栏齐开后，新录数据的重复建档率一般能压到约 1% 以下（项目实施口径，非承诺值）。相比每月做一次全库去重，写入端拦截的成本低一个量级。

五、五步落地顺序

方案再对，顺序错了也会翻车。给一个经过验证的实施顺序。

1. 定主体：三张卡的边界先开会定清楚，特别是联系人与客户的分离；
2. 建主键：客户编号系统自动生成，信用代码做自然键；
3. 连关系：全部下游对象挂客户编号外键；
4. 设护栏：四道护栏上线，先于存量导入；
5. 留痕迹：字段级变更日志开启，只增不删。

存量清洗放在护栏上线之后做：以信用代码为锚点跑批合并，命中疑似重复的进人工审批队列，不自动并。宁可慢，不可错——并错的恢复成本远高于并慢。

六、三个常见的架构误区

1. 一张大宽表装天下

把客户、联系人、商机字段全塞一张表，短期省事，三个月后字段互相覆盖、查询性能崩塌。三张卡分离是底线。

2. 用名称做关联键

名称会变、有简称、有错别字，任何以名称为键的关联都是隐患。关联只认编号。

3. 追求一步到位的完美模型

主数据是活的，行业字段、画像标签都会演进。第一版守住「唯一 ID＋四道护栏」这两条主干，枝叶后面慢慢加。

落地工具方面，CRM 方案这类低代码平台原生支持多对象外键关联和字段级查重规则，三张卡的关系模型可以直接配置出来。主数据这件事，晚做不如早做，早做一天，下游就少一分还债。