MQL（Marketing Qualified Lead，本页称“市场认可线索”）和SQL（Sales Qualified Lead，本页称“销售认可线索”）的核心区别，不是英文字母不同，而是判断人、所掌握的证据和要决定的下一步不同。MQL由市场依据市场与销售共同约定的条件作出，回答“为什么值得进入销售沟通”；SQL由销售在进一步核实后作出，回答“为什么值得继续业务推进”。二者都是当前状态，不是成交承诺，也不是对联系人的永久价值评级。需要把交接依据写成可执行标准，可继续阅读MQL最低条件。
本页使用“市场认可线索”和“销售认可线索”作为中文解释。行业资料中也常见“市场合格线索”“销售合格线索”。翻译可以不同，实施时应在企业词典中选择一种，并把进入依据写清。想先了解完整阶段，可阅读线索生命周期通常包含哪些阶段；本页只聚焦MQL、销售接收与SQL三者的边界。
MQL回答市场为什么愿意交接
市场通常先看见访问来源、内容接触、表单信息、活动提问和初次沟通。MQL意味着这些已知信息达到双方约定的最低条件，值得由销售继续核实。它不表示市场已经替销售完成需求访谈，也不表示客户已经形成采购项目。
一条可解释的MQL记录应能指出：联系人和企业背景如何得到确认，对方此刻提出什么问题，问题是否落在当前服务范围内，对方是否愿意进行相关的下一步沟通，以及还有哪些信息未知。只写“MQL，意向高”不能帮助接手者工作。
SQL回答销售为什么继续推进
销售在读取市场交接后，通过真实沟通补充市场暂时无法确认的信息，例如业务问题的范围、谁会参与评估、客户希望本轮讨论得到什么结果、推进中有哪些限制，以及双方能否约定下一步。达到本企业销售资格规则后，才形成SQL。
SQL仍不是订单。销售可能在后续发现问题不适配、时机变化或客户不再继续。准确做法是更新事实和状态，而不是为了让漏斗看起来顺畅，长期保留一个已经失去依据的SQL。
销售接收与SQL是两类事实
本课把“销售确认收到并承担后续动作”单独称为已接收。有些企业会把它命名为SAL，即Sales Accepted Lead；也有企业不设置SAL，直接把接收动作放进SQL流程。名称可以选择，接收与核实不能消失。
系统把记录分配给小周，只证明路由发生；小周点击或明确回复接收，证明责任转移；小周与客户沟通并获得新的业务证据，才可能形成SQL。把三步压成一个“已转销售”，就无法判断问题出在分配、响应还是资格核实。
为什么需要市场与销售两次判断
两次判断不是让客户重复回答同一套问题，而是让掌握不同信息的人对各自能确认的部分负责。市场擅长保存来源、内容背景和初步来意；销售更接近合作范围、组织参与和后续推进。合理交接会让信息逐步增加，而不是每换一位同事就从姓名电话重新开始。
如果企业业务简单，也可以减少状态数量，但仍要能回答：谁判断可以交接，谁确认接手，谁依据什么继续推进。流程精简不等于事实省略。
判断对象不是一个抽象分数
MQL和SQL都应关联正确联系人与企业账户。一个人在同一企业中可能只是资料阅读者，也可能代表具体业务问题；同一家企业还可能有多位联系人参与。同一个分数无法替代对象关系和客户原话。
行为评分可以帮助排序，但一次下载、连续浏览或达到阈值只证明规则触发。求职者、同行研究者和已有客户也可能频繁访问。达到分数后仍要核实身份、来意和服务边界，不能把自动计算直接包装成真实需求。
教学例子：同一条联系怎样增加证据
**以下为教学例子，不是真实客户案例。** 林经理下载线索交接表，并说明自己负责一家B2B软件企业的市场工作。此时能确认联系人、企业背景和内容需要，但尚不知道他是否希望讨论服务，不应自动标记MQL。
小陈继续询问，林经理说市场与销售各自保存表格，退回原因长期只写“没需求”，并愿意与销售负责人一起讨论规则。企业和问题在本次教学设定的服务范围内，也有明确下一步，因此可以按教学标准记录MQL。销售小周接收后，进一步确认双方要梳理的流程范围、参与人和下一次交流，达到销售侧规则后才标记SQL。
一次状态变化至少留下什么
每次变化至少记录原状态、新状态、时间、判断人、判断依据、未知事项、当前负责人和下一步。客户原话与团队判断分开写，例如“客户说想先内部讨论”是原话，“当前符合MQL最低标准”是基于规则的判断。
规则版本同样重要。企业修改MQL标准后，历史数据不能假装一直按新标准产生。计算转化率之前，应确认两个阶段的对象、时间窗口和口径一致，方法可参考B2B营销指标如何定义。
哪些情况不应升级
无法识别联系人、需求明显超出服务范围、明确拒绝继续联系或只是索取公开资料，都不应因为销售需要数量而升级。预算和时间暂时未知则未必需要排除，可以保留未知并说明由谁在什么场景核实。
同样，销售已经接收但没有完成沟通，不能只因系统等待了一段时间就自动变成SQL。状态必须由业务事实推动，提醒可以自动化，判断责任不能悄悄交给计时器。
怎样用样本校准两个定义
让市场与销售分别阅读同一批已脱敏记录，独立判断是否为MQL、是否已接收、是否为SQL，并写出依据。结论不一致时，不先争论谁更懂客户，而是检查定义、字段或证据是否缺失。
校准结果应形成共同词典：每个状态的定义、进入条件、排除项、责任人、下一步和例子。随后用真实运行样本复查，不能把一次会议决定当成永远不变的行业标准。
常见误区会怎样伤害协作
把MQL当订单，会诱导市场过度承诺；把接收当SQL，会让销售管道虚高；把SQL当商机，会隐藏仍待确认的合作事项；把所有退回写成“差”，又会让市场无从改进。名称相同也不代表不同团队的数据可直接相加。
更稳妥的做法是把每项指标拉回原始记录。若只有状态名称变化而没有新增证据，报表看起来前进，客户沟通实际没有进展。有关完整协作规则可继续阅读B2B市场与销售SLA怎么制定。
把定义写进流程时还要做什么
共同词典不能只存在培训文档里。表单、营销系统、CRM和周会应使用相同定义，并分别保存分配、接收与核实事件。界面可以隐藏不常用字段，但原始依据和历史状态不能因为当前只显示一个标签而丢失。自动提醒只负责通知负责人，不能替负责人确认客户事实。
还要指定例外处理：重复账户由谁合并，已有客户的新咨询由谁接手，销售暂时没有容量时如何排队，无法确认身份时放在哪里。每种例外都要保留客户体验，避免多个同事重复联系或把客户推回无人负责的列表。
词典还应给出正例、反例和待确认例。正例说明什么证据足以进入，反例说明哪些行为不能替代判断，待确认例说明信息不足时放到哪里。只写一句定义而没有样本，同事仍会按各自经验解释；只有样本、字段和责任一起明确，术语才会进入真实工作。
每个例子还要写明不应推断的内容，防止培训材料在执行中变成夸大判断。
季度或业务变化后重新抽样。若标准修改，记录版本、生效日期和受影响报表；历史数据按当时口径解释，不把定义变化包装成转化改善。只有定义、系统字段和日常动作一致，MQL与SQL才是可用的管理语言。
本页完成结果
读完后应能交付一张三列对照表：MQL、销售接收、SQL分别由谁确认，最低依据是什么，下一步由谁负责；再用一条教学或脱敏记录写出三次独立状态事件。如果团队仍只能说“转销售了”，就继续补接收和核实证据。
最终要记住：MQL负责解释市场为何交接，销售接收负责确认责任已经转移，SQL负责解释销售为何继续推进。三者可以采用不同名称，却不能被一个模糊标签替代。