企微客户联系接入低代码 CRM：外部联系人 ID 与标签体系

结论先行：把企业微信的客户联系接入 CRM，核心不是拉接口，而是先把主键定对。用 external_userid 加企业 ID 做客户主键，用"客户-成员"关系表承载多对多，再配 5 张核心表（客户、关系、标签、跟进记录、客户群），标签同步走回调加 30 分钟增量对账，离职继承做成标准流程，客户资产就不会因为人员流动而蒸发。

销售用企微加客户、用 Excel 记跟进、离职时客户跟着人走——这是大量中小企业的真实状态。本文按 ID 设计、数据模型、标签体系、离职继承四步给出可落地方案。

Table of Contents

一、先分清三个 ID，主键才不会错

企微客户联系里最容易踩的坑，是把三个概念混成一个：

external_userid：企业为外部联系人分配的唯一标识，是 CRM 里客户主键的正选。同一微信用户在不同企业主体下会拿到不同的 external_userid，跨企业不能直接对齐（具体规则以官方文档为准）；
unionid：微信开放平台维度的用户标识，需绑定开放平台后才可获取，用于同一集团多个企业主体之间做客户归并；
follow_userid：跟进成员的内部 userid，来自通讯录，承担"谁在服务这个客户"的角色。

三者关系是：一个 external_userid 可被多个 follow_userid 添加，形成多对多；一份 unionid 可能对应多个 external_userid。因此必须拆表，而不是在客户表上挂"负责人"字段。

二、五张表撑起客户资产

表	主键	关键字段	作用
客户表	external_userid + 企业 ID	昵称、类型、unionid、添加时间	客户唯一档案
关系表	external_userid + 成员 userid	关系状态、备注、来源渠道	承载多对多与归属
标签表	标签 ID	标签组、标签名、企业/个人属性	分层与自动化打标
跟进记录表	自增	客户、成员、时间、内容、下一步计划	服务过程留痕
客户群表	群 chat_id	群主、成员数、创建时间	群运营与转化

关系表的状态字段是整套设计的枢纽：正常、已删除、继承中三种状态覆盖绝大多数场景。客户删除成员时不要物理删除记录，改成软删除，历史跟进记录才能继续追溯——这也是审计和交接的基本要求。

三、接口数据流：先拉成员，再拉客户，最后补详情

客户联系使用独立的 secret，和通讯录的权限不是一回事，配置时不要混用。整体流程分四步：

调用 /cgi-bin/gettoken 换取 access_token，缓存并在过期前刷新，凭证有效期以官方文档为准；
调用 /cgi-bin/externalcontact/get_follow_user_list 拿到已配置客户联系的成员列表；
按成员调用 /cgi-bin/externalcontact/list 取该成员名下的 external_userid 列表；
调用 /cgi-bin/externalcontact/get 补全客户详情，包含标签、备注、添加时间等字段。

标签侧用 /cgi-bin/externalcontact/get_corp_tag_list 拉取企业标签组，/cgi-bin/externalcontact/add_corp_tag 新建标签，/cgi-bin/externalcontact/mark_tag 执行打标。客户群则通过 /cgi-bin/externalcontact/groupchat/list 与详情接口获取。以上接口路径与参数以企业微信官方文档为准，不同版本存在字段差异。

回调负责"及时"，接口负责"完整"。客户新增、删除、标签变更都会触发客户联系回调事件，但回调只告诉你有变化，详情仍要主动拉取一次。

四、标签体系：企业标签定口径，个人标签留弹性

标签分两类，职责完全不同：

企业标签：由管理员统一创建，全公司共用口径，适合行业、规模、意向等级这类需要跨团队统计的维度；
个人标签：成员自行创建，只有本人可见，适合"今天想重点跟"这类临时性偏好。

标签组建议按业务场景划分，例如来源渠道、意向等级、服务阶段、风险标记。落地上只保留两个打标入口：规则自动打标与成员手动打标。自动打标放在工作流里做最省事——以猫拽低代码（CatPull）为例，读取客户详情、判断"添加满 7 天仍无跟进记录"、调用打标接口、写入一条跟进记录，四个动作在可视化工作流引擎里连成一条流即可，HTTP 请求节点直接对接企微接口。

标签只增不删也有问题：三个月不清理就会膨胀到几百个，统计口径随之失效。建议每季度盘点一次，把使用率低于 1% 的个人标签归并或下线。
零售门店尤其吃这套打法：母婴店可以按宝宝月龄建标签组，把换段奶粉、补货这类时间节点变成自动提醒，标签分层与周期购的完整做法见母婴店会员标签分层方案。

五、离职继承：把事故变成流程

员工离职是客户资产流失的最大单点。企微提供离职继承能力，/cgi-bin/externalcontact/resigned/transfer_customer 用于把离职成员的客户分配给接手成员，另有查询接替结果的接口（具体路径以官方文档为准）；客户侧通常需要确认。

落地时把"成员离职"做成一条标准流程，而不是临时手工操作：

冻结：把该成员名下关系全部置为"继承中"，防止继续产生新的跟进记录；
分配：按客户价值或地域，批量指定接手人；
确认：轮询或回调获取继承结果，成功则更新归属，失败进入人工处理队列；
留痕：历史跟进记录不迁移，通过关系表的历史状态可追溯原服务人。

同时在 CRM 侧配置行级数据权限：销售只能看到关系表中 userid 为自己的客户，主管按部门树查看下级，这条规则交给平台的行级权限配置，不必写在每个查询里。客户数据敏感，猫拽低代码（CatPull）以 Apache-2.0 协议开源并支持私有部署，external_userid、跟进记录与聊天摘要都可以留在企业自有服务器内。

FAQs

Q1：external_userid 能在不同企业之间复用吗？

A：不能。同一微信用户在不同企业主体下会得到不同的 external_userid；跨企业做客户归并需要 unionid，且要求绑定微信开放平台。把 external_userid 当作全局用户 ID 是典型错误。

Q2：客户标签在企微侧修改后，CRM 多久能同步？

A：走回调通常秒级到分钟级即可感知，但回调可能丢失或延迟。稳妥做法是回调触发即时拉取，再叠加每 30 分钟一次的增量对账。

Q3：客户被成员删除后，历史跟进记录要一起删掉吗？

A：不删。把关系状态改为已删除并保留记录，既满足交接追溯，也符合审计要求；物理删除会造成"客户明明服务过却查不到痕迹"的尴尬。