WhatsApp客服号码清洗步骤：格式规范、开通检测与CRM回写

客服团队手上的号码名单通常是多年积累下来的：工单系统导出的来电号码、售后登记表、门店留资、老 CRM 迁移过来的数据。要把它导入 WhatsApp 客服渠道或 CRM，清洗要达到的结果很具体：每个号码格式统一、没有重复、知道它有没有开通 WhatsApp，而且结果能回写到对应的客户记录上。

推荐的处理顺序：

备份原表，每行保留客户 ID 和原始号码；
按国家把号码转成 E.164 国际格式，单独处理阿根廷、墨西哥等特殊编码；
按转换后的号码去重；
按国家分批检测 WhatsApp 开通状态；
读懂字段，按已开通、未开通、待核实分组回写 CRM。

顺序最好别颠倒。格式没统一就去重，同一个客户的 07911123456 和 +44 7911 123456 会被当成两个号码；格式没统一就检测，一部分本来已开通的号码会因为格式问题被判成无效。

WhatsApp客服号码清洗五步顺序：保留原始值、E.164转换、去重、开通检测、分组回写CRM

第一步：保留原始值，再动手清洗

先确保表里有两列不做任何改动：客户 ID 和原始号码。后面所有转换都写进新列。这样检测结果回写时能按客户 ID 对上；某个号码转换出错，也能回到原始值重新处理。

客服名单里常见的问题有：

带本地前导 0 或长途前缀，没有国家代码；
混着空格、横杠、括号，或者“ext.”“转”之类的分机标记；
一个单元格里填了两个号码，比如手机和座机写在一起；
国家代码重复或写错，例如 +86 86 138…。

分机号要拆到单独的列，两个号码要拆成两行或两列，不要直接拼进号码里。

第二步：转成 E.164 格式，特殊国家单独处理

WhatsApp 按完整国际格式识别号码：加号、国家代码、区号和本地号码，并去掉本地拨号用的前导 0 和长途前缀。保留前导 0 或本地拨号前缀，号码就可能识别失败。比如英国号码 07911 123456，应写成 +44 7911 123456。

补国家代码时，优先用名单里已有的依据：客户所属地区、来源门店或业务线、账单地址。号码本身没有国家代码、表里也找不到其他线索的，不要按主业务国统一补，先放进“待核实”组。

WhatsApp 帮助中心对两个国家给了额外规则：

阿根廷（+54）：国家代码和区号之间要加 9，并删掉本地手机号前的 15，最终是 13 位数字，形如 +54 9 XXX XXX XXXX。
墨西哥（+52）：国家代码后保留 1，形如 +52 1 XXX XXX XXXX。

如果你用的检测工具或客服系统对这两个国家有自己的输入要求，以它们的文档为准。

多国名单建议先按国家拆成多个文件，逐个国家核对转换规则，再分别提交检测。拿不准某个国家的号码长度和前缀，可以在 NexCheck 区域方案页查对应国家的号码格式。完整的转换规则可以参考 WhatsApp E.164格式转换规则。

第三步：按规范号码去重

去重放在格式统一之后，按 E.164 号码比较，而不是按原始字符串。

一个号码对应多个客户 ID 的情况在客服数据里很常见，比如家人共用一个号码、企业总机。这时不要直接删重复行，而是保留“一个号码对应多个客户 ID”的关系：检测只跑一次，结果回写到所有关联记录。这样既不会重复计费，也不会丢客户。具体做法见 WhatsApp号码去重怎么做。

第四步：检测 WhatsApp 开通状态

不建议等客服系统自己报错再处理。Meta 开发者社区的讨论提到，WhatsApp Business API 早期能批量确认号码的 contacts 端点已经弃用；对未注册号码发起的消息会直接报错，模板消息返回 1013（User is not valid），会话消息通过 Webhook 返回 470。对客服团队来说，没清洗的号码导进去，就会变成分配了坐席却联系不上的工单，还会带来重试和排查负担。

比较稳妥的做法是在导入前单独检测。以 NexCheck 为例：把清洗好的文件按国家上传到控制台（txt 或 csv），或者通过 REST API 提交，结果按有效和无效分组返回；走 API 的可以用 Webhook 接收结果。WhatsApp 能检测哪些字段、各项怎么计价，以 WhatsApp 平台页为准。检测项和单价会调整，不同平台能查的项目也不一样。

字段怎么选：客服分配通常只需要开通状态。想把空号、高风险号一并筛掉，可以叠加号码基础检测。检测按条计价，按用途选项目就行，不必一次全选。

控制台还是 API：一次性清理历史名单，用控制台上传最省事；新客户持续进入 CRM、需要入库时就检测的，用 API 提交加 Webhook 回推更合适，接入步骤见 WhatsApp批量验证API怎么接。