CRM 公海池的号码治理：回收线索先过状态这一关
线索掉进公海池，几个月无人负责，捞上来一半打不通。本文讲公海池为什么特别容易攒死号、入池打标和出池复测这两道关卡怎么设、按号码状态给公海池分层的做法，以及二次放号误打的合规边界。
约 1400 字🎁 免费试用 手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
销售三个月没跟进的线索，系统会自动回收进公海池。公海池是个开放的大池子，谁先点谁得。
运营最近发现一个怪现象：捞取量不低，首拨接通率却一直在往下走。销售的说法倒是很一致——池子里的号，一半是死的。
自营客户池有人负责，号码状态有人管。公海池恰恰相反，它是「没人负责」的集合。
一条线索从 A 销售手里回收，掉进池子；B 销售捞走，跟了两周没进展，又掉回去；再被 C 捞走。每一次流转之间都有一段真空期，短则几天，长则几个月。号码就是在这些真空期里慢慢失效的：客户换了号、停机、销户、变空号。
更麻烦的是，池子里的号码没人定期刷状态。你捞到的可能是三个月前还好好的号码，而系统里没有任何一列告诉你，它已经不行了。
「联系方式」这四个字太笼统。落到号码上，其实是三类不同的问题，处置方式完全不一样：
- 失效：空号、不在网。号已经不在服务状态，怎么打都到不了；
- 占用：欠费、长时间关机。号还在，只是当下摸不到人，属于有希望的一类；
- 错配：号码被回收后重新放给新用户，你打过去，接的已经不是原来那位客户了。
前两类是效率问题——白费工时。第三类是合规问题——打给无关的人，可能被投诉骚扰。公海池因为流转周期长，错配的概率比自营池高得多。
治理思路不复杂，关键卡在两个节点上。
入池时打标。 线索被回收进池，先做一次号码状态核验，把状态写进线索字段。这一步的作用是给池子里的号建一份底档，让后面捞取的人一眼看到这条线索的号码属于哪一类。
出池时复测。 捞取动作发生的那一刻，再核一次。原因还是时间——从入池到被捞，中间隔了多久没人说得准。只看入池时的旧状态，等于拿过期的信息做决策。
串起来就是：线索回收 → 状态核验打标 → 入公海池 → 捞取触发复测 → 按状态分流跟进。
这两步用【手机号在网状态 API】这类直连三网的服务批量完成，按次计费，结果回写线索字段，不需要人工一条条试。接入方式与返回字段以商品详情页文档为准。
核验结果不该只挂一个字段，最好直接决定这条线索进哪个池子。一个常见的分法：
| 状态 | 进哪个池 | 跟进策略 |
|---|---|---|
| 正常、通话中 | 可捞池 | 正常分配，首拨加短信双通道 |
| 欠费、长时间关机 | 观察池 | 降低单人捞取上限，错峰重试，短信通道慎用 |
| 无短信能力 | 可捞池（打标） | 跟进话术不得把短信当兜底 |
| 空号、不在网 | 资料池 | 移出动态捞取，转资料补录，别占销售工时 |
把失效号码挪进资料池这一条最容易被忽略。它在系统里仍然算「一条线索」，但对外呼来说已经不是可跟进对象了。留在可捞池里，只会被反复捞起、反复放弃。批量核验一遍之后，用【手机号在网状态 API】的结果直接驱动这条分池规则，比让销售凭手感挑要靠谱。
下面几条能直接翻译成系统规则（示意，按自家系统配置，别照抄数值）：
线索回收进池时强制核验一次状态并写入字段；捞取动作触发时对状态做一次复测，超过设定时长的记录自动重核；连续两轮被捞取且都没联系上的线索，降权或移入观察池；空号、不在网的线索不再进入动态捞取。
这套分层和销售线索去重可以配套用：先去重、再核状态，能省掉一批重复号码的核验成本。号码活跃度怎么进客户画像，客户画像里的号码状态标签里有更完整的讨论。
状态查询返回的是号码能否正常使用，不返回机主身份。公海池的号码来自企业自有或合法取得的线索，用途限于内部跟进，核验记录也只能内部留存。
二次放号带来的错配，是池子治理里最需要防的一条：号码失效后重新放号，你还按老线索打过去，接的是新用户。所以号码在池子里放得越久，出池复测越不能省。这不是流程设计得啰嗦，是把「可能打错人」的概率压下去。
文章评论
发表评论
请先注册/登录后评论