同一个手机号进了多条表单线索，怎么定合并规则

教程定位

这篇教程解决什么问题

这篇文章解决一个很具体的问题：同一个脱敏手机号在多个表单线索里反复出现时，CRM 管理员怎么先整理判断口径，再产出一份可执行的“重复线索合并规则”。

最后交付物不是线索评分模型，也不是销售分配策略，而是一份规则说明：哪些重复号码可以进入自动合并候选，哪些必须人工复核，哪些应该保留多条记录；合并时保留哪条主记录，来源、跟进记录、销售归属、商机和勿扰状态分别怎么处理。

这里的 AI 只适合做三件事：帮助你把字段和冲突情况整理成规则草稿，发现遗漏的复核条件，把规则写成销售、市场和 CRM 管理员都能看懂的版本。AI 不能替你执行真实合并，也不能只凭一段脱敏表格断定两条线索就是同一个人。真实合并必须回到 CRM 做查重、查看完整客户和商机历史，并由线索负责人或销售管理者确认。

使用场景

什么情况下最适合用这一套

你是 CRM 管理员，最近市场部上线了好几个表单：官网试用申请、白皮书下载、直播报名、展会留资、小红书私信导流。表面上新增线索很多，但一查 CRM，发现同一个手机号可能在不同入口重复出现。

最麻烦的不是“重复”本身，而是重复之后带来的连锁问题：

所以这篇文章的目标不是追求“手机号一样就合并”的简单答案，而是帮你把重复号码拆成几类：确定可以合并的、需要人工判断的、应该保留的。规则越清楚，后面自动化越稳；规则越含糊，自动合并越容易制造事故。

• 同一个客户上午刚被 A 销售电话联系，下午又被 B 销售按新线索跟进，客户觉得公司内部很乱。
• 市场部想看渠道转化，结果某个手机号先下载白皮书、后申请试用，如果直接覆盖来源，首次来源和最近触点都会失真。
• 销售主管看跟进效率，发现一部分销售名下有很多“新线索”，其实是老客户、老商机或已联系线索重复进表。
• CRM 自动分配规则把重复线索分给不同销售，后续谁负责、谁拿业绩、谁继续跟进都说不清。
• 客服或销售把客户主记录合并错了，历史沟通、附件、商机、退订状态丢失，后面很难还原。

材料准备

开始前先把材料和边界备齐

在让 AI 帮你起草规则之前，先准备一份脱敏后的样例数据和内部口径。不要把完整手机号、完整邮箱、真实身份证件、合同金额明细或敏感备注直接粘给 AI。建议用 CRM 导出的重复组做样例，每组 2 到 5 条记录即可，手机号只保留脱敏展示，同时保留 CRM 内部生成的 `phone_key` 或“重复组编号”。

至少准备这些字段：

| 字段 | 用途 | 注意点 | | --- | --- | --- | | 线索 ID | 后续定位记录 | 用内部编号，不要暴露完整个人信息 | | phone_key | 表示 CRM 归一化后的同号分组 | 由 CRM 或数据脚本生成，AI 不负责从脱敏号码猜是否同号 | | 脱敏手机号 | 便于人工识别重复组 | 例如 `138****4521`，不要出现完整号码 | | 姓名 | 判断是否同一联系人 | 姓名冲突时不要自动合并 | | 公司 | 判断是否同一组织 | 公司简称、全称、旧公司名要人工确认 | | 来源渠道 | 保留归因和最近触点 | 不能简单被最新表单覆盖 | | 表单提交时间 | 判断新旧记录 | 注意时区和导入时间差异 | | 最近互动时间 | 判断当前有效跟进 | 比创建时间更能反映谁正在跟 | | 当前负责人 | 判断销售归属冲突 | 不同负责人通常需要人工复核 | | 线索状态 | 判断是否已联系、无效、转客户 | 状态冲突时不能只按最新状态覆盖 | | 商机状态 | 判断是否有开放商机 | 有活跃商机必须慎重处理 | | 勿扰/退订状态 | 合规和体验边界 | 绝不能被新线索覆盖成可联系 | | 跟进摘要 | 判断是否同一需求 | 只放脱敏摘要，不放敏感原文 |

还需要提前写清楚四个内部口径：

如果这些口径没有定，AI 只能写出一份看起来完整、实际上无法执行的通用清单。真正有用的规则必须和你的 CRM 字段、销售管理方式、渠道归因方式绑定。

1. 手机号归一化规则：是否去掉空格、横线、国家区号、分机号；企业总机和个人手机号是否分开处理。
2. 公司名称归一化规则：简称、工商全称、品牌名、子公司名、门店名怎么对应。
3. 销售归属优先级：已有客户归客户负责人，活跃商机归商机负责人，新线索才进入新分配。
4. 来源保留规则：首次来源、最近来源、所有表单触点分别放在哪些字段或活动记录里。

实操流程

按这套步骤把工作跑起来

【第一步：先把“重复”定义成 CRM 能识别的条件】

不要让 AI 从脱敏文本里判断两个号码是不是一样。正确做法是：先在 CRM 或数据表里完成手机号标准化，再把同一个标准化结果分到同一个 `phone_key`。

比如，CRM 里可能把带空格、带横线、带国家区号的号码统一成同一个内部键值，然后在导出表里只展示 `138****4521`。这样 AI 看到的是“这些记录属于同一个 phone_key”，而不是自行猜测。

推荐定义：

注意，“自动合并候选”不等于“已经可以自动执行”。它只是进入下一步 CRM 查重或批处理前的候选范围。真实合并仍要依赖 CRM 的去重功能、字段保留规则和负责人确认。

【第二步：先分三类，不要一开始就写复杂公式】

重复号码合并规则可以先拆成三层：

| 类别 | 判断口径 | 处理方式 | | --- | --- | --- | | 自动合并候选 | 同号、同人、同公司、无负责人和商机冲突 | 进入 CRM 合并候选列表，批量前抽样检查 | | 人工复核 | 同号但公司、负责人、状态、商机、勿扰、来源价值存在冲突 | 由 CRM 管理员、销售负责人或客户负责人确认 | | 保留多条 | 号码疑似总机、门店公共号码、多人共用号码、不同公司明确无关 | 不合并，只在 CRM 标记“同号不同对象” |

这样做的好处是，销售团队不用理解一大串难懂公式，只要看得懂“为什么这条不能自动合并”。CRM 管理员也可以先把规则落成视图、标签或待办队列，等验证稳定后再考虑自动化。

【第三步：明确主记录选择顺序】

合并时最容易吵架的是“保留哪条”。建议不要用“最新创建的一条”做默认主记录，因为最新记录可能只是一次白皮书下载，而旧记录里已经有客户、商机、合同或完整跟进历史。

可以采用这样的主记录优先级：

这套优先级背后的原则是：不要为了清理重复而破坏正在发生的业务。客户、商机、当前跟进和审计记录比“哪条更新”更重要。

【第四步：把字段处理规则写细】

一份能落地的合并规则，不能只写“合并到主记录”。你还要说明每类字段怎么处理。

| 字段类型 | 建议处理 | | --- | --- | | 手机号 | 以 CRM 标准化字段为准，脱敏展示字段只用于人工核对 | | 姓名 | 完全一致可保留；一条为空可补齐；冲突则人工复核 | | 公司 | 标准化后相同可合并；简称/全称可人工确认后归一；不同公司默认复核 | | 来源 | 首次来源不覆盖；最近来源写入最近触点；所有来源表单写入活动记录 | | 最近互动时间 | 保留最大值，但要保留原记录互动明细 | | 负责人 | 已有客户或商机负责人优先；不同销售冲突要负责人确认 | | 线索状态 | 不简单按最新覆盖，需按状态优先级和历史流转保留 | | 商机 | 有开放商机不自动合并，先由商机负责人确认 | | 勿扰/退订 | 更严格状态优先，不能被新表单覆盖为可营销 | | 附件和备注 | 迁移到主记录活动或附件区，保留来源记录 ID |

尤其要注意来源字段。很多团队为了“数据干净”，把重复线索合并后只留下最新来源，结果市场归因全乱。更稳的做法是把来源拆成三个概念：首次来源、最近触点来源、全部触点历史。合并不是删除营销历史，而是把同一人的多次触点串起来。

【第五步：规定人工复核触发条件】

下面这些情况，不建议自动合并：

人工复核不是低效，而是在保护客户体验和销售公平。对于 P0 规则，宁可多保留几组复核，也不要把高价值客户合错。

【第六步：把规则变成可执行的复核表】

建议最终规则至少包含这些列：

| 规则编号 | 条件 | 建议动作 | 主记录选择 | 保留字段 | 需要谁确认 | | --- | --- | --- | --- | --- | --- | | R1 | 同号、同姓名、同公司、无商机、同负责人 | 自动合并候选 | 信息最完整或互动最新记录 | 全部来源和跟进历史 | CRM 管理员抽样 | | R2 | 同号、同姓名、同公司、不同负责人 | 人工复核 | 按客户/商机/最近互动排序 | 保留所有来源 | 两位负责人或主管 | | R3 | 同号、不同公司 | 人工复核 | 暂不指定 | 暂不迁移 | CRM 管理员和负责人 | | R4 | 同号、不同姓名 | 人工复核或保留多条 | 暂不指定 | 标记同号组 | CRM 管理员 | | R5 | 企业总机或公共号码 | 保留多条 | 不合并 | 标记公共号码 | CRM 管理员 | | R6 | 任一记录有开放商机 | 人工复核 | 商机记录优先但不自动执行 | 商机、活动、附件完整保留 | 商机负责人 | | R7 | 勿扰/退订状态冲突 | 人工复核 | 更严格状态优先 | 保留合规标记 | 销售运营或合规负责人 |

这张表可以让 AI 起草，但落地前必须由 CRM 管理员根据系统字段改写。比如有的 CRM 叫“负责人”，有的叫“Owner”；有的有“活动记录”，有的把表单提交存在“市场触点”。字段名不一致时，不要直接照搬。

【第七步：先干跑，再小批量验证】

规则写好以后，不要立刻全量合并。建议先做三步验证：

每次真实合并都要留下审计信息：原线索 ID、主记录 ID、合并时间、执行人、确认人、合并原因、迁移字段、未迁移字段、是否涉及负责人变更。没有日志的合并，出了问题很难复盘。

1. 已存在客户联系人记录优先于普通线索。
2. 有开放商机的记录优先于无商机记录。
3. 有最近双向互动的记录优先于只有表单提交的记录。
4. 信息更完整、负责人明确、跟进历史更连续的记录优先。
5. 如果以上都相同，再考虑保留创建更早的一条作为首次获客记录。
6. 干跑：只打标签，不合并，输出“建议动作”和“原因”。
7. 抽样：从自动合并候选里抽 30 到 50 组，人工检查 CRM 完整记录。
8. 小批量：先处理低风险组，保留合并日志，观察销售反馈和客户投诉。

• 重复号码组：`phone_key` 相同的 2 条或以上线索。
• 高风险重复号码组：同一 `phone_key` 下出现不同公司、不同姓名、不同负责人、开放商机、客户记录、勿扰状态冲突或企业总机特征。
• 自动合并候选：同一 `phone_key` 下，姓名一致或其中一条为空，公司一致或其中一条为空，无开放商机冲突，无负责人冲突，无勿扰状态冲突，跟进历史可以完整迁移。
• 同一 `phone_key` 下出现两个或以上不同公司，哪怕姓名相同。
• 同一 `phone_key` 下出现不同姓名，尤其是企业总机、门店、前台号码或家庭共用号码。
• 任一记录存在开放商机、合同、报价、试用中、重要客户标签。
• 不同销售负责人都在最近 30 天内有有效跟进。
• 一条记录为退订、勿扰、投诉、黑名单，另一条记录为可营销。
• 来源渠道涉及高价值活动，例如付费展会、代理商推荐、重点客户转介绍。
• 最近互动摘要显示需求不同，例如一条是采购软件，一条是咨询合作。
• 公司名称可能是跳槽前后变化，无法确认是同一自然人还是不同组织联系人。

输入示例

可以直接参考的输入材料

下面是一段可以粘给 AI 的脱敏样例。注意，样例里没有完整手机号，也没有完整邮箱；`phone_key` 是 CRM 或数据表提前生成的同号分组，不是让 AI 根据脱敏号码猜出来的。

背景：
我们是一家 B2B SaaS 公司，市场表单包括官网试用申请、白皮书下载、直播报名和展会留资。现在 CRM 里出现同一个 phone_key 对应多条线索的情况，想先制定重复线索合并规则。

目标：
请帮我起草一份“重复手机号线索合并规则”。规则只用于建议和人工复核，不能直接执行真实合并。真实合并必须回到 CRM 查重，并由负责人确认。

内部口径：
1. phone_key 已经由 CRM 完成手机号归一化，同一个 phone_key 代表系统认为号码相同。
2. 脱敏手机号只用于展示，不用于 AI 判断真实号码。
3. 已有客户联系人优先于普通线索。
4. 有开放商机的记录不允许自动合并。
5. 来源不能被覆盖，首次来源、最近触点和全部表单历史都要保留。
6. 勿扰、退订、投诉等状态以更严格状态为准。
7. 不同销售负责人时，默认进入人工复核。

样例数据：

| lead_id | phone_key | 脱敏手机号 | 姓名 | 公司 | 来源 | 创建时间 | 最近互动时间 | 负责人 | 线索状态 | 商机状态 | 勿扰状态 | 跟进摘要 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| L-10231 | PKEY-A7F2 | 138****4521 | 王敏 | 上海启禾科技 | 官网试用申请 | 2026-06-03 10:12 | 2026-06-05 15:20 | 张岚 | 已联系 | 无 | 否 | 约过产品演示，需求是销售线索自动分配 |
| L-10388 | PKEY-A7F2 | 138****4521 | 王敏 | 启禾科技 | 白皮书下载 | 2026-06-08 09:33 | 2026-06-08 09:33 | 张岚 | 新线索 | 无 | 否 | 下载线索清洗资料 |
| L-10402 | PKEY-A7F2 | 138****4521 | 王敏 | 上海启禾科技 | 直播报名 | 2026-06-10 14:05 | 2026-06-11 11:40 | 张岚 | 已联系 | 无 | 否 | 直播后回复希望看报价 |
| L-11019 | PKEY-B11C | 139****0086 | 刘伟 | 杭州景航贸易 | 展会留资 | 2026-06-01 16:40 | 2026-06-02 10:00 | 陈立 | 已联系 | 开放商机 | 否 | 已建商机，预计下周评审 |
| L-11377 | PKEY-B11C | 139****0086 | 刘伟 | 上海云桥咨询 | 官网试用申请 | 2026-06-12 13:18 | 2026-06-12 13:18 | 周宁 | 新线索 | 无 | 否 | 申请试用，备注为咨询团队使用 |
| L-12108 | PKEY-C94D | 400****1138 | 前台 | 北京明岚集团 | 白皮书下载 | 2026-06-04 11:09 | 2026-06-04 11:09 | 未分配 | 新线索 | 无 | 否 | 企业总机，未确认具体联系人 |
| L-12156 | PKEY-C94D | 400****1138 | 赵晨 | 北京明岚集团 | 直播报名 | 2026-06-09 18:22 | 2026-06-10 09:10 | 林悦 | 已联系 | 无 | 否 | 说该号码是公司前台转接 |
| L-12930 | PKEY-D02E | 186****7780 | 孙洁 | 深圳禾木智能 | 代理商推荐 | 2026-05-20 15:02 | 2026-05-25 17:30 | 唐越 | 无效-暂不采购 | 无 | 是 | 客户要求暂不电话联系 |
| L-13244 | PKEY-D02E | 186****7780 | 孙洁 | 深圳禾木智能 | 官网试用申请 | 2026-06-15 10:21 | 2026-06-15 10:21 | 未分配 | 新线索 | 无 | 否 | 重新提交试用申请 |

请输出：
1. 自动合并候选规则。
2. 必须人工复核的规则。
3. 应保留多条记录的规则。
4. 主记录选择顺序。
5. 字段保留和覆盖原则。
6. 针对样例数据的建议动作。
7. 真实执行前的人工检查点。

提示词

可复制使用的提示词

你是 B2B CRM 销售运营顾问。请根据我提供的脱敏重复线索样例，起草一份“重复手机号线索合并规则”。

重要边界：
- 你只能提出规则建议和复核清单，不能把任何样例直接判定为已经完成合并。
- 真实合并必须回到 CRM 查重，查看完整客户、商机、活动、附件和负责人信息，并由负责人确认。
- 样例中的手机号已经脱敏，不允许根据脱敏号码猜测完整号码。
- phone_key 是 CRM 归一化后的同号分组，你可以把同一 phone_key 当作“系统识别为同号的候选组”，但仍需判断是否能合并。
- 不要做线索评分模型，不要重新设计销售分配策略，只处理重复手机号合并规则。

请按以下结构输出：
1. 判断前提：列出使用这些规则前必须满足的 CRM 数据前提。
2. 自动合并候选：用表格列出条件、建议动作、主记录选择、保留字段、风险说明。
3. 人工复核：用表格列出触发条件、复核人、复核问题、可能动作。
4. 保留多条记录：说明哪些重复号码不应合并，并给出原因。
5. 主记录选择顺序：写成可执行的优先级。
6. 字段处理原则：分别说明手机号、姓名、公司、来源、负责人、状态、商机、勿扰、跟进历史怎么处理。
7. 样例数据建议：逐个 phone_key 给出“自动合并候选/人工复核/保留多条”的建议和原因。
8. 执行前检查清单：列出 CRM 管理员和销售负责人必须确认的事项。
9. 不确定问题：列出需要我补充的业务规则。

输出风格：
- 用 CRM 管理员能执行的语言写，不要写空泛原则。
- 对高风险情况要明确写“不得自动合并”。
- 对来源归因要强调“首次来源、最近触点、全部触点历史都要保留”。
- 对勿扰、退订、投诉状态要采用更严格状态优先。
- 如果信息不足，请标记为人工复核，不要假装确定。

下面是我的业务背景、内部口径和脱敏样例数据：
【在这里粘贴背景、内部口径和样例表格】

输出样例

AI 应该输出到什么程度

下面是使用上面提示词后，AI 可能给出的初稿。它适合作为规则草案，但仍然不能直接执行真实合并。

# 重复手机号线索合并规则建议稿

教程正文

1. 判断前提

本规则只适用于 CRM 已经完成手机号归一化后的重复号码组。phone_key 相同表示系统识别为同号候选，但不代表一定可以合并。真实合并前必须在 CRM 中查看完整记录，包括客户联系人、商机、活动记录、附件、退订状态、负责人和历史合并日志。

教程正文

2. 自动合并候选

| 规则 | 条件 | 建议动作 | 主记录选择 | 保留字段 | 风险说明 | | --- | --- | --- | --- | --- | --- | | A1 | phone_key 相同，姓名一致，标准化公司一致或一条为空，无开放商机，无负责人冲突，无勿扰冲突 | 标记为自动合并候选 | 已联系且最近互动更完整的记录优先 | 所有来源、表单提交、活动、备注全部迁移 | 仍需 CRM 干跑和抽样检查 | | A2 | phone_key 相同，姓名一致，公司简称和全称可明确对应，负责人相同，无商机和合规冲突 | 标记为自动合并候选 | 客户/商机优先，其次最近有效互动 | 首次来源不覆盖，最近触点更新到最近来源字段 | 公司简称映射需在 CRM 字典中确认 |

教程正文

3. 人工复核

| 触发条件 | 复核人 | 要问的问题 | 可能动作 | | --- | --- | --- | --- | | 同一 phone_key 下出现不同公司 | CRM 管理员 + 当前负责人 | 是同一人跳槽、集团/子公司关系，还是公共号码？ | 合并、保留、改公司映射 | | 不同负责人都在近期跟进 | 两位负责人或销售主管 | 谁拥有当前有效客户关系？是否涉及商机保护期？ | 指定主记录后合并，或保留并转移归属 | | 任一记录有开放商机 | 商机负责人 | 合并是否影响商机阶段、报价、任务和预测？ | 通常以商机记录为主，但不得自动执行 | | 勿扰状态冲突 | CRM 管理员或合规负责人 | 客户是否仍然拒绝电话或营销触达？ | 更严格状态优先，必要时暂停联系 | | 企业总机、前台、门店号码 | CRM 管理员 | 这是个人手机号还是组织公共号码？ | 多数情况下保留多条，并标记公共号码 |

教程正文

4. 保留多条记录

以下情况建议保留多条记录，不做自动合并：

• 号码明显是企业总机、门店电话、前台转接或多人共用号码。
• 同一 phone_key 下姓名不同，且不能证明是同一自然人。
• 同一 phone_key 下公司不同，且没有跳槽、集团、子公司或品牌简称关系证明。
• 记录对应不同业务对象，例如一个是客户采购需求，一个是合作伙伴咨询。

教程正文

5. 主记录选择顺序

1. 已有客户联系人记录优先。
2. 有开放商机的记录优先，但必须由商机负责人确认。
3. 最近有双向互动的记录优先。
4. 负责人明确、跟进历史完整的记录优先。
5. 若仍无法判断，保留创建最早记录作为主记录候选，同时把较新表单作为活动触点迁入。

教程正文

6. 字段处理原则

• 手机号：以 CRM 标准化字段为准，脱敏展示不参与真实判断。
• 姓名：一致则保留；一条为空可补齐；冲突进入人工复核。
• 公司：标准化一致可合并；简称/全称关系需有公司字典或人工确认；不同公司默认复核。
• 来源：首次来源不覆盖，最近触点可更新，所有表单提交保留为活动历史。
• 负责人：已有客户和开放商机负责人优先；不同负责人冲突时不得自动改归属。
• 状态：不按最新记录直接覆盖，按客户生命周期和历史状态迁移。
• 商机：开放商机相关记录不得自动合并。
• 勿扰：退订、勿扰、投诉等更严格状态优先，不得被新表单覆盖。
• 跟进历史：迁移到主记录活动区，保留原 lead_id 和时间戳。

教程正文

7. 样例数据建议

| phone_key | 建议动作 | 原因 | 执行前确认 | | --- | --- | --- | --- | | PKEY-A7F2 | 自动合并候选 | 姓名一致，公司可视为同一公司，负责人相同，无商机和勿扰冲突；应把白皮书下载、直播报名都保留为触点 | 在 CRM 确认公司简称映射和所有活动可迁移 | | PKEY-B11C | 人工复核 | 同号同姓名，但公司不同、负责人不同，且其中一条有开放商机 | 商机负责人确认是否同一人跳槽或两个组织需求 | | PKEY-C94D | 保留多条或人工复核 | 号码疑似企业总机/前台转接，同一号码可能对应多人 | 标记公共号码，不建议自动合并 | | PKEY-D02E | 人工复核 | 同人同公司，但存在勿扰状态冲突；新试用申请可能表示重新授权，也可能只是误触发 | 负责人确认客户最新授权和可联系边界 |

教程正文

8. 执行前检查清单

• CRM 是否确认 phone_key 对应同一标准化号码。
• 是否存在客户联系人、开放商机、合同、报价、任务或附件。
• 两条或多条记录的负责人是否一致；不一致时是否已确认归属。
• 勿扰、退订、投诉、黑名单状态是否被保留为更严格状态。
• 首次来源、最近触点、全部表单历史是否都能保留。
• 合并后是否保留原 lead_id、执行人、确认人和合并原因。
• 是否先进行干跑和抽样检查，再进入批量处理。

教程正文

9. 需要补充的问题

1. CRM 是否有“首次来源”和“最近来源”两个独立字段？
2. 公司简称和工商全称是否有标准映射表？
3. 销售保护期是按创建时间、最近互动时间还是商机创建时间计算？
4. 勿扰后重新提交表单是否视为重新授权，还是必须人工确认？

这份 AI 输出已经能作为初稿，但还需要你把“标准化公司一致”“销售保护期”“重新授权”这些词改成你们公司的真实规则。否则销售团队拿到后仍然不知道该怎么操作。

人工验收

人要怎么检查和改到可用

AI 输出后，CRM 管理员要做的是把“看起来合理的建议”改成“系统能执行、团队愿意认账的规则”。建议按下面清单逐条检查。

第一，检查数据前提是否真实存在。比如 AI 写了“标准化公司一致”，但你的 CRM 里没有公司标准化字段，只有销售手填的公司名，那这条就不能作为自动合并条件，只能作为人工复核条件。

第二，检查手机号重复是否来自 CRM 查重，而不是来自脱敏样例的视觉相似。脱敏号码只能用于展示，真实合并必须使用 CRM 的标准化号码、查重工具或数据脚本结果。

第三，检查主记录优先级是否符合你们的销售管理制度。有些公司要求已有客户负责人优先，有些公司要求按商机负责人优先，有些公司有销售保护期。AI 不知道你的内部制度，必须由销售运营确认。

第四，检查来源字段是否会被覆盖。合并后至少要能回答三个问题：客户第一次从哪里来，最近一次触点从哪里来，中间还参加过哪些活动。如果合并规则只保留一个来源字段，后面市场复盘会很痛苦。

第五，检查开放商机。只要任一记录存在开放商机，就不要让自动合并直接改客户、负责人、阶段、预计成交时间或预测金额。先让商机负责人确认，再由 CRM 管理员执行。

第六，检查勿扰和退订状态。新表单提交不一定代表客户允许重新营销，尤其是代理商代填、展会批量导入、同事代报名、系统同步延迟这些场景。勿扰、退订、投诉、黑名单等状态要按更严格原则处理。

第七，检查公共号码。企业总机、前台电话、门店电话、热线号码、集团统一号码都可能被多人填写。这样的重复号码不适合按个人线索自动合并，更适合标记为公共号码，并要求销售补全真实联系人。

第八，检查合并后的审计日志。规则里要写清楚合并前后记录 ID、执行人、确认人、时间、原因、字段迁移结果。没有审计日志的“干净数据”，其实是不可追责的数据。

第九，检查销售沟通话术。合并规则不是只给系统看的。销售需要知道为什么某些线索被合并、为什么某些线索还在待复核、为什么不能抢另一个负责人名下的重复客户。规则说明里最好保留一段面向销售的解释。

第十，先抽样再批量。即使规则写得很好，也要先做干跑和小批量验证。建议从自动合并候选中抽样检查，确认没有把不同公司、不同人、公共号码、活跃商机和勿扰冲突误放进去。

可以把人工确认结果补成这样的复核表：

| phone_key | 系统建议 | 人工结论 | 确认人 | 原因 | 是否执行 | | --- | --- | --- | --- | --- | --- | | PKEY-A7F2 | 自动合并候选 | 同意合并 | 张岚、CRM 管理员 | 同人同公司同负责人，来源保留为活动 | 是 | | PKEY-B11C | 人工复核 | 暂不合并 | 陈立、周宁 | 公司不同且存在开放商机 | 否 | | PKEY-C94D | 保留多条 | 标记公共号码 | CRM 管理员 | 企业总机/前台转接 | 否 | | PKEY-D02E | 人工复核 | 暂停联系并复核授权 | 唐越、CRM 管理员 | 勿扰状态冲突 | 否 |

这张表是 AI 草稿到真实执行之间的安全垫。没有人工结论，不要把“建议动作”当成“执行动作”。

失败反例

这些失败反例要提前避开

【反例一：只要手机号一样就自动合并】

错误做法：把所有相同 `phone_key` 的线索直接合成一条。

为什么错：同一个号码可能是企业总机、门店号码、前台转接、家庭共用号码，也可能是一个联系人换了公司。只看手机号会把不同业务对象混在一起。

正确改法：至少结合姓名、公司、负责人、商机、最近互动和公共号码特征判断。无法确认同人同公司时，进入人工复核。

【反例二：用最新表单覆盖全部来源】

错误做法：客户先从展会留资进入，后来下载白皮书，合并后来源只保留“白皮书下载”。

为什么错：首次来源被覆盖后，市场活动 ROI、渠道质量、销售跟进路径都会失真。白皮书可能只是最近触点，不是首次获客来源。

正确改法：保留首次来源、最近触点和全部触点历史。合并是串联触点，不是抹掉历史。

【反例三：不同销售负责人时自动改给最新线索负责人】

错误做法：同号重复线索进入系统后，谁拿到最新线索就把主记录负责人改成谁。

为什么错：旧记录可能已经在跟进、已经建商机或处于销售保护期。自动改负责人会引发抢线索、业绩归属和客户体验问题。

正确改法：不同负责人默认人工复核。已有客户、开放商机、最近有效互动和销售保护期都要纳入判断。

【反例四：把企业总机当成个人手机号合并】

错误做法：看到 `400****1138` 或前台转接号码重复，就把不同姓名的线索合并成一个联系人。

为什么错：公共号码可能对应多个部门、多个联系人、多个需求。合并后销售会把 A 联系人的备注放到 B 联系人名下。

正确改法：标记公共号码，保留多条联系人或线索，要求销售补真实手机号或直接联系人信息。

【反例五：让 AI 根据姓名相似度直接决定合并】

错误做法：让 AI 判断“王敏”和“王女士”是不是同一个人，然后直接输出合并结论。

为什么错：AI 看不到 CRM 完整历史，也不能验证真实身份。姓名相似只是线索，不是合并依据。

正确改法：AI 可以提示“需要复核姓名一致性”，但真实判断必须回到 CRM，结合通话、表单、公司、负责人和客户确认信息。

【反例六：合并时丢掉跟进历史和附件】

错误做法：把重复线索删除，只保留主记录当前字段。

为什么错：销售通话、客户回复、报价附件、活动报名、备注都可能是后续成交依据。删除后不仅影响跟进，也影响审计。

正确改法：合并前明确迁移范围，把原记录的活动、备注、附件、表单提交和原 lead_id 迁移或关联到主记录。

【反例七：勿扰状态被新表单覆盖】

错误做法：客户之前标记“勿扰”，后来又出现在官网试用表单里，系统自动把状态改成“可联系”。

为什么错：新表单可能由同事代填、代理商导入或系统同步产生，不一定代表客户重新授权。贸然联系会伤害客户体验，也可能带来合规风险。

正确改法：勿扰、退订、投诉、黑名单等状态按更严格原则保留；是否恢复联系需要负责人或合规口径确认。

【反例八：跨系统导入前没有统一号码格式】

错误做法：官网、展会工具、直播平台各自导出号码，未处理国家区号、空格、横线、分机，直接让 AI 看表格写规则。

为什么错：同一个号码可能被识别成多条，不同号码也可能因为格式处理错误被归到一起。AI 无法替 CRM 做可靠的号码标准化。

正确改法：先在 CRM 或数据脚本里完成手机号归一化和查重，再把重复组交给 AI 起草规则。

主题边界

它和相邻主题的区别

这篇只处理“同一个手机号出现在多条表单线索中时，怎么制定合并和复核规则”。它的交付物是一份重复线索合并规则，重点是自动合并候选、人工复核条件、保留多条条件、主记录选择和字段保留原则。

它不是线索评分模型。线索评分会讨论行业、职位、预算、行为分、活跃度和成交概率；本文不判断线索值不值得跟进，只判断重复号码该不该合并。

它不是销售分配规则。销售分配会讨论区域、行业、轮询、保护期和业绩归属；本文只在合并场景里说明负责人冲突需要人工确认，不重新设计分配体系。

它不是渠道归因方案。渠道归因会讨论首次触点、多触点权重、广告 ROI 和转化口径；本文只要求合并时不能覆盖来源，必须保留首次来源、最近触点和全部触点历史。

它也不是 CRM 系统配置教程。不同 CRM 的去重、合并、活动迁移和权限配置都不一样。本文给的是业务规则草稿的写法，真正执行时仍要回到 CRM 查重、测试合并结果，并取得负责人确认。