MQL 与 SQL 是什么：线索分层怎么做

在很多企业里，市场和销售的矛盾集中在一句话上：市场说”我给了那么多线索，销售为什么不跟”；销售说”这些线索质量太差，根本没意向”。这个矛盾的根源，往往是没有清晰定义 MQL 和 SQL。

MQL（Marketing Qualified Lead，市场合格线索）是指经市场营销触达、符合目标客户画像并表达过一定兴趣的线索；SQL（Sales Qualified Lead，销售合格线索）是指经销售初步确认、有明确需求和一定决策能力、值得深度跟进的线索。 两者是线索从”潜在”到”商机”旅程中的两个关键里程碑。

MQL 是什么

MQL 的核心定义是：市场团队认为值得移交给销售关注的线索。它是线索生命周期中从”原始线索”到”销售商机”的第一道门槛。

达到 MQL 标准的线索，通常需要同时满足两类条件：

条件一：画像匹配（Fit）

• 所在行业是否在目标市场范围内
• 企业规模是否符合目标客户（员工数、营收规模）
• 联系人职位是否是目标决策链上的人（如 IT 负责人、采购总监、运营负责人）

条件二：意向信号（Intent） 以下至少满足一项：

• 主动填写了咨询表单或申请了演示
• 注册了免费试用账户
• 下载了白皮书、解决方案手册等高价值内容
• 参加了线下或线上活动并留下联系方式
• 多次访问了核心产品页或定价页

仅有画像匹配但无任何意向行为的，只是”目标潜客”，还不是 MQL；仅有意向行为但画像不匹配的，也不该进入 MQL，避免浪费销售资源。

这里给你一个能直接抄的打分骨架。画像维度：目标行业 +20 分，非目标行业直接 -30 分当一票否决；员工 50-500 人 +15 分，超 2000 人或不足 20 人各 +5 分（大客户走单独的大客户通道、太小的先丢回培育）；对接人是运营/IT/采购负责人 +15 分，是实习或纯执行岗 +5 分。行为维度：申请演示 +40、注册试用 +30、下载定价手册 +25、7 天内三次以上看定价页 +20、只下载科普类白皮书 +10。然后画一条线，比如满 50 分才算 MQL。你自己拿几条真实线索代进去算一遍就明白：单靠一个下载动作（+10 或 +25）够不到 50 分线，必须”画像达标”叠加”一个强意向动作”才过得了线——这正是同时过滤”只有画像”和”只有行为”两类伪 MQL 的机制。分值不用一开始就精确，先粗糙上线，跑两三个月拿转化率反过来调权重就行。

SQL 是什么

SQL 的核心定义是：销售团队通过初步沟通确认的、有明确跟进价值的商机。SQL 是线索真正进入销售漏斗的起点。

从 MQL 升级为 SQL，通常需要销售通过电话、微信或邮件完成初步接触后，确认以下关键信息：

• 有明确需求：客户能描述具体的业务问题或改进目标
• 有决策参与能力：接触的人是决策者或能直接影响决策的人
• 有一定时间意向：客户有在未来 3-6 个月内解决问题的意愿
• 无明显阻断因素：预算不是硬性阻断、公司没有采购冻结等特殊情况

SQL 不要求客户已经有明确预算或已经启动正式评估，但至少要确认”这个客户值得投入后续销售资源”。

MQL 与 SQL 的区别与流转

维度	MQL	SQL
评估方	市场团队	销售团队
核心依据	画像匹配+行为信号	需求确认+决策确认
进入方式	自动评分或人工筛选	销售初次接触后判断
下一步	移交销售初步接触	进入机会管理/商机跟进
典型停留时长	1-14 天	1-12 周

线索流转路径：

原始线索（Raw Lead）
    ↓ [画像筛选 + 行为评分]
MQL（市场合格线索）
    ↓ [24小时内销售首次跟进]
SQL（销售合格线索）
    ↓ [深度需求挖掘 + 方案评估]
商机（Opportunity）
    ↓ [报价 + 谈判]
成交（Closed Won）

被销售接触后确认无价值的 MQL，要有明确的回流机制——记录原因、返回培育序列或关闭，而不是静静留在系统里成为”僵尸线索”。

市场与销售怎么交接：SLA 设计

SLA（Service Level Agreement，服务水平协议）是市场和销售之间关于线索交接的”契约”。有了 SLA，双方对彼此的职责有清晰预期，减少扯皮。

SLA 核心内容：

市场对销售的承诺：

• MQL 产生后，24 小时内通知到具体销售负责人
• 每条 MQL 包含的基本信息：公司名、联系人、职位、线索来源、触发行为
• 每月 MQL 数量不低于 X 条（具体数字根据销售目标反推）

销售对市场的承诺：

• MQL 接收后，24 小时内完成首次触达（电话或微信）
• 48 小时内在 CRM 中更新线索状态（推进/回流/关闭）
• 回流 MQL 时注明具体原因（画像不匹配/无需求/竞品已在用等）

共同遵守的规则：

• MQL 被驳回的比例超过 X%，需要双方一起复盘 MQL 标准是否合理
• 每季度联合审查一次 MQL→SQL 的转化率，并校准标准

SLA 里最容易被忽略的一环，是把承诺换算成可核对的数字，而不是停留在”尽快跟进”这种模糊表述。举个反推的例子：假设销售团队本季度目标是签 12 单，你按漏斗倒推——成交率 30%，那需要 40 个商机；商机来自 SQL，SQL→商机按 60% 算，需要约 67 个 SQL；MQL→SQL 按 40% 算，需要约 168 个 MQL。这样”每月 MQL 数量不低于 X 条”里的 X 就有了依据（168÷3≈56 条/月），而不是市场拍脑袋报个好看的数。这套倒推做完，市场和销售会第一次对”到底要多少线索”达成共识，很多扯皮当场就消失了。

响应时效也要写成能被系统监控的形式。“24 小时内首次跟进”如果没人统计，等于没写。可行的做法：在 CRM 里给每条 MQL 打上移交时间戳，销售第一次外呼或加微信时自动记录首触时间，两者之差就是响应时长。你把这个字段做成看板，每周拉一次超时清单，谁的 MQL 压了三天没动一目了然。见过一个团队上线这个看板后，平均首触时长从 40 多小时压到 8 小时以内——不是销售突然变勤快了，是”看得见”本身就是约束。

怎么定义你自己的 MQL 标准

没有放之四海而皆准的 MQL 标准。不同行业、不同产品、不同客单价对应的标准差异很大。定义你自己的 MQL 标准，推荐这个过程：

第一步：分析历史成交客户画像 回溯最近 50-100 个成交案例：他们来自什么行业？规模多大？是什么角色？通过什么渠道进来的？这是 MQL 画像标准的数据基础。

第二步：分析高意向行为 哪些行为最终成交率最高？（通常是主动咨询、申请 demo、下载定价手册）这些行为权重应该更高。

第三步：初版 MQL 标准上线，跑 3 个月收集反馈 让销售每次接触 MQL 后填写”是否认可这条 MQL？原因是什么”，积累反馈数据。

第四步：根据数据校准，迭代版本 MQL 标准不是一次定好就不改，而是随着产品定位和市场变化持续迭代的文档。

线索评分体系的详细方法，参考线索评分怎么做：BANT 与 MEDDIC 实操。

转化率怎么看：核心漏斗指标

线索分层体系的健康度，用以下几个转化率衡量：

指标	计算方式	健康参考值
原始线索 → MQL	MQL数 / 总线索数	20%-40%
MQL → SQL	SQL数 / MQL数	30%-50%
SQL → 商机	商机数 / SQL数	50%-70%
商机 → 成交	成交数 / 商机数	20%-40%

参考值因行业和产品不同差异很大，重点是建立自己的基线，然后持续优化。

看这几个转化率时，别只盯着某一段低就急着改那一段。它们是串联的：如果原始线索→MQL 高达 60%，远超参考区间，先别高兴，多半是 MQL 标准太松，把大量画像不匹配的线索也放进来了——代价会转嫁到下一段，你会看到 MQL→SQL 跌到 15% 以下。反过来，如果 MQL 少但 MQL→SQL 高达 70%，说明标准卡得偏严，市场可能漏掉了一批本该培育的潜客。健康的曲线是每一段都落在参考区间内、且相对平稳，而不是某一段畸高畸低。

几个常见误区

误区一：把 MQL 当成”线索够多”的 KPI。 市场为了完成 MQL 数量，不断放宽标准，数字很好看，但销售接到手全是无效线索，最后干脆不看市场给的线索。MQL 的正确目标是”移交给销售后被认可的比例”，而不是绝对数量。盯 SAL（Sales Accepted Lead，销售接受线索）的占比，比盯 MQL 总数更能反映真实质量。

误区二：MQL 一到就立刻塞给销售。 有些线索只是下载了一份资料，意向远没成熟，这时候硬推给销售，客户会觉得被骚扰，销售也会觉得线索差。更稳的做法是设一个”培育门槛”——比如至少完成 2 次以上高价值内容触达、或行为评分达到某个分值，再触发移交。什么时候不该等：客户主动填了”申请演示""要报价”这类强意向表单，别培育了，24 小时内直接联系，等下去就凉了。

误区三：回流的 MQL 没人管。 销售驳回一条 MQL，如果只是简单关闭，这条线索里的信息就浪费了。正确做法是带原因回流到培育序列：画像不匹配的直接关闭并给渠道打标（说明这个来源质量差）；有需求但时机未到的，放回培育，设 1-3 个月后的再激活提醒；预算是唯一阻断的，标记等预算周期。回流原因积累多了，本身就是优化投放和标准的一手数据。

一个真实的落地例子

一家做 SaaS 的团队，早期市场和销售天天互相甩锅。他们做了三件事：第一，把成交客户拉出来复盘，发现真正成交的集中在两个行业、员工 50-500 人、对接人是运营或 IT 负责人——于是 MQL 画像直接按这三条硬卡。第二，行为上只认四个高意向动作（申请演示、注册试用、下载定价手册、多次看定价页），其余行为只加分不单独触发 MQL。第三，SLA 写死：MQL 24 小时内首触、48 小时内更新状态、驳回必填原因。

三个月后复盘，MQL→SQL 从原来的不到 20% 提到 42%，销售不再抱怨线索差，市场也不再被质疑”只会刷数量”。变化的不是投放渠道，而是双方终于在用同一把尺子量线索。这件事的启发很直接：MQL/SQL 标准的价值，一半在标准本身，另一半在市场和销售是不是一起定的、认不认这套标准。

什么时候不该急着上这套分层

不是每个团队都该立刻搭这套 MQL/SQL 分层。如果你一个月总线索还不到三五十条，销售就两三个人、一天能把新进线索全部打一遍电话，那分层带来的收益很小，反而多加一层流程摩擦：市场要维护评分规则、销售要填回流原因、两边还要开会校准，投入产出并不划算。这个阶段更该把力气花在两件事上——把线索总量做起来，把成交客户画像摸扎实。等哪天线索多到销售没法逐条人工判断、必须靠一套标准来决定”先打谁、后打谁、谁先不打”，分层才真正开始产生价值。别为了流程而流程；分层是解决”线索多到管不过来”的工具，不是团队成熟度的勋章。

小结

MQL 和 SQL 是市场与销售协同的语言体系——有了清晰定义，两个团队才能用同一套标准评估线索价值，减少摩擦、提高效率。核心步骤：定义 MQL 和 SQL 的标准、制定 SLA 规范交接流程、定期校准转化数据。

查看销售线索专题，了解从线索获取到转化的完整运营体系。

企客连连正在研发面向中小团队的线索评分与培育工具，欢迎访问 /product/ 加入内测候补名单，提前体验自动打分与移交提醒。