mcpField

sales-lead-routing

github.com/sales-skills营销与增长60 次安装
代码仓库

关于 sales-lead-routing

面向销售团队的工具无关型技能,用于设计和实施销售线索分配。内容涵盖路由模型、分配与回退规则、销售平台实施及效果评估。

主要功能

  1. 01选择路由模型
  2. 02制定优先级分配规则
  3. 03规划响应时限与超量回退
  4. 04销售平台实施指引
  5. 05路由指标与复盘周期

适用场景

  1. 01为销售团队选择分配模型
  2. 02制定线索分配和回退规则
  3. 03在 Salesforce 或 HubSpot 中实施路由
  4. 04评估响应速度和转化指标

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/sales-skills/sales --skill sales-lead-routing

安装后在 Claude Code 中输入/sales-lead-routing确认已加载。

附带文件references/learnings.md

详细介绍

设计销售线索分配规则

帮助用户设计和实施销售线索分配方案——从选择分配模式和定义分配规则,到平台实施、优化线索响应速度和管理处理能力。此技能不依赖特定工具,涵盖 Salesforce、HubSpot、Salesloft、Apollo 和独立的线索分配工具。

步骤 1 — 收集背景信息

如果存在 references/learnings.md,请先阅读以了解积累的知识。

询问用户:

  1. 你的团队架构是什么?

    • 有多少名销售代表(SDR、AE,或两者都有)?
    • 销售代表是否有专门分工(按细分市场、区域、垂直行业),还是通才?
    • 是否有分级的资历层级(资深销售代表与初级销售代表)?
  2. 销售线索来自哪里?

    • A) 入站(网站表单、内容、活动)
    • B) 外呼(SDR 开发、冷外呼)
    • C) 产品主导(注册、试用、PQL)
    • D) 合作伙伴/渠道
    • E) 混合 — 请说明
  3. 目前如何分配销售线索?

    • A) 手动分配(经理分配)
    • B) 轮流分配
    • C) 基于区域分配
    • D) CRM 自动化规则
    • E) 没有系统 — 先到先得
    • F) 从头开始
  4. 你使用哪些工具?

    • CRM:Salesforce、HubSpot、Pipedrive,其他
    • 销售互动:Salesloft、Apollo、Mailshake,其他
    • 分配工具:LeanData、Chili Piper、Distributely,暂无
  5. 销售线索量有多少?(每周或每月的入站销售线索量,大致估算)

如果用户的请求已提供大部分背景信息,请直接跳到相关步骤。 根据合理假设(明确说明)先给出尽力而为的答复,然后仅在末尾询问最关键的 1–2 个澄清问题——不要以收集完整背景信息为由延迟答复。

步骤 2 — 分配模式框架

根据团队架构和销售线索特征选择合适的分配模式。

决策矩阵
模式适用场景团队规模复杂度线索响应速度
轮流分配平均分配、通才团队任意低快
基于区域地理区域或指定客户专门分工4 名以上销售代表中快
基于评分根据销售线索质量匹配销售代表技能6 名以上销售代表高中
基于客户有指定负责人的指定客户采用 ABM 的任意规模团队中快(若已有负责人)
混合有多个细分市场的复杂组织10 名以上销售代表高不定
轮流分配
  • 工作方式:按轮换顺序将销售线索平均分配给每位销售代表
  • 变体:简单轮换(A→B→C→A)、加权(A 分配 40%,B 分配 30%,C 分配 30%)、考虑可用状态(跳过休假的销售代表)
  • 适用场景:小型团队、销售线索质量相近、无需专门分工
  • 局限性:不考虑销售代表技能、销售线索质量或区域
基于区域
  • 工作方式:根据地理区域、行业垂直领域或公司规模细分市场分配销售线索
  • 区域类型:地理区域(北美西部、北美东部、EMEA、APAC)、垂直领域(医疗保健、金融科技、SaaS)、细分市场(SMB、中型市场、企业)
  • 适用场景:团队拥有区域/垂直领域专业知识,且规模足以进行专门分工
  • 局限性:如果各区域的销售线索量不同,分配会不均衡
基于评分
  • 工作方式:高分销售线索分配给资深/经验丰富的销售代表,低分销售线索分配给 SDR 进行资格审核
  • 分层:热门(80 分以上 → 资深 AE)、温热(50–79 分 → 普通 AE)、冷门(30–49 分 → SDR)、低于 30 分 → 培育/弃置
  • 回退规则:将未评分的销售线索(数据缺失 = 无评分)分配给 SDR 进行人工资格审核。如果某层级的销售代表已满负荷,则将超出的销售线索分配给下一低层级(例如,如果所有资深 AE 都已满负荷,则将热门销售线索分配给普通 AE 团队)。设置每位销售代表的处理量上限(例如,每周最多 30 条销售线索),并在销售代表达到上限时自动重新分配。
  • 适用场景:已建立销售线索评分机制的团队(参见 /sales-lead-score)、销售代表经验分层
  • 局限性:需要可用的评分模型;评分不佳会导致分配不佳
基于客户账户
  • 工作方式:将线索匹配到现有客户账户的负责人。全新客户账户通过其他模型进行分配。
  • 逻辑:检查线索所属公司是否匹配现有客户账户 → 分配给客户账户负责人。如果没有匹配项 → 回退到轮询分配或区域分配。
  • 适用场景:ABM 团队、指定客户账户策略、防止销售代表之间发生冲突
  • 局限性:需要干净的客户账户数据并进行去重

步骤 3 — 设计分配规则

优先级瀑布

按优先级瀑布设计分配规则——匹配到的第一条规则生效:

优先级规则示例
1匹配现有客户账户线索所属公司匹配已分配负责人 的客户账户 → 分配给客户账户负责人
2指定客户账户列表公司在目标客户账户列表中 → 分配给指定 AE
3评分阈值评分 ≥ 80 → 分配给资深 AE 池
4区域匹配地理位置/细分市场匹配区域 → 分配给区域负责人
5轮询分配回退未匹配其他规则 → 在可用销售代表之间轮询分配
线索响应时效 SLA

线索响应时效是分配中最重要的指标。响应时间会直接影响转化率:

响应时间转化影响
< 5 分钟与 30 分钟相比,获得资格认定的可能性高出 8 倍
5-30 分钟基准
30-60 分钟资格认定率下降 50%
> 1 小时下降 80% 以上
> 24 小时基本无望 — 最好重新进行培育

按线索类型给出的 SLA 建议:

  • 入站演示请求:< 5 分钟
  • 入站内容下载:< 1 小时
  • PQL(产品驱动):< 15 分钟
  • 外呼响应/回复:< 1 小时
  • 合作伙伴推荐:< 30 分钟
超额分配与回退规则

如果分配的销售代表无法及时响应,会发生什么:

场景回退方式
销售代表未在 SLA 时限内响应升级给经理 + 重新分配给下一位可用人员
销售代表不在岗在轮转中跳过,分配给替补人员
区域负责人已达承载上限溢出到相邻区域或 SDR 池
不存在客户账户负责人回退到轮询分配
冲突解决
  • 多位销售代表认领同一条线索:由客户账户负责人优先处理。如果没有客户账户负责人,则按首次接触归因。
  • 线索匹配多个区域:以主要区域为准(在区域规则中定义主要区域)。
  • 现有客户的新联系人:分配给客户账户负责人,而不是轮询分配。
  • 回收/重新参与的线索:如果原负责人仍在团队中,则分配回原负责人;否则采用轮询分配。

步骤 4 — 平台实施

Salesforce
  1. 分配规则:Setup > Lead Assignment Rules — 定义条件并分配给用户或队列
  2. 队列:为人员池创建线索队列(SDR 池、AE 池、区域队列)
  3. Flow Builder:用于复杂逻辑 — 基于评分的分配、客户账户匹配、SLA 升级
  4. 匹配规则:Setup > Duplicate Management > Matching Rules — 将线索与现有客户账户匹配
  5. 升级规则:Setup > Escalation Rules — 如果未在 SLA 时限内联系,则自动升级
  6. 第三方工具:使用 LeanData 或 Distributely 实现高级分配,并使用可视化规则构建器
HubSpot
  1. 线索轮转:Settings > Users & Teams > Lead Rotation — 内置轮询分配
  2. 工作流:Automation > Workflows — 根据属性构建基于 if/then 的分配逻辑
  3. 联系人负责人分配:使用工作流操作,根据区域、评分或客户账户设置负责人
  4. SLA 监控:创建工作流,如果负责人在 X 小时内未记录活动,则重新分配
  5. 第三方工具:使用 Chili Piper,根据表单实现实时预约和分配
Salesloft
  • Rhythm 分配:Rhythm 为销售代表安排操作优先级 — 通过 CRM 同步配置分配
  • 销售节奏分配:根据 CRM 分配情况自动将线索导入销售节奏
  • 轮询分配:并非原生支持 — 在 CRM 中处理分配,并将分配结果同步到 Salesloft
Apollo
  • 序列分配:将联系人分配到特定销售代表负责的序列
  • CRM 同步:Apollo 遵循 CRM 中的所有权归属——在 CRM 中路由,再同步到 Apollo
  • 列表:为每位销售代表/每个区域创建筛选列表,并据此分配序列

第 5 步——衡量效果

关键指标
指标目标说明
线索响应速度< 5 min(入站演示申请),< 1 hr(其他)销售代表的响应是否足够快?
线索接受率> 80%销售代表是否接受或拒绝分配的线索?接受率低说明定向或路由不佳
按路由划分的转化率对比不同模型哪种路由路径的转化效果最好?可识别表现不佳的特定区域或层级
产能利用率每位销售代表 70-90%销售代表是否负荷过重或利用不足?调整权重或区域
挑拣线索比例< 10%销售代表是否忽略低分线索?可能需要强制执行 SLA 或调整评分
优化节奏
  • 每周:检查线索响应速度和接受率
  • 每月:按路由检查转化率,调整权重或区域
  • 每季度:全面审查路由模型——模型是否仍与团队结构和线索来源相匹配?

注意事项

  • 不要在补充信息之前进行路由。 如果收到的线索只有电子邮件地址(例如来自表单),请先补充公司数据再进行路由。缺少公司/职位数据,就无法根据区域和评分进行路由。使用 /sales-enrich 在路由前补全缺失信息。

  • 不要忽视线索响应速度。 响应缓慢的完美路由模型,不如响应迅速的简单轮询分配。如果只能优化一项,就优化线索响应速度。数据很明确:5 分钟与 30 分钟的响应速度,在资格判定上相差 8 倍。

  • 简单方案奏效之前,不要过度复杂化。 从轮询分配开始。只有在数据表明区域路由或基于评分的路由能提高转化率时,才添加这些规则。复杂度会增加维护负担和故障模式。

  • 自我改进:如果发现本文未涵盖的内容,请将其附加到 references/learnings.md,并注明今天的日期。

相关技能

  • /sales-qualified — Qualified 平台帮助(基于 Salesforce 的实时网站聊天线索路由)
  • /sales-lead-score — 设计为基于评分的路由提供依据的评分模型
  • /sales-enrich — 补充路由规则所需的线索公司/职位数据
  • /sales-prospect-list — 构建按区域预先划分的潜在客户列表
  • /revops — 设计更广泛的营销到销售交接流程
  • /sales-cadence — 为不同路由细分设计跟进节奏
  • /sales-do — 不确定该使用哪项技能?路由器会将任何销售目标匹配到合适的技能。

示例

示例 1:为成长中的团队设置轮询分配

用户表示:“我有 8 位 SDR,每周大约有 200 条入站线索。应该如何分配?” 技能执行:

  1. 建议以加权轮询分配作为基准方案(初始时平均分配)
  2. 设计 SLA 规则:演示申请 < 5 min,内容线索 < 1 hour
  3. 添加销售代表达到产能上限或不在岗时的溢出规则
  4. 提供 HubSpot/Salesforce 实施步骤 结果:带有 SLA 和溢出处理的轮询分配路由
示例 2:区域路由

用户表示:“我需要为 4 位 AE 设置区域路由:北美西部、北美东部、EMEA 和 APAC。” 技能执行:

  1. 按地理位置定义区域规则(将国家/州映射到各区域)
  2. 处理可覆盖地理位置规则的指定客户
  3. 为地理位置未知的线索添加回退规则
  4. 提供 CRM 实施步骤 结果:带有指定客户覆盖规则和地理位置回退规则的区域路由
示例 3:基于评分的分层路由

用户说:“我想将高分潜在客户分配给资深销售,将低分潜在客户分配给 SDR。我们使用 HubSpot。” 技能执行的操作:

  1. 为分层路由定义评分阈值(热门/温热/冷淡)
  2. 将不同层级映射到销售人员池(资深 AE、普通 AE、SDR)
  3. 为未评分的潜在客户添加后备方案
  4. 提供 HubSpot 工作流实施步骤 结果:根据评分阈值进行分层路由、分配销售人员池并设置后备规则

故障排除

潜在客户迟迟无人跟进

症状:潜在客户已分配,但未在 SLA 规定的时间内联系 原因:销售人员负荷过重、未执行 SLA,或潜在客户在非工作时间分配 解决方案:添加升级规则——如果在 SLA 规定的时间内没有活动,则重新分配给下一位可用人员。为每位销售人员设置容量上限。根据工作时间/时区进行路由。

分配不均

症状:部分销售人员获得的潜在客户数量是其他人的 3 倍 原因:区域分配不均、加权轮询配置错误,或账户匹配导致过多潜在客户分配给同一负责人 解决方案:每月审查各区域的数量。调整权重以实现均衡。设置容量上限,防止任何一位销售人员每天获得超过 X 个潜在客户。

销售人员争抢潜在客户归属权

症状:多位销售人员声称同一潜在客户或账户归自己所有 原因:路由中缺少账户匹配步骤,或 CRM 中存在重复账户 解决方案:将账户匹配作为路由流程的第一步。在 CRM 中清除重复账户。明确规则:对于现有账户,始终由账户负责人优先跟进。

评论

支持 Markdown