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