同一张「联系我」码如果配了多名员工，客户扫码后到底会加到谁，不能靠猜测「谁客户少就分给谁」，也不能把第三方活码工具上的自动切换说成企业微信官方规则。企业微信开发者文档「客户联系「联系我」管理」（页标最后更新 2026/10/08）写了多人类型和成员条件；官方帮助中心「如何添加客户」页则专门写了多人「联系我」二维码的客户分配规则。下面按2026年11月13日（北京时间）核读的这两页来看。帮助中心该页未见页标日期，分配规则以该页原文为准，不另作推算。

先分清这张码是单人、批量单人，还是多人

帮助中心「如何添加客户」在「联系我」一节写：企业超级管理员可在管理后台、客户与上下游、客户联系、加客户、联系我中，选择「联系我二维码联系」「通过工卡联系」或「在小程序中联系」，并设置绑定的成员。支持的设置类型有：批量单人、单人、多人。

三种类型不要混着读。单人：单个二维码或小程序的「使用成员」仅支持设置一个成员，设置后生成这个成员的单人二维码。批量单人：使用成员支持设置多个成员或部门，但设置后是批量生成这些成员各自的单人二维码，可通过压缩包下载——客户扫到的仍是某一个人的码，并不是同一张码在多名成员之间分配。多人：单个二维码或小程序的「使用成员」最多可配置 100 个成员，「多个客户扫码添加的时候会平分二维码中的服务人员」。

因此，只有类型确实是「多人」的那一张码，才涉及「客户会加到谁」的分配问题。若实际发出去的是批量生成的多张单人码，客户加到谁，取决于他扫的是哪一张，而不是多人分配规则。开发者文档把联系方式类型写成 type 为 1 表示单人、为 2 表示多人；单人时 user 必填且只能有一个，部门列表只在多人类型时有效。接口文档没有再写「批量单人」这一项，批量单人只出现在帮助中心对管理端类型的说明里。

多人码的官方规则是同等概率分配，不是按客户少的人优先

帮助中心单独列出了「客户联系多人「联系我」二维码的客户分配规则」：客户联系多人「联系我」二维码的客户分配规则是同等概率分配的。该页紧接着注明：这是指曝光的平均分配，不是实际加好友数的平均分配；也就是说，同一个二维码中每个成员出现在客户添加页面的机会是均等的，而不是客户越少的成员出现的机会越大。

前面「会平分二维码中的服务人员」这一句，要和这条注释一起读。官方没有把它写成按加好友数量补齐，本轮核读的页面也没有把分配方式写成可切换的轮询或按固定顺序选项。本轮同时打开过官方页「配置「联系我」」，该页说明了新建、展示和使用联系方式，但没有补充分配算法，本文不以该页为分配规则来源。

如果发现同一张多人码里，有的成员客户明显更多，帮助中心写了两种可能，而不是据此认为分配规则已经改成「谁少给谁」：其一，其中一个服务人员被添加在其他多人二维码中，这样被其他客户添加上的概率会高一点；其二，服务人员通过其他方式主动添加客户，比如分享个人二维码、在群聊中添加。也就是说，实际加到的人数，并不自动等于这张码上的曝光机会。

接口里还有一个「同一外部企业客户」的优先规则，不要和同等概率混成一句

开发者文档在配置参数里写了 is_exclusive：是否开启「同一外部企业客户只能添加同一个员工」，默认为否；开启后，同一个企业的客户会优先添加到同一个跟进人。这条只约束「同一外部企业」的客户，而且默认是关闭的。文档没有写它会不会改变普通微信客户的同等概率曝光，也没有把「优先同一个跟进人」解释成轮询或按顺序。核对「客户会加到谁」时，应先看这张码是不是多人类型，再看有没有开启这一项，并按原文把「外部企业客户」和普通添加场景分开，不要自行合并成一套新算法。

开发者文档还写：外部客户添加时是否无需验证由 skip_verify 控制，默认为 true。这只决定添加时要不要成员确认，不决定客户会被分配给哪一名成员。临时会话模式在该页写明仅支持配置为单人、暂不支持多人，因此也不适用于这张多人「联系我」码的分配问题。临时会话的默认有效期等字段，不属于本篇的分配规则，本文不展开。

使用成员本身也有条件和人数上限

即便类型已经是多人，也不等于名单里的每个人都会进入分配。开发者文档（页标最后更新 2026/10/08）在权限说明中写：配置的使用成员必须在企业微信激活，且已经过实名认证，且配置了客户联系功能；传入的成员和部门需要在此应用的可见范围内。参数注意还写：每个联系方式最多配置 100 个使用成员，包含部门展开后的成员；party 或 user 必须在应用可见范围或客户可建联的成员范围内。帮助中心对多人类型也写了「最多可配置 100 个成员」，与接口页一致。100 人是这两处写明的使用成员上限。无日期介绍页上另有 200 人、5 个群、7 天或「永不过期」等说法，不是本轮这两份官方说明给出的现行硬阈值，也不能拿来理解这张「联系我」码会分给谁。

如果通过接口配置，还要注意文档写的其他边界：通过 API 添加的「联系我」不会在管理端展示；每个企业可通过 API 最多配置 50 万个。这些只说明去哪里核对使用成员，不改变上面的分配规则。帮助中心还写，管理端里单人加多人两种类型的二维码数量总上限是 1000 个，但该页没有页标日期，本文仅原文备查，不以它替代接口页已标注日期的 100 人上限。本文未登录管理端或调用接口实测。

同一张码给多人用时，可以按这个顺序核对

- 这张码的类型是单人、批量单人，还是多人；批量单人发出去的是多张单人码，不适用多人分配规则

- 多人类型下，官方写的是同等概率、曝光平均分配，不是按现有客户数少的人优先，也不是实际加好友数平均

- 接口是否开启了「同一外部企业客户只能添加同一个员工」；该项默认关闭，且只写了同一外部企业客户会优先同一跟进人

- 使用成员是否已激活、已实名、已配置客户联系功能，是否在可见范围或可建联范围内，加上部门展开后是否超过 100 人

- 成员实际客户数差距较大时，先核对该成员是否还出现在其他多人码中，或是否通过个人码、群聊等其他方式主动添加，而不要反过来改写官方分配规则

同一张「联系我」码给多名员工用，客户会加到谁，官方帮助中心写清的是同等概率出现在添加页面，而不是谁客户少就分给谁。先确认类型真的是多人，再核成员条件和 100 人上限，需要时再看「同一外部企业客户」这一项是否开启。第三方活码产品页上的多账号切换或永久有效等宣传，与上述官方说明不是同一套规则，不能用来解释这张码的分配方式。

参考资料

[1] 企业微信开发者中心：客户联系「联系我」管理 https://developer.work.weixin.qq.com/document/path/92228，最后更新 2026/10/08，访问日期 2026-11-13（北京时间）。本文依据该页关于管理后台-客户联系-加客户中可配置「联系我」、也可通过接口生成，type 为 1 表示单人、为 2 表示多人，单人时 user 必填且只能有一个，部门列表只在多人类型时有效，每个联系方式最多配置 100 个使用成员（含部门展开后的成员），使用成员须激活且已实名并配置客户联系功能，传入的成员和部门须在应用可见范围内，party 或 user 须在应用可见范围或客户可建联的成员范围内，is_exclusive 默认否、开启后同一个企业的客户会优先添加到同一个跟进人，skip_verify 默认为 true，以及临时会话模式仅支持单人、暂不支持多人，通过 API 添加的「联系我」不会在管理端展示、每个企业可通过 API 最多配置 50 万个等表述。该页未写多人码的同等概率或曝光平均分配规则。

[2] 企业微信帮助中心：如何添加客户 https://open.work.weixin.qq.com/help2/pc/20169，页面未见页标日期，访问日期 2026-11-13（北京时间）。本文依据该页「联系我」一节关于单人、批量单人、多人三种类型，多人最多可配置 100 个成员，「多个客户扫码添加的时候会平分二维码中的服务人员」，以及「客户联系多人「联系我」二维码的客户分配规则是同等概率分配的」：指曝光的平均分配，不是实际加好友数的平均分配；同一二维码中每个成员出现在客户添加页面的机会均等，而不是客户越少的成员机会越大；并转述该页对客户数量差距较大的两种说明。该页还写管理端单人加多人二维码总上限 1000 个，因无页标日期仅原文备查。该页链至上条接口文档。

[3] 企业微信：配置「联系我」 https://work.weixin.qq.com/wework_admin/contactplugin/guide，页面未见页标日期，访问日期 2026-11-13（北京时间）。该页说明可在管理后台-客户联系-「联系我」中新建二维码、工卡或小程序三种联系方式，以及展示和使用方式；未写多人分配规则，本文不以该页为分配算法来源。