什么是销售认可线索（SQL）？判定标准、框架与衡量指标

什么是销售认可线索（SQL）？

销售认可线索（SQL，也写作销售合格线索），是销售人员按事先约定的标准审核过、并确认值得进入正式销售沟通的潜在客户。审核通常看两件事：对方符合你的理想客户画像，并且表现出真实的购买意向——比如预约演示、询问价格、回复了开发邮件。Salesforce 的 SQL 指南划的是同一条线：线索经过销售审核、被接受进入管道下一步，才算 SQL（Salesforce）。

SQL 处在原始线索和商机之间。它还不是一笔交易：没有金额、阶段和预计成交日期。它只是销售愿意花时间跟进的人或公司。「销售确认」是这个概念的核心——没有销售点头，再像样的线索也还只是线索。有些团队靠产品使用行为而不是沟通来判定线索，那是另一条路径：产品认可线索（PQL），标准不同，别混在一起数。

SQL 和 MQL 有什么区别

市场认可线索（MQL）是市场按匹配度和行为信号（下载、访问页面、点击邮件）打分后认为可能购买的潜在客户，但销售还没有接手。SQL 则是销售确认过匹配度和意向、愿意跟进的同一类线索。区别在于谁拍板、凭什么拍板：市场看信号，销售看对话。两个阶段怎么交接、交接时容易吵什么，见 MQL 与 SQL 的区别；本页只讲 SQL 这一侧。

判定框架：BANT、CHAMP、MEDDIC

「合格」到底指什么，团队不写下来就会各说各话。常见框架有三个：选一个、按自己的业务改短，短到 SDR 在一通电话里就能用。

• BANT：预算（Budget）、决策权（Authority）、需求（Need）、时间（Timing）——对方有没有钱、谁签字、要解决什么问题、什么时候要解决。中小销售团队的经典起点（HubSpot）。
• CHAMP：挑战（CHallenges）、决策权（Authority）、资金（Money）、优先级（Prioritization）。它把对方的问题放在预算前面，适合痛点还不明显、需要先做顾问式沟通的场景（Revenue.io）。
• MEDDIC：指标、经济决策人、决策标准、决策流程、识别痛点、内部支持者，六项清单。比 BANT 重，适合决策链长、周期长的企业级大单（MEDDIC Academy）。

框架是清单，不是分数。不管选哪个，产出都一样：销售说得出为什么值得跟进，下一个人查得到依据。

由谁确认 SQL？

确认 SQL 的是销售，不是市场，更不是一次表单提交。多数团队里，SDR（销售开发代表）负责资格判定电话，AE（客户经理）把线索接进自己的管道。微软 Dynamics 365 的官方培训描述的也是这个流程：销售按组织的标准判定线索，判定通过才往商机推进（Microsoft Learn）。

三个习惯能让这个标签保持诚实：

1. 把标准写下来：匹配度加意向，用大白话写，附上「不算」的例子。
2. 在 CRM 里记录判定：谁确认的、什么时候、按哪条标准。判定和打分都在 CRM 里做；表格里的一个标签不算 SQL。
3. 市场提供证据，不下结论：来源、UTM、浏览轨迹、客服对话记录都能帮 SDR 判断，但市场不给自己产生的线索贴 SQL 标签。

SQL 转商机率与平均成交周期

两个数字就能看出 SQL 的标准有没有起作用，都是从 CRM 导出就能复算的比率。

SQL 转商机率 = 商机数 ÷ SQL 数（结果写成百分比）。 先数一个周期里确认了多少 SQL，再数其中多少变成了商机（带金额和阶段的交易）。比率低，说明销售接了跟不动的线索；比率高得反常，可能是标准严到只放「稳赢」的线索进来。

平均成交周期 = 从 SQL 确认到成交的天数总和 ÷ 成交单数。 起点用 SQL 确认日期，不用首次表单提交日期，这样量的才是销售真正控制的周期。

示例数据：一个季度确认 80 个 SQL，28 个转成商机，其中 10 个成交。这 10 单从 SQL 到成交的天数分别是 24、31、18、45、27、38、22、51、33、41。

一个提醒：33 天只算了已成交的单。还开着的 18 个商机——尤其是拖得久的那些——不在平均里，真实周期通常更长。这两个比率按季度跟自己的趋势比，比任何公开基准都有用。整条漏斗的算法见线索转化率。

SQL 太少或太多时查什么

数量本身就是诊断信号。改定义之前，先查它前后的环节。

SQL 太少，倒着查：标准是不是太严（比如没确认预算就不算）？MQL 质量是不是不行——来源不对、人群不对？交接是不是断了，SDR 根本没打市场给的线索？来源结构是不是变了，进来的都是不匹配的渠道？先修真正漏水的环节，再考虑放宽 SQL 标准。

SQL 太多，查相反的毛病：标准太松，每个演示请求都算；销售为了完成指标随手标 SQL；SQL 转商机率低却没人复盘。一大堆变不成商机的 SQL，比一份小而诚实的名单更糟——它掩盖了真实的转化问题，还浪费 SDR 的时间。

常见误区

• 把每个演示请求都当 SQL：表单提交是意向，不是资格。仍然要有人确认匹配度和时机。
• 让市场自己标 SQL：产生线索的团队同时给线索打分，数量会虚高，销售也不再相信这个数。
• 只数 SQL，不看商机转化：数量看着像进展；SQL 转商机率才说明判定有没有用。
• 平均周期只算已成交：还开着的长周期单被排除在外，周期显得比实际短。写清楚平均覆盖了哪些单。
• 中途改标准不通知：季度中途挪了门槛，比率的变化就和线索质量无关了。

在 TapCub 里怎么看线索证据

确认 SQL 是在 CRM 里由人做的判断；TapCub 不是 CRM，也不做线索打分。它回答的是销售接手一条线索前会问的三个问题。

• 从哪儿来？ 网站统计 › 来源 显示这次访问背后的渠道、来源和 UTM 活动，销售开发能看出线索来自付费活动、搜索还是推荐。
• 做过什么？ 对已识别的用户（用 tapcub.login），全端分析 › 用户 › 用户 的档案里有按天排列的事件时间线：看过的页面、提交的演示申请、价格页访问。资格和意向按行为来判断，这正是 BANT 一类框架里「需求」和「时间」两项要问的。
• 说过什么？ 聊过的话，客服 › 客服工作台 会把对话和他当前的页面、来源、最近两天的浏览轨迹放在一起，点「在统计中查看」能打开访客档案。客服和统计用同一个访客 ID，不用手工对人。
• 哪些行为预示着 SQL？ 把通常发生在接受之前的动作，比如演示申请，在 网站统计 › 目标 里标成转化；SQL 太少或太多时，按活动比较这些目标的转化率。

资料来源

• Salesforce，Sales qualified lead 定义与判定步骤。
• Microsoft Learn，线索到商机流程（Dynamics 365）。
• HubSpot，BANT 销售资格判定框架。
• Revenue.io，什么是 CHAMP。
• MEDDIC Academy，MEDDIC 销售方法论清单。