lead-routing

线索路由

设计分配逻辑，确保每条入站线索都有一位明确的负责人接收。这个领域没有行业命名的框架——从业者各自独立地形成了相同的事实标准模式：按顺序排列的优先级阶梯（也称为规则瀑布），从上到下逐条评估，命中首条规则后即停止，最后以受监控的兜底规则收尾。应将其描述为常见做法，切勿包装成某种品牌方法论。

路由不等于分配。

• **分配：**在 CRM 中写入所有者字段。
• **路由：**从线索捕获到有人承担责任的完整链路；若无人接手，系统则发出可见异常，并设置计时器和升级路径。

大多数路由故障都是无声的：

• 规则触发
• 仪表板显示正常
• 线索留在无人负责的队列中，迟迟无人跟进

线索评分在这里严格来说只是输入，绝不是设计目标。使用用户已有的评分作为：

• 排序信号：优先跟进哪些符合条件的线索
• 资格门槛：仅路由评分高于阈值的线索

不要设计或调整评分模型本身。相关的姊妹技能是 mbfinotti/revops-skills@lead-scoring。

访谈

• 设计前先提问。

• 每条消息只问一个问题。

• 尽可能提供多选项。

• 只有在用户已经回答过时才跳过问题。

• 线索由什么触发创建，又通过哪些接入路径进入——网页表单、API、列表导入、聊天、日程安排工具、CRM 同步还是手动录入？

• 哪些线索属性在捕获时能够可靠填充（国家/地区、公司规模、行业、电子邮件域名）？哪些经常为空？

• 团队结构如何——有多少名销售代表，分别属于哪些团队（SDR、AE、细分市场团队、专家团队），各自有什么专长？

• 覆盖时段和时区如何？非工作时间或周末会有入站线索吗？

• 销售模式属于 B2B 账户制、B2C/高流量、PLG 自助服务，还是混合模式？每月大约有多少条线索？

• 是否有指定客户名单、合作伙伴交易注册或现有客户的例外规则？这些信息是否在某处进行版本管理？

• 对这个团队来说，“公平”分配意味着什么——轮流均分、按未结工作量均分、根据适应期/任职时长按比例分配，还是均分潜在机会价值？

• 目前有哪些响应 SLA（如有）？是否会进行衡量？

• 有哪些合规限制——数据驻留、同意要求或受监管行业？

• 是否有可用作输入的线索评分？它代表什么？团队是否信任它？

• 新路由必须在哪个日期前上线？这个日期是硬性截止日期，还是期望日期？

• 你想一次性修复当前的路由错误，还是建立一个能随着团队发展持续适用的分配系统？

• 工作量上限是什么——有多少管理员工时可用、是否有人日常负责 CRM，以及团队是否会开展固定的治理流程（权重审查、区域调整）？

最后三个问题的答案会改变本技能中的选项排名，而不仅仅影响时间安排。提出方案前，先根据这些答案重新排序——有关哪个答案会改变哪个选项，请参阅“分配变体”。

工作流

1. 进行访谈；在提出规则之前，先收集设计所依赖的答案。

2. 在修改规则之前先做好埋点：添加各阶段的时间戳（捕获、符合资格、决策、分配、通知、接受、首次操作）。没有这些数据，就无法证明路由变更是否奏效。

3. 在分配线索之前，先修复线索与账户的匹配。统一账户域名字段。优先按电子邮件域名匹配，其次按模糊公司名称匹配。如果匹配率低于约 90%，或重复项超过约 5%，那么在任何规则运行之前就会有线索流失——先清理。

4. 自上而下编写优先级阶梯（见下一节），从最具体到最通用，并将其保存为有版本管理的文档。资格层级决定谁可以持有线索。分配只在符合资格的人员池中进行选择。

5. 先写下团队对“公平”的定义，再根据团队的回答选择实际能够支持的最高档位——默认采用档位 1，即经过可用性检查的直接轮转（见“分配方案”）。

6. 将兜底处理设计成真正的状态：一个受监控的分诊队列，包含：

   • 一位指定负责人
   • 当日工作时间内的 SLA
   • 每周进行一次审查，将反复出现的例外转化为规则

   在此处完成设计，并优先发布——它位于“优先级阶梯”的构建顺序之首，先于其上的所有规则。

7. 添加接受计时器：如果线索已分配，但在 N 分钟内未被接受或处理，则连同记录的原因代码一起重新路由给指定的备用人员。将决策结果和 CRM 写入结果存储在不同字段中，以便区分写入失败与规则从未匹配。

8. 制定路由矩阵（条件 → 负责人 → SLA，按优先级排列）和合成测试包，覆盖每条规则、每种重叠情况以及每条数据接入路径——参见 references/precedence-ladder-example.md 和 references/test-pack-and-rollout.md。

9. 在沙盒中使用测试包进行测试，最好重放真实的历史线索；然后通过金丝雀分段逐步推出，并进行每日核对，同时准备回滚计划。只有在金丝雀分段无法控制变更时，才使用影子模式（参见 references/test-pack-and-rollout.md 中的排序）。切勿直接在生产环境中编辑会影响分配的逻辑。

10. 根据下文“衡量”中的通过阈值进行验证。持续迭代规则、匹配或覆盖范围，直到满足所有阈值。按章节向用户展示最终设计并征求批准：

    • 路由矩阵
    • 测试包
    • 监控计划

11. 如果你的测试框架具有持久记忆功能，则记住已批准的优先级阶梯、公平性定义和阈值——后续变更请求应以此为基础，而非重新访谈。

优先级顺序

按从上到下的顺序排列规则；匹配到第一条即生效。一个站得住脚的默认排序，应根据用户的实际情况调整：

1. 法律、监管或合同要求优先——数据驻留、同意约束、合同合作伙伴权利。这些规则必须确定且有版本记录，绝不能靠推断得出。
2. 根据有版本记录的名单，确定指定客户或战略客户的归属。
3. 匹配账户上存在待处理商机或正在进行的商业流程。
4. 现有账户及其层级关系的归属——转给客户关系负责人，而不是轮换中的下一位。
5. 区域边界——按地理位置、细分市场、行业或团队采用的任意组合划分。
6. 产品、技能或语言资格。
7. 容量和可用性——未处理线索上限、休假、工作时间。
8. 公平分配——在第 1-7 层所确定的候选池范围内，采用选定的分配层级。
9. 受治理的例外处理——受监控的兜底分流队列。

两条结构性规则：

• 第 1-6 层定义资格；第 7-8 层只在符合条件的范围内进行分配。把两者混在一起，就会让企业客户的线索落到 SMB 销售代表手中。
• 层级冲突（匹配到的子公司归一位销售代表所有，而其母公司归另一位销售代表所有）应转入由人工负责的冲突队列，并设置处理时限，绝不能交给自动规则处理。

此列表有意不按效率排序，也绝不会因效率而重新排序。这是评估顺序——从最具体的规则开始，匹配到第一条即生效——因此，任何效率排序的调整，改变的都是触发哪条规则，而不是先构建哪条规则。

构建顺序确实需要排序，而且与上述顺序不同：

• 效率（构建顺序）：第 9 层兜底规则 > 第 4 层现有账户归属 > 第 5 层区域划分 > 第 6 层产品／技能／语言 > 第 7-8 层分配

• 工作量（构建顺序）：第 5 层区域划分（一周，然后设置持续运行的任务）> 第 6 层（一周，加上每位销售代表的技能字段）> 第 4 层（一两天，前提是匹配率达标）> 第 7-8 层（参见“分配方案”）> 第 9 层（一小时）

• **优先构建第 9 层兜底规则：**一小时的工作，就能把所有未处理的遗漏转变为可见的例外；这是唯一能让其他层级的效果可衡量的层级。

• **接下来构建第 4 层现有账户归属：**它能避免最具破坏性的错误分配，即把现有客户交给从未与其沟通过的销售代表；但匹配率低于 90% 时，它毫无用处，因此应先修复匹配问题。

• **第 1-3 层不参与排序：**法律优先规则、指定客户和待处理商机都不可妥协，因此它们的比例永远不会影响任何决策。

分配方案排名

轮转分配是一系列算法的统称，每种算法对“公平”的定义都不同。

最常见的配置错误：

1. 选择的方案不符合团队对公平的定义
2. 选择过于复杂的方案

应根据方案的实际效果排名：线索响应速度和销售代表实际感受到的公平性（而非算法声称实现的公平性），并结合其成本进行评估：

• 效率：检查可用性的直接轮转 > 基于容量的分配 > 加权分配 > 分层组合

• 价值：分层组合 > 基于容量的分配 > 检查可用性的直接轮转 > 加权分配

• 工作量：分层组合 > 加权分配 > 基于容量的分配 > 检查可用性 == 直接轮转

• 合规成本：加权分配 == 分层组合 > 基于容量的分配 == 检查可用性 == 直接轮转

• **直接轮转和检查可用性的工作量相同：**两者都只需基于团队已有的数据进行配置（轮转名单，以及团队信任的任何一种缺勤日历），无需新增字段，也无需设立持续负责的人员。

• **加权分配和分层组合的合规成本相同：**两者都会有意让部分销售代表比其他人获得更多入站线索。这会改变收入机会，因此上线前必须得到销售领导和薪酬管理部门的批准；而且，一旦销售代表了解自己的权重，就不能悄悄撤销。

另外三种方案都不存在这类风险。 第 1 级——经过可用性检查的直接轮转（默认）。 轮到谁就分给谁，但跳过休假或不在营业时间内的人。公平意味着在实际到岗的人之间平均轮转。

• 你将获得：这里能实现的最大单项线索响应速度提升——不会把线索搁置在缺席人员手中；这类失误会直接毁掉线索，而不只是导致分配不均。
• 你需要付出：轮转几乎不需要成本，可用性检查约需 1 小时，无需固定负责人。
• 失效情形：轮转次数相同，未处理线索却严重堆积在少数人手中，或者把日历上的在岗状态误当成销售产能。
• 低成本升级：如果已有未处理线索计数，就添加硬性上限，跳过超过上限的人员。成本几乎为零，而且无需第 2 级的固定裁决人，就能获得其大部分保护效果。

第 2 级——基于产能，仍经过可用性检查。 未处理线索最少的人接手下一条线索。公平意味着未处理工作量相同。

• 你将获得：按工作量而非轮转次数衡量分配偏差，并能明显减轻被无人察觉的大量线索压垮的人员的负担。
• 你需要付出：由 CRM 维护的未处理线索字段，约 1 周时间来商定未处理线索的定义，以及一名固定裁决人来判定何时不再计为未处理线索。
• 失效情形：“一条线索”所需投入差异巨大，因此计数相同却掩盖了工作量不均，和按轮转次数分配时一样。

第 3 级——加权轮转。 权重为 2 的人获得的线索大约是权重为 1 的人的两倍。公平意味着按上手阶段、任职时间或角色进行比例分配。

• 你将获得：为正在上手和兼职的销售人员提供保护——这是一个范围有限的收益，只在有人实际处于上手阶段时才有价值。
• 你需要付出：固定的权重治理流程（谁设定权重、依据什么证据、何时复审），以及上文提到的薪酬方案审批。
• 失效情形：无人负责复审，去年设置的上手期权重仍在沿用，却成了未经审视的绩效评判标准。

第 4 级——完整的分层体系。 通过资格条件缩小候选范围，再按产能或权重进行分配，最后叠加可用性检查。公平意味着同时满足每项定义。

• 你将获得：四种方案中最佳的实际效果，也是唯一能满足同时持有两种公平定义的团队的方案。
• 你需要付出：上述全部成本及其相互作用——需要一项固定工作，而且是这里最难回退的选项。
• 失效情形：没人能用一句话解释某条线索为何分配给某人；此时团队也无法安全地撤销该方案。

只有在当前级别的失效情形已在试点数据中显现时，才提升一级，绝不要提前升级。

• 未处理线索持续堆积，将第 1 级提升至第 2 级。
• 确有一批正在上手的人员，将第 2 级提升至第 3 级。

这种排序会忽略什么。 第 4 级每次都落败：价值最高，固定成本也最高，因此按比值排序时不会选中它。

但在以下三项条件都满足时，仍应升级到第 4 级：

• 有人负责日常管理 CRM
• 不止一个候选池的经济效益确实不同
• 已经出现公平争议

只有 3 名销售人员的团队如果部署了第 4 级，就构建了一个自己无力改变的系统。

删除，而不是降级。

• 如果 CRM 没有未处理线索字段，且团队不愿添加，就直接删除第 2 级，并一并删除第 4 级。降级后的方案可能会在 3 个月后悄然重新成为范围要求。
• 没有权重治理负责人，就删除第 3 级。
• 缺少可用性数据是个例外：它不会删除任何方案，因为首先要做的是建立可用性数据来源，而不是围绕数据缺失来选择轮转变体。

根据答案重新排序。

• 截止日期明确时，将第 1 级前移，并删除第 4 级：截止日期前无法建立起固定流程。

• 若要求打造可复利的资产，则将第 2 级前移，因为随着团队壮大，工作量字段会持续带来收益，而轮转名单不会。

• 如果投入上限低于“需要一项固定工作”，则一次性删除第 3 级和第 4 级。 这一排序是默认方案，而非铁律。它会随情境和执行者而变化，因此在提出任何建议之前，应结合已知的所有用户信息重新排序：

• 全职负责 CRM 的管理员，可以让第 4 级变得触手可及

• 同一时区的 3 名销售代表会让偏差自行修正，并可删除第 2 至第 4 级

• 现有的区域模型已经完成了大部分资格范围缩小工作，因此任何分配变体能带来的额外价值都会降低

B2B 与 B2C／高流量／PLG

两种模式的层级结构、兜底设计、测试方法和衡量方式都相同。不同之处在于路由依据和覆盖模式：

• B2B 以客户为基础：优先按客户归属进行路由。同一客户的所有联系人都应分配给同一位负责人——采购委员会提交 3 份表单，不应分配给 3 名销售代表。将指定客户例外和合作伙伴交易注册保护期作为强制覆盖规则。目标客户采用 24 小时 SLA 是从业者常见的起步方案。
• B2C／高流量／PLG：按地理位置、语言和覆盖时段进行路由。在触发条件满足后 24–48 小时内路由产品合格信号（达到使用量阈值、邀请队友），并将底层信号而不只是一个简单评分传递给销售代表。覆盖模式本身是一个排序选择，如下所示。
• 混合模式：在同一层级中运行两条分支——先处理以客户为基础的层级，再将高流量分配作为通用池。

高流量模式的覆盖机制：

• 效率：免触达下限 > 按班次划分的池 > 基于技能的队列 > 全天候接力覆盖

• 投入：全天候接力覆盖（一个季度，而且需要做出招聘决策）> 基于技能的队列（一周，然后建立常设技能矩阵）> 按班次划分的池（一小时，使用团队已经维护的排班表）> 免触达下限（几乎为零）

• **首先设置免触达下限：**一条资格规则将价值最低的自助服务细分群体完全排除在销售之外，这是整个高流量设计中投入产出比最高的一步。它只需设置一个层级，却能减少其下所有规则的流量，因此后续每个变体的成本都会降低。

• **其次设置按班次划分的池：**基于现有排班表提供工作时段内的覆盖。

• **基于技能的队列：**只有在语言或产品能力确实决定了谁能处理线索时才投入，并且需要有人维护每位销售代表的技能字段，确保信息保持最新。

如果团队在其他区域没有员工，就直接删除全天候接力覆盖——它本质上是披着路由规则外衣的招聘决策，而将它降级会让人有机会提议“分阶段引入”。提供即时自动确认的非工作时段队列（层级第 7 级）几乎不花成本就能弥补同一缺口，也应该改为构建这一方案。

故障模式及修复方法

故意不做排名：修复实际观察到的问题症状。按比例对症状驱动的修复方法排序，会造成虚假的精确感。

有两行是例外，它们在任何症状出现之前就已纳入，因为其症状在设计上不可见：

• 针对每个来源的静默告警
• null 赋值时的硬失败分支

症状	可能原因	修复
一条数据导入路径分配的负责人与另一条不同	某条路径绕过了分配规则（API 创建的记录常见此问题）	将相同的合成数据包通过所有路径推送；添加硬失败分支，在未分配负责人时发送页面告警
线索匹配到了错误的规则	随着时间推移出现了重叠条目；较早的条目会静默地优先生效	审核并合并重叠条件；为规则集添加版本；每次出现两条规则同时匹配的情况后，重新记录优先级
规则在字段为空时错误路由	区域或细分市场数据过时或为空	路由前先验证或补充数据，并设置硬超时及明确的缺失字段分支——绝不静默地错误路由
线索被分配给不在岗的代表	没有休假或节假日跳过逻辑；某些平台会将从未设置可用状态的代表视为始终可用	采用基于可用状态的轮换、覆盖人员池，并针对已知假期设置专用规则
周末或非工作时间的线索无人跟进	没有考虑时区或工作时间的分支	采用日不落人员池，或设置非工作时间队列，并规定下一工作时段开始时的 SLA 及即时自动确认
代表质疑分配是否公平	计数相同却掩盖了线索价值差异；或存在作弊行为（如立即关闭线索以获取更多分配）	提供透明的分配日志；将高评分线索与标准池分开分配；监控作弊模式
兜底规则悄然积压	需要人工审核溢出项，但审核从未发生	指定负责人，设定当日工作时间内的 SLA，并进行严格的每周审核——反复出现的异常类型应转化为新规则
仪表板显示正常，管道中却没有数据	来源静默时没有任何告警	按来源监控数据量；在来源静默时告警，而不只是出现错误时告警

衡量指标与通过阈值

将线索响应速度拆解为一系列计时节点：已捕获 → 符合条件 → 已决策 → 已分配 → 已通知 → 已接受 → 首次行动。报告接受差距（已接受减去已分配），即队列滞留和通知失败会被掩盖的时间间隔。

同时跟踪：

• 从未联系的线索数量
• 各销售代表的分布偏斜
• 线索到账户的匹配率
• 兜底队列的数量和滞留时间

发布前，设计必须达到以下所有阈值。持续迭代，直到达标：

• 入站量中的线索到账户匹配率 ≥ 90%；低于此值时，应先返回匹配环节，而不是处理分配。
• 每条摄取路径至少覆盖一个测试用例，并且同一条合成记录在所有路径上都产生相同的所有者。
• 未受监控的队列数量为零：兜底队列（以及任何冲突队列）都必须指定负责人、SLA 和定期审核安排。
• 在试点期间，超过接受 SLA 仍由队列持有的线索数量为零；并且每个来源的流量监控已启用，且静默时会触发警报。
• 分配偏斜须处于团队公平性定义允许的差异范围内，并在试点窗口期内验证，而非根据算法选择想当然地认定。

如果已有用户自身按响应时间统计的转化历史数据，应据此设定响应 SLA。广为人知的紧迫性统计数据（5 分钟 / 21 倍 / 100 倍）来自 2007 年 InsideSales/MIT 的电话时代研究和 2011 年 HBR 审计，常被错误归因；它们证明的是紧迫性，而非路由带来的投资回报。引用任何数字向利益相关方汇报前，请参阅 references/speed-to-lead-evidence.md。

可选集成说明

除非用户点名以下某个平台，否则请跳过本节。

• **Salesforce：**每个对象只能有一条启用的线索分配规则；规则条目按自上而下的顺序进行评估，并采用首个匹配项。通过 API 创建的线索会跳过该规则，除非设置了分配规则标头；原生区域管理不涵盖线索或轮流分配。
• **HubSpot：**轮转公平性按每次轮转操作计算，而非按全局所有权计算，因此，两个各自公平的工作流可能造成总体分配不均。添加或移除所有者会重置轮转。
• **Dynamics 365：**从未设置可用状态的销售人员会被视为始终可用，并会在不知不觉中成为兜底人员。

参考资料

• 有关已整理的优先级阶梯和路由矩阵（B2B 和 PLG 变体）以及反面示例，请参阅 references/precedence-ladder-example.md。
• 有关合成测试包模板以及 sandbox → shadow → canary 发布流程，请参阅 references/test-pack-and-rollout.md。
• 有关可引用的线索响应速度与匹配统计数据（含来源、年份和可信度标记），请参阅 references/speed-to-lead-evidence.md。
• mbfinotti/revops-skills@crm-data-governance：了解路由读取字段的字段所有权和事实来源规则。