MQL 已经分给销售却没人跟，先补上“接受”这一步

市场团队打开 CRM，看到新来的 MQL 已经有负责人，往往会认为交接已经完成。几天后再查，销售活动仍然是空的：没有电话，没有邮件，也没有退回原因。销售说线索质量差，市场拿出分配记录，双方都能找到对自己有利的数字。

这个场景里，最值得先查的动作很具体：销售有没有明确表示“我接了”。分配只说明系统把记录送到了谁名下；接受说明销售看过线索，愿意在约定时间内推进。把两者记成同一个状态，路由错误、响应延迟、信息缺失和销售超负荷都会被混成一句“没人跟”。

CRM 有负责人，仍不等于销售已经接手

HubSpot 的生命周期文档称 MQL 是市场团队认为已适合交给销售的联系人或公司，SQL 则是销售团队确认有潜在购买价值的联系人或公司。两个结论来自不同主体，系统里也应留下两个动作。Adobe Marketo 的收入周期示例同样把 marketing qualified lead 与 sales accepted、actively working 分开。

这一区分能回答一个经常被漏掉的问题：一条线索从市场队列离开以后，是否真的进入了销售的工作队列？如果 CRM 只有 owner 和 MQL=true，团队只能证明“系统分过了”；加上 accepted_at、accepted_by 和接受结果，才能看出销售何时看过、是否愿意接、准备做什么。

有些团队沿用 MQL→SQL，不单设 SAL（Sales Accepted Lead）这个名称，原有阶段也可保留。关键在于增加一个可回查的接受动作，避免 SQL 同时承担“销售看过”和“销售完成资格确认”两层含义。

先把“没人跟”拆成四个可查故障

线索没有进入有效沟通，常见原因应沿着实际发生顺序查。

第一种是分错人。 地区、行业、客户规模、语言或存量客户归属没有进入路由规则，线索先落到无权或不适合跟进的人名下，再被手工转来转去。此时调整 MQL 分数帮助不大，团队该查的是首次路由准确率和改派记录。

第二种是到得太晚。 线索在市场系统里已经达标，却要等运营人员整理表格、销售主管二次分配。Salesforce 对销售与市场 SLA 的建议同时包含合格线索口径、跟进时限和拒绝反馈，说明计时应从交接动作开始，而不能只看销售最后有没有建商机。早期响应研究也显示，网络表单线索的联系和资格确认几率会随等待时间快速下降；这项研究来自较早的美国电话跟进样本，适合提醒团队记录时间，不适合拿来给所有业务统一规定“五分钟”。

第三种是信息不够。 销售只收到姓名、电话和一个总分，不知道潜客看过哪一页、填写了什么、来自哪场活动，也不知道市场为何在今天判定他值得跟。销售要重新做一遍研究，优先级自然会落到手里那些背景更清楚的机会。

第四种是无人表态。 线索被分配后既没有接受，也没有退回；负责人休假、离职或手上已有更高优先级机会时，它会一直停在“已分配”。这时要查接受截止时间、超时提醒和重新分配规则，同时把销售容量放进路由条件。

LeanData 的交接实务指南把相近问题归为响应时间、路由准确性、交接上下文、接受或拒绝入口以及审计记录。把故障拆开以后，市场与销售讨论的对象就从笼统的“线索好不好”变成了具体字段、时间和动作。

交接记录要回答“为什么匹配、为什么现在”

销售接到线索时，最有用的并非更长的活动履历，而是一段能帮助他决定第一句话怎样开场的上下文。交接记录至少应包含五组信息：

假设一家制造业软件公司收到一条演示申请。记录里写“华东地区、中型制造企业、生产负责人、来自排产功能页”，能解释为什么匹配；表单中的“计划今年替换现有系统”能解释为什么现在值得联系。这个场景只用于说明字段。它没有预设客户会回复，也没有预设销售一定能把线索转成商机。

近期，Reddit 的一场公开从业者讨论提到在交接中增加一句 why now。匿名经验无法证明效果，但这个字段很实用：它迫使市场写清这次转交由哪个新信号触发，也让销售可针对具体信号提出异议。

接受、退回和回收要留下不同结果

销售看完交接记录后，至少应有三种去向。

接受，表示负责人同意在 SLA 内完成首次联系。系统记录接受时间，开始计算从接受到首次有效动作的间隔。后续联系不上，应进入“已尝试联系”或“暂无响应”，不要把它改写成线索不匹配。

退回，表示销售已经看过，并给出一个市场能够处理的原因。公司规模不符、地区不覆盖、身份不对归入不匹配；项目真实但采购时点较远，则进入继续培育。Adobe Marketo 在旁路阶段中就把 Disqualified 与 Recycled 分开：前者偏向不符合画像，后者仍符合条件，只是有待更多培育。

回收，处理的是负责人没有在约定时间内动作。线索可回到公共池、改派给有容量的人，或由销售运营介入。国内营销自动化服务商 JINGdigital 的线索培育流程也把超时回收、退回培育和再次分配列成不同动作。这样做能保留一个重要事实：线索尚未经过销售审核，不能因无人处理就被算作低质量。

团队准备把阶段口径、评分、路由、SLA 和 CRM 必填字段整理成同一份规范时，可使用 B2B RevOps 营收运营工具。它会根据现有阶段和历史成单资料，输出线索生命周期标准、评分模型、分配规则与字段清单，方便销售运营继续配置 HubSpot 或 Salesforce。

Zendesk 的问题先出在“交给谁”

路由错了以后，销售的沉默很容易被市场理解成“不信任线索”。Zendesk 的公开客户故事给了一个更具体的过程。

随着 Zendesk 扩张到多个销售区域，原有轮询分配很难处理语言和地区条件。例如，一些来自非洲地区、需要法语销售跟进的线索会落到错误的人手里。销售团队要自己核对客户资格，还专门建了一个 Slack 频道寻找真正的负责人。记录看起来已经有人负责，销售实际仍在做二次分拣。

根据 LeanData 发布的 Zendesk 客户案例，团队用六周实施新的路由方案，允许营销运营调整复杂规则，并在负责人没有响应时自动改派。案例称路由时间从 45 分钟降到约 8 分钟，每周自动处理约 4,100 条线索，手工分配工作量也随之下降。

这些数字由产品供应商披露，没有独立审计，所以更适合用来理解改动顺序：先把语言、地区和负责人规则写清，再记录路由时间与重分配。案例能证明 Zendesk 在特定时期减少了路由摩擦，无法单独证明相同工具会给其他团队带来同样幅度的结果。

每周先看交接中段，再讨论线索质量

许多周报一头看 MQL 数量，一头看商机和收入，中间几步只剩一条转化率。这样一来，团队看到 MQL→SQL 下降，仍分不清是市场交得宽、系统分得错、销售接得慢，还是客户暂时联系不上。

更有用的周报会同时看四类数：本周分配量是流入；当前未接受和已接受未联系的数量是存量；从分配到接受、从接受到首次联系的中位时间是速度；接受率、退回原因分布和 MQL→SQL 是结果。再按来源、区域和销售团队切开，同一项问题会更容易露出来。

Adobe Marketo 的阶段分析文档也把“有多少人曾进入某阶段”“当前有多少人停在这里”“到达当前阶段花了多少天”列为不同问题。数量、存量和耗时一起看，才能找到线索堆在哪一处。

如果网站侧还没有统一记录定价页访问、演示表单提交和 CTA 来源，可用 营销数据追踪工具从业务问题倒推网页事件、参数和身份逻辑，整理成 GA4/GTM 的追踪表与上线检查清单。销售接受、退回、首次联系和商机创建继续以 CRM 记录为准，具体状态与时间戳由 RevOps 和 CRM 管理员配置，避免两个系统各自解释一次。

刚开始时，先选一个高意向来源，例如官网演示申请。抽查最近两周的记录，补齐接受时间、退回原因和首次联系时间，再观察有多少线索停在每个阶段。等这一条路径能稳定说明“谁接了、何时接、为什么退、下一步去哪”，再把规则扩到活动名单、内容下载和其他来源。回到最初那条有负责人却没有动作的 MQL，团队应该能从记录里直接看出它卡在哪里。