CRM 电话号码原始归属运营商查询：添加原始运营商与线路类型字段

本指南旨在为 CRM 运营团队提供字段设计与工作流建议，通过同步查询和文件任务，将原始运营商、底层运营商、号码类型及分配地区等信息添加到联系人记录中。

在 CRM 中进行电话号码原始归属运营商查询，可为每个联系人补充分配背景信息：即该号码段最初分配给的运营商、当品牌运行在其他网络上时的底层运营商、移动或固定电话等号码类型，以及分配的地区和城市。实际操作分为三个部分：创建命名清晰的自定义字段、在有新记录时运行同步查询，以及通过文件任务对现有数据库进行一次性处理。空值应存储为“无法判定”，且所有字段应仅作为分组和审查的参考背景，而非联系人可触达性的证明。

在进行任何电话号码原始归属运营商查询前设计 CRM 字段

大多数关于此主题的指南直接跳到调用 API，而忽略了字段设计。字段名称决定了同事们在多年后如何解读这些数据，因此请务必先确定字段名称。

请在标签中使用“原始”和“分配”字样，以确保不会有人将运营商误读为当前网络，或将地区误读为联系人的居住地。在 HubSpot 中，属性字段类型（如单行文本、下拉选择和日期选择器）涵盖了所有这些需求；Salesforce 则通过自定义字段提供相应功能。

为查询准备电话字段

查询的质量取决于输入数据的质量。在首次运行前，请检查 CRM 中电话号码的存储方式：

1. 选择一个源字段。 联系人通常有“电话”、“手机”和一个自由文本的“其他”字段。请决定使用哪一个字段进行查询，或者为每个字段创建一个查询记录。
2. 标准化为 E.164 格式。 去除空格和标点符号，删除国家长途前缀，并添加加号和国家代码，例如 +447700900123。该格式定义在 ITU-T Recommendation E.164 中。
3. 将标准化后的值与原始输入分开存储，以便销售人员仍能看到联系人最初输入的内容。
4. 在号码层面去重，确保多个联系人共享的同一个号码只需查询一次，并将结果写回给每个联系人。
5. 记录每个号码的国家/地区（通过国家代码识别）。同步查询不需要此信息，但文件任务需要。

无法标准化的记录应保持“未查询”状态并注明原因，而不是直接发送导致被拒。

新记录：CRM 工作流中的同步查询

新联系人通过表单、导入或集成逐个进入系统，因此同步查询最为适用。典型模式包括：

• 工作流 Webhook 或中间件。 当记录创建或其电话字段发生变更时，您的集成服务器调用 POST /api/v1/check 查询单个号码，并将结果写回 CRM 字段。
• 定时微批处理。 每隔几分钟收集新记录，并将 1–100 个 E.164 号码发送至 POST /api/v1/batch-check。结果将按输入顺序返回，因此请根据位置或发送的号码将其匹配到记录中。
• 人工审查。 运营人员可以将最多 500 个号码粘贴到仪表板的实时批量区域进行快速抽查。

请将 X-API-Key 保存在您的集成服务器上；切勿将其放置在 CRM 客户端脚本或浏览器扩展中。公共 API 文档规定了少量共享的并发槽位，且每个账户一次仅限一个多号码请求，因此请对查询进行排队，而不是在大规模导入期间为每条记录触发一次查询。

现有数据库：每个国家/地区一个文件任务

对于存量数据，请导出标准化后的号码，并将其作为文件任务处理，而不是进行数千次同步调用。

1. 按国家代码分组。 文件任务使用选定的国家/地区，且该范围之外的行将被排除，因此请按国家/地区进行导出。
2. 每行写入一个号码，使用 TXT 或单列 CSV 格式，仅包含数字和国家代码。
3. 提交文件：在仪表板上提交，或使用 POST /api/v1/bulk-tasks，在多部分请求中先发送国家/地区，再发送文件。
4. 轮询 GET /api/v1/bulk-tasks/{id}，频率不超过每 30 秒一次。
5. 下载 CSV：针对每个成功的任务下载 CSV 文件并导入 CRM，通过纯数字标识符与您的标准化字段进行匹配。

预处理会移除无效行、重复项和没有国家代码的号码，这些被排除的行不会被计费。列表大小和文件大小受各产品限制，因此在决定如何拆分大型导出文件前，请查阅 API 文档。对于仅支持同步查询的国家/地区（如中国大陆、香港和澳门），应通过同步路径进行处理。

正确处理空值和无法判定结果

在电子表格中，三种结果看起来很相似，但在 CRM 中含义不同：

在同步多号码请求中，没有正常结果的行应归入“无法判定”类别，而不是列入无效号码列表。切勿用后续“无法判定”尝试返回的空白值覆盖之前已有的正确值。失败或无法判定的查询不会扣费，因此进行有限次数的重试（例如一天内尝试几次）是合理的。

在细分和报告中使用新字段

字段就位后，CRM 团队通常会构建：

• 按号码类型细分，以便将固定电话联系人分配到基于呼叫的序列，将移动号码段分配到需要手机号码的渠道。
• 运营商分组，用于比较消息服务提供商的送达报告，并牢记携号转网的号码仍属于原始运营商分组。
• 审查队列，用于在进行高价值外呼前，对状态为“已完成（空值）”或“无法判定”的记录进行检查。
• 数据质量仪表板，显示按国家/地区划分的已查询、已完成和不可用记录的占比。

这些字段支持分组和审查决策。它们不能证明联系人可触达、号码属于指定人员，或联系人已同意被联系，因此同意和所有权检查应保留在各自的字段和流程中。

常见问题解答

CRM 团队应多久对现有记录重新运行一次运营商查询？

原始归属运营商描述的是号码段，不会因号码携号转网而改变，因此频繁进行全量刷新意义不大。仅在以下情况重新检查记录：电话号码发生变更时、存储状态为“无法判定”时，或查询日期已久远且团队需要为特定活动获取最新背景信息时。使用查询日期字段可以轻松筛选，仅检查已变更或状态为“无法判定”的记录可保持较低的调用量。

当联系人表示他们更换了网络时，CRM 是否应覆盖原始运营商？

不应覆盖。原始运营商字段描述的是该号码段最初分配的运营商，即使在携号转网后也不会改变。如果联系人当前使用的网络对您的团队很重要，请将其记录在带有独立来源和日期的单独字段中，例如来自联系人的备注。将这两个值分开存储，可防止报告将分配背景信息与用户自述信息混淆。

团队如何将 AI 助手连接到相同的查询数据？

官方 MCP 端点允许 AI 助手运行单个或 1–100 个号码的同步查询并读取余额，使用与 REST API 相同的账户和限制。它不提供文件任务工具，因此数据库范围的刷新仍应通过仪表板或批量 API 进行。助手适用于记录审查期间的临时查询，结果由人员或集成写回。

了解更多

选择符合您工作流下一步的产品信息。

• 查看产品文档 →
• 联系团队 →