友情链接 wecomapi.
在实际运营中，同一名客户可能添加多名企业员工，也可能同时进入咨询群、活动群、交付群和售后群。
如果系统把每一次员工关系和每一次入群记录都当成独立客户，就会出现客户数量虚高、标签相互冲突、销售重复跟进和服务记录分散等问题。
公开的企业微信 API 文档镜像显示，获取客户详情时，返回的跟进成员会受到应用可见范围限制；获取客户群列表时，群主同样需要处于应用可见范围，并且群列表需要分页获取。这意味着系统看到的数据可能只代表当前应用权限范围，而不一定是企业全部客户关系。
一、客户主体和客户关系必须分开
同一客户被两名员工添加，并不代表企业拥有两名不同客户。
数据模型中应建立一个客户主体，用于表示客户本身；再建立员工客户关系，用于表示哪名员工在什么时间添加了客户、负责什么业务以及当前跟进状态。
客户加入外部群后，则新增群成员关系，记录客户在哪个群、何时加入、由谁邀请以及是否已经退出。
这样，一个客户可以对应多条员工关系和多条群成员关系，但客户主体仍然只有一条。
二、昵称不能作为身份依据
客户可能修改微信昵称，不同客户也可能使用相同昵称。如果系统按照昵称合并客户，很容易发生错误。
头像同样不可靠，因为头像可以更换，也可能多人使用相同图片。手机号虽然具有较强识别能力，但并不是所有场景都能获得，而且手机号也可能发生更换或被多人共用。
系统应优先使用平台提供的稳定身份标识，再在内部建立统一客户编号。外部标识属于哪个企业、账号和接入渠道，也需要一起保存，不能脱离上下文单独使用。
三、身份归并需要区分确定匹配和疑似匹配
并不是所有客户记录都能够自动确认属于同一个人。
可以把匹配结果分成三个等级。
确定匹配表示存在稳定平台标识或经过验证的业务身份；高置信匹配表示手机号、订单信息或多个字段高度一致；疑似匹配则只存在昵称、头像或行为上的相似。
确定匹配可以自动归并，高置信匹配可以进入人工确认，疑似匹配只做提示，不应直接合并。
错误合并的影响通常比暂时不合并更严重。两名不同客户被合并后，可能造成订单、标签和聊天记录相互泄露。
四、合并时不能简单覆盖字段
不同员工保存的客户备注可能不同，一名销售记录的是公司名称，另一名客服记录的是售后问题。如果合并时只保留最后一条数据，会丢失有价值的信息。
客户主体中可以保存经过确认的基础资料；员工客户关系中保留各员工自己的备注、标签和跟进记录；群成员关系中保留客户在不同群中的身份和行为。
对于存在冲突的字段，可以记录来源、更新时间和可信等级，由业务规则决定当前展示哪个值。
五、客户标签也需要区分关系级和主体级
部分标签属于客户主体，例如所属行业和所在地区。部分标签只属于某一段业务关系，例如某销售判断的跟进阶段。还有一些标签只与某个群或活动有关，例如参加春季训练营。
如果所有标签都直接写在客户主体上，就容易造成跨业务污染。
例如，客户在某次活动中被标记为"未到场"，不代表该客户在其他业务中也处于同样状态。
因此，标签应明确作用范围：客户主体标签、员工关系标签、群成员标签或活动标签。查询客户完整画像时，可以统一展示，但底层数据不能混在一起。
六、跨群统计必须基于客户主体去重
一个客户加入三个群，群成员数量应该计算为三条关系，但企业客户数量只能计算为一人。
数据看板应同时提供两个指标：外部群成员关系数和去重客户数。
前者反映群运营规模，后者反映实际覆盖客户规模。二者之间的差异还可以帮助企业了解客户平均加入多少个群，以及是否存在重复拉群过多的问题。
七、权限范围会影响身份判断
应用只能看到权限范围内的数据时，系统可能无法发现同一客户与其他部门员工的关系。
因此，系统不能因为当前只查询到一条跟进关系，就断定该客户在企业内只有一名负责人。
身份归并结果应记录数据覆盖范围和最近同步时间。权限扩大或增加新账号后，可以重新执行归并，而不是永久沿用早期判断。
不同部门查看同一客户时，也应遵守权限规则。统一客户编号并不意味着所有员工都可以查看客户的全部聊天、订单和服务记录。
八、归并和拆分都需要审计
身份归并可能由系统规则自动完成，也可能由管理员人工确认。无论哪种方式，都应记录原记录、目标客户、匹配依据、操作人员和时间。
如果后续发现错误，还需要支持拆分。拆分时，应恢复员工关系、群成员关系、标签和业务记录的原始归属。
没有审计记录的客户合并，一旦出现错误，通常很难判断哪些数据应该恢复给哪一名客户。
九、总结
企业微信外部群中的客户身份并不是一条简单联系人记录，而是客户主体、员工关系、群成员关系和业务记录的组合。
系统需要使用稳定标识建立内部客户编号，对不同置信度的匹配采用不同处理方式，并区分客户级、关系级和群级数据。
只有身份被正确归并，客户数量、标签、销售跟进和群运营统计才不会因为重复记录而失真。