CRM 电话号码数据清洗：导入前检查清单
在将联系人列表导入 CRM 之前，请准备好电话字段、国家/地区数据、重复项检查及号码分配背景信息。
在将联系人列表导入 CRM 之前，请准备好电话字段、国家/地区数据、重复项检查及号码分配背景信息。
CRM 电话号码的数据清洗工作在点击导入按钮之前就已经开始了：保留原始值，确定每条记录的国家/地区，将号码标准化为 E.164 格式，审查重复项，然后仅附加查询实际返回的分配背景信息。请明确标注不可用的查询值。这一流程使导入的列表更易于审计，并避免将格式修正或原始归属运营商查询结果误解为关于某个人或某条线路当前状态的结论。
保留原始数据并选择电话字段
导出联系人列表的工作副本，并保留一个稳定的源记录键。原始电话值应存放在一列中，清洗后的值存放在另一列。如果 CRM 系统支持，请在单独的字段中包含国家/地区、联系人所有者、最后更新时间和许可来源。这样可以在必要时审查变更，并将错误的导入追溯到其来源。
确定团队正在清洗哪个电话字段。一条记录可能包含主线、移动电话线路和总机分机号。请勿将分机号合并到标准化的国际号码中。如果源行同时包含移动电话和办公电话，请勿用通用办公号码静默覆盖已知的移动电话字段。如果 CRM 只有一个通用电话字段，请记录哪个输入项具有优先权，以及另一个号码将存储在何处。
电子表格可能会扭曲电话标识符。Microsoft 的指南建议使用文本格式来保留前导零和长数字字符串。如果电子表格已经丢失了数字，更改单元格格式将无法恢复它。请将可疑行与上游导出文件进行比对，而不是猜测替换值。
在去重前标准化国家/地区和 E.164 格式
E.164 提供了 ITU-T Recommendation E.164 下的国际编号结构。对于 CarrierLookup 的实时输入，请提交带有前导加号、国家代码和用户号码的格式，且不含空格或分隔符。首先分配一个可信的国家或编号区域。没有该背景信息的本地格式号码无法进行转换。
在辅助字段中删除视觉标点符号，然后针对任何国家拨号前缀应用特定国家的规则。请勿通过通用规则删除前导零；请确认它是否为该国编号计划中的主干前缀。已经包含加号和国家代码的号码不应再添加国家代码。标记模棱两可的行，并将清洗后的字段留空，直到经过审查。
只有在标准化之后，团队才应比较电话号码以查找重复项。两个视觉上不同的原始字符串可能会标准化为同一个国际号码。保持所有关联的联系人记录可见：重复的号码可能是共享的业务线路或数据错误，关于重复项的决定不应自动合并人员信息。在清理过程中，请存储重复审查状态，而不是直接删除行。
选择与列表规模相匹配的查询路径
对于新的或已更正的 CRM 记录，CarrierLookup 的原始归属运营商查询（Original Carrier Lookup）可以添加号码类型、原始分配运营商、底层运营商和号码分配地理位置。单次查询适用于单条记录。同会话 REST 多号码查询最多可接受 100 个 E.164 号码，仪表板实时批处理最多可接受 500 个。多号码查询路径保留了输入顺序，这有助于将结果映射回源键。
大型积压数据需遵循单独的异步文件任务。准备一个单列的 TXT 或 CSV 文件，每行包含一个带国家代码的号码，并选择该任务所使用的国家/地区。包含多个国家的 CRM 导出文件应先按国家分组。列表应基本来自所选国家；不符合批量预处理规则的行可能会被排除。请阅读 CarrierLookup API documentation 以了解实时限制和接受详情，而不是在导入模板中嵌入假设的限制。
文件任务并非同响应查询。提交准备好的文件，在记录的间隔内监控其任务状态，并在成功后下载结果 CSV。请保留准备好的标识符与 CRM 源键之间的映射，因为批量结果标识符是纯粹的带国家代码数字，不含加号。该标识符与 CRM 的 E.164 字段之间的转换应是明确的。
映射字段，切勿推断出更强的结论
CarrierLookup 的运营商字段是指号码段最初分配到的公司。区域和城市字段是分配地理位置。号码类型描述了范围分类。请将这些值放入相应命名的 CRM 字段中，例如“原始运营商”和“分配区域”，而不是使用可能被误认为是关于某人当前事实的通用“运营商”和“位置”标签。
| 导入字段 | 存储内容 | 切勿推断 |
|---|---|---|
| 标准化号码 | 经审查的 E.164 值 | 所有权或许可 |
| 号码类型 | 报告的分配类别 | 服务是否处于活跃状态 |
| 原始运营商 | 报告的范围分配 | 携号转网后的服务运营商 |
| 分配区域或城市 | 报告的号码段地理位置 | 人员或设备当前位置 |
| 空查询字段 | 不可用值 | 负面或无效结果 |
已完成的查询可能包含空的运营商字段。请将其留空或使用明确的不可用标记；请勿根据前缀自动填充猜测的运营商。格式拒绝或无法判定的查询应进入审查队列，而不是进入正常的丰富结果组。CRM 应保留查询日期，以便后续用户了解数据的时效性。
测试导入并记录异常处理路径
在导入整个文件之前，请测试一个小样本，其中包含普通移动号码段、固定电话或 VoIP 类别、重复项、空查询字段以及需要从国家格式转换为国际格式的号码。检查 CRM 是否将每个字段映射到了预期的列，以及空白值是否未意外覆盖良好的源数据。在实际的 CRM 界面中测试导入后，审查几条记录。
准备一份包含源键、原因和所有者的异常报告。可能的类别包括：缺少国家/地区、原始值损坏、重复项审查、查询不可用以及文件任务排除。每个类别都需要采取不同的后续行动。“重试”仅在已知可更正的输入或临时结果条件下适用；它不应替代查找源国家/地区的操作。
最后，比较每个阶段的行数：源导出、标准化候选、已提交查询、已完成结果、异常和已导入的 CRM 记录。如果行被有意保留，计数不必完全匹配，但每个差异都应是可以解释的。这将一次性的清理工作转变为下一个操作员可以重复的流程。
常见问题解答
团队应在何时对 CRM 导入的电话号码进行去重？
首先将号码标准化为经审查的国际格式，然后比较值。保持关联的源记录可见，并审查重复的号码是共享线路还是数据错误。
应如何导入空的运营商字段？
存储一个不可用值和查询日期。带有空字段的已完成响应不应被转换为无效号码或断开线路的结论。
大型运营商查询文件中应包含什么？
使用单列的 TXT 或 CSV 文件，其中包含准备好的带国家代码的号码，按所选国家分组，并保留返回结果与 CRM 记录键之间的映射。
了解更多
选择适合您工作流程下一步的产品信息。