客户公海池怎么设计？回收与再分配规则

公海池要解决的是一个很具体的问题：客户资源属于公司，不属于个人，但跟进效率又依赖个人的积极性。这两件事本身是矛盾的——如果不设回收机制，客户会被长期占着不动；如果回收得太狠，销售会不敢投入，反而伤害成交。

所以公海池设计的难点从来不是"要不要做"，而是规则怎么定才既不养懒人、也不逼走认真跟单的人。这篇按两类规则讲：回收规则和领取规则，然后讲几个常见坑。文中有一组来自生产环境的实测配置参数，可以作为对照参考；其余关于规则形态与常见问题的内容来自公开的行业资料。

一、为什么需要公海池

先看一个实测漏斗。某生产环境中的数据显示：线索 8495 条、客户 656 个。线索到客户的比例大约 13:1——大部分线索没有转化。这么多线索里，显然有相当一部分是"当时没成，但未必永远不成"的客户。

公海池的价值就在这个区间里。公开资料把它归为三点：

• 提升线索利用率：很多客户不是没需求，只是跟之前的销售不对路。换个人跟进可能就成了，公海池让客户有机会被再次触达。
• 激活销售积极性：对新人来说公海是资源库，不必完全依赖上级分配；对老人来说回收机制是一种鞭策，不认真跟进机会就会飞走。
• 数据透明化：所有进入公海的客户，其流转记录与跟进历史都可追溯。管理者能看到哪类客户容易掉入公海，是产品问题还是话术问题。

但这里有个前提：公海里的客户应该是"暂时未成交"，而不是"完全无效"。如果掉进去的全是打不通的空号、明确拒绝的客户，公海池就变成了死海——没人愿意捞，机制自然失效。反过来，当线索量明显超过团队的消化能力时（比如助贷团队怎么提升日呼量里讨论的那种加班也打不完的量级），公海池的价值会立刻体现出来。

二、两类规则，缺一不可

公海池由两套规则驱动：回收规则（什么时候把客户从私海扔回公海）与领取规则（谁能从公海捞走、能捞多少）。公开资料里有一句总结很到位：公海池只有回收动作、没有规则体系，那就只是菜市场；规则的完整性决定了它是不是一套资源调度系统。

这六条参数可以分成三组来理解：

• 回收规则组（无跟进天数、最大持有数量）——目标是让客户流动起来，防止资源被锁死；
• 领取规则组（每日领取上限、领取冷却期）——目标是防止囤积与"扔了再捡"的套利行为；
• 保护规则组（跟进记录要求、成交保护期）——目标是保护认真跟进的人，同时确保客户处于被服务状态。

三组缺任何一组都会失衡。只有回收没有保护，销售不敢投入；只有保护没有回收，资源会被占死；只有回收和保护没有领取限制，公海会被少数人刷走。这三组规则共同构成客户流转的调度层，它与进件、商机等业务链路的衔接方式，可参考助贷进件管理系统怎么做里关于节点交接的部分。

三、回收规则：不要用同一个天数管所有客户

回收是公海池里最敏感、也最容易吵架的一环。公开资料里反复提到同一个教训：用统一天数管所有客户，一定会误伤。有公司规定"7 天不成交就回收"，结果销售为了保住客户疯狂骚扰，本来能成的单被吓跑了；也有做大型设备的企业销售周期长达半年，私海限制太死，销售根本不敢把长期培育的客户放进来，因为一旦掉入公海半年的跟进就白费了。

更合理的做法是按客户所处阶段分档。一组实测配置可以说明这个思路：

这组分档设计的逻辑很清楚：回收天数对应的是"这个阶段正常应该多久有一次推进"。刚接触的客户（首访）给 7 天——如果一周内都没有接触上，大概率是联系不上；已经聊过几轮的客户（复访）给 14 天——沟通周期本身更长，太过紧迫反而催出敷衍的跟进；进入尽调阶段的客户只给 3 天——已经到这一步说明双方都在实质推进，三天没有动静就是异常信号，值得尽快检查。

除了按阶段分档，回收的触发条件还有几类值得配置：

• 时间触发：超过设定天数没有成交或推进；
• 动作触发：连续若干天没有填写跟进记录，或没有实质的沟通动作；
• 状态触发：销售主动把客户状态改为"无意向"，直接退回公海；
• 离职触发：员工离职时名下客户一键回归公海，由主管重新分配。

最后两类容易被忽略但很重要。状态触发是销售主动释放的通道——如果没有这条通道，销售会倾向于"挂着不管"而不是"明确放弃"，公海里就会少了很多本该被重新激活的客户。离职触发则属于刚性要求：客户资源随人走是最典型的资产流失方式，具体做法可参考助贷机构怎么防止离职员工带走客户。

还有一个细节值得加：回收前自动提醒。在客户即将被回收前主动提示销售"这个客户即将回收"，给一次最后跟进的机会。公开资料里把这条列为减少误回收的有效手段——把客户的最后一次沟通从"被回收后才发现"变成"回收前主动处理"。

还有一个必须提前定好的问题：被回收的客户后来成交了，业绩算谁的。这个答案会直接影响销售对回收机制的接受度。常见做法分两种：一种是分段认定——客户被回收前的跟进贡献按约定规则计入原负责人（比如首次接触与前期沟通的贡献），成交业绩归实际成交人；另一种更简单——一旦进入公海即与原负责人无关，业绩全部归新负责人。两种都可行，但必须事前明确、系统留痕，而不是事后靠争论决定。这类争议一旦反复出现，回收机制的执行力就会被消耗掉。

另外需要设置最长持有期：即使一直在跟进，如果超过约定时长仍未成交，也应当回收。实测配置中有一项"跳过周末、跳过节假日"的开关，作用是把回收计时按工作日计算，避免客户因为放了个假就被回收。

四、保护期与冷却期：两个容易混淆的概念

这两个概念都涉及时间，但方向相反，经常被混为一谈：

保护期保护的是销售——客户刚分配到他名下的一段时间内，其他人不能抢走，销售可以安心跟进。实测配置里的客户持有上限为 50 个，超出后需要先处理已有客户才能继续认领。公开资料里还提到一种弹性设计：基础容量之外，业绩达标的可以向上扩容（比如从 100 个放宽到 150 个），或者对资深销售给更大的额度，因为长周期复杂订单本来就需要更多在跟客户。

冷却期保护的是规则本身——防止销售故意把客户扔回公海再自己捡回来，以此刷新保护期、规避回收规则。实测配置里这一项是 15 天：客户被退回公海后，15 天内不能被原负责人重新领取。公开资料里也有更短的版本，比如"原负责销售 7 天内不可再次领取"，或者"24 小时内拥有优先赎回权"。

这两种思路的差别值得注意：

• 优先赎回权（短）适合手误场景——销售误操作把客户退了，可以快速找回，不影响跟进连续性。
• 长冷却期适合防止规则套利——如果原负责人可以随时捡回来，那么"回收"就变成了一次免费的保护期刷新，规则形同虚设。

实测配置选了后者（15 天）。这个选择的前提是系统支持"操作确认"或"退回二次确认"，手误的概率被前置消掉了，所以可以把冷却期设得长一些来防套利。如果你的系统没有误操作防护，那"24 小时优先赎回 + 之后进入长冷却"的组合会更稳妥。

五、领取规则：抢单、分配还是混合

客户掉进公海之后，谁能捞走？公开资料里归纳了三种模式：

三种模式的选择没有标准答案，取决于团队特征：新人多的团队更适合轮转分配（保证每个人有饭吃，避免新人没资源），成熟团队适合标签匹配或混合制（效率优先）。

无论选哪种模式，下面三项限制都应当配置：

• 每日认领上限。实测配置中，普通成员每日可认领 20 个、主管与管理员各 10 个。公开资料里的常见区间是每人每天 5 到 10 个。这一项的目的是防止有人大量领取却不跟进——领了不跟，等于把公海变成了第二个私海。
• 持有数量上限。实测是每人最多锁定 50 个客户。想领新的就得先把旧的推进或释放，这是"逼着你把资源用在刀刃上"的机制。
• 重复与撞单校验。同一客户已有人认领即锁定，避免两人同时跟进撞单。查重规则本身是一套独立机制，在后续专门讨论撞单判定时会展开。

有一点需要提醒：上限值不能一刀切。实测配置中普通成员的上限（20）高于主管（10），这个安排是有道理的——主管的主要精力在管理与协助，不必占用太多客户；而一线成员需要足够的在跟客户量来维持产出。如果反过来设置，会出现"主管手上客户多但没时间跟、一线成员想领却领不到"的错配。

六、"有效跟进"怎么判定：防造假是必需项

回收规则能不能生效，取决于系统怎么判定"有效跟进"。这是整个机制里最脆弱的一环，因为只要判定标准模糊，销售就会用最低成本应付——公开资料里点得很直接：为了不让客户掉入公海，销售可能会随便填个"已联系"敷衍系统。

可靠的判定方式是把跟进与真实动作绑定，而不是与"填写行为"绑定：

• 通话记录自动挂靠：跟进记录不是手写的，而是通话结束后由系统自动生成，包含通话时间与时长。这样"填了记录但没打电话"这种情况就不存在了。录音的挂靠与调阅机制，在助贷通话录音怎么管理里有完整说明。
• 通话时长门槛：只有达到一定时长的通话才计为有效跟进。响两声就挂断的呼叫不应该让客户从"停滞"状态中解套。
• 阶段推进作为独立证据：客户不仅要有跟进记录，还应从当前阶段推进到下一阶段。这条与商机阶段模型的"没有证据不许推进"是同一套逻辑，相关内容可参考助贷商机管理怎么设计。

把这三条组合起来，跟进状态的判定就从"销售自己说"变成了"系统能看到"。这也顺带解决了一个管理问题：管理者不需要怀疑某个销售有没有认真干活，系统数据本身就是答案。

七、最容易踩的四个坑

坑一：抢单内耗

公海客户谁都能领，销售拼手速、拼网速，领完又互相撞单。根源是认领规则不清晰或分配规则缺失。解法有三条：设置认领上限、撞单拦截（已认领即锁定）、按标签定向分配。公开资料还提到一个更彻底的思路：高意向、高价值的客户走系统自动分配，不走手动抢单，从机制上杜绝恶性竞争。

坑二：僵尸数据泛滥

公海里堆满无效号码和错误信息，销售领了白领。这里的根源在于回收时没有做数据校验。解法是：回收前校验客户有效性（联系方式是否可达、需求是否真实），无效客户直接进废单库而不是进公海；同时给公海客户标注来源与回收原因，让销售在认领之前就能判断值不值得跟。

这一条与第一节讲的前提是同一件事：公海应该只接"暂时未成交"，不接"完全无效"。

坑三：分配不公

好客户总被同一批人领走，新销售拿到的都是边角料。解法是用规则分配替代自由认领，配合轮转与负载均衡；同时用"按价值与意向度排序展示"代替无序列表，让销售自己也能看清手里的机会分布。公开资料里有一条设计细节很实用：公海客户列表按价值、意向度排序，销售领客户有据可依。

坑四：销售抵触，规则变成一纸空文

这是最根本的坑，而且它不在技术层面。公开资料里说得很直接：强制回收客户会被销售视为"抢食"；如果老板看到回收规则就心软，特批"这个客户再留一个月"，那整个机制瞬间崩塌。规则一旦可以被特批，它的威慑力就归零了。

应对方式有两条：一是规则要经过销售团队讨论后再定，让执行方有参与感；二是规则确实要留出弹性通道——比如长周期客户可以申请延长保护期，但必须走主管审批，让它成为规则内的例外，而不是规则外的特批。这两条结合起来，规则才既严格又可执行。规则定得合不合理，同样可以在试用期里用小范围真实数据验证，验证思路可参考助贷CRM免费试用怎么申请。

另外还有一个反向的坑：只收不放，公海变死海。如果回收的客户长期无人认领，说明前端线索质量或公海定价有问题，需要市场与销售两侧对齐线索标准，而不是继续往里扔。

八、常见问题

Q1：回收天数到底设多少合适？

没有通用答案，但有两个判断依据。一是业务周期：快消类、低客单价的业务决策周期短，回收周期可以设得紧一些（15 天或 30 天）；长周期大额业务要放宽，否则销售不敢投入。二是客户所处阶段：如第三节所示，首访、复访、尽调三个阶段适用的天数完全不同，按阶段分档比统一设置合理得多。设置完成后建议观察一个周期，看回收的客户里有多大比例是"其实还在正常跟进"的——如果这个比例偏高，说明天数过紧。

Q2：客户刚分配就被回收，销售会不会有意见？

会有，所以要配套两个机制：一是回收前提醒，让销售在客户被回收前收到通知并有机会处理；二是保护期，新分配的客户在保护期内别人无法抢走，销售可以安心跟进。这两条加起来能消化掉绝大部分抵触情绪。需要强调的是保护期不宜过长——保护期太长等于变相取消了回收机制。

Q3：公海客户被领走后又被退回，历史记录会丢吗？

不应该丢，这是公海机制能不能长期有效的关键。公开资料里有一条明确的设计要求：回收的客户自动带出跟进历史与回收原因，方便下一个销售判断是否值得再跟进。如果每次回收都清零，接手的人要从零开始了解客户，触达效率会大打折扣——而这恰恰是公海池想要改善的问题。系统设计上，跟进历史应当挂在客户对象上，而不是挂在"某次分配"上。

Q4：公海池和撞单是同一个问题吗？

相关但不是同一件事。公海池解决的是"资源怎么流动"，撞单解决的是"同一客户被多人同时跟怎么办"。两者的交集在于领取环节——如果认领时不做查重与锁定，公海池会直接制造撞单。所以撞单拦截应当是领取规则的一部分，而完整的撞单判定规则（包括判定依据、时间窗口、争议仲裁）是另一套机制，需要单独设计。

Q5：小团队也需要公海池吗？

取决于线索量与人员规模。如果是三五个人的团队、线索量也不大，客户被长期占着不动的概率不高，公海池的收益有限，维护规则的沟通成本反而不小。但如果线索量明显大于团队消化能力（第一节那组 13:1 的数据就是典型场景），那么"没有人跟的客户"就是实实在在的损失，公海池的价值会立刻体现出来。判断标准可以简化成一句：有没有一批客户，暂时没人跟，但换个人跟是有机会的。有，就值得做。

九、小结

把这篇的要点收一下：

• 公海池要解决的是"资源属于公司、效率依赖个人"这对矛盾，目标是让客户流动起来而不伤害跟进积极性；
• 规则分三组：回收规则（无跟进天数、最大持有量）、领取规则（每日上限、冷却期）、保护规则（跟进要求、成交保护期），缺任何一组都会失衡；
• 回收天数要按阶段分档（实测口径：首访 7 天、复访 14 天、尽调 3 天），统一天数必然误伤；
• 回收触发有四类：时间、动作、状态、离职。后两类容易被忽略但对资源流转很关键；
• 保护期与冷却期方向相反：保护期保护销售不影响跟进，冷却期防止"扔了再捡"刷新保护期；
• 领取模式有抢单、分配、混合三种，配上限（认领上限、持有上限）与撞单锁定；
• "有效跟进"必须与真实动作绑定（通话自动挂靠、时长门槛、阶段推进），否则规则会被"随便填个已联系"绕过；
• 最大的坑不是技术：规则一旦可以被特批，机制就失效了。

最后给一个判断标准：一套公海池规则是否合理，可以问三个问题——客户在什么条件下会被收回、收回之后多久能被重新认领、"有效跟进"由谁说了算。三个问题都有明确答案，规则就是可执行的；有一个含糊，实际运转中就会变成人为博弈。公海池是客户管理里最"动人心"的一块，因为它直接触及资源分配——所以它比任何其他模块都更需要规则前置、参数可配，而不是上了系统之后边跑边吵。关于客户资源归属的整体设计，可以参考助贷防飞单系统的六个必备能力与助贷机构为什么需要客户管理系统两篇。