一、同一个词、三种不相干的工作

每一套 B2B CRM 都背着一笔悄悄的账——同一个词「lead」，同时承担着三种毫不相干的工作，并把管道报表里的数字平均注水约 18%（HubSpot State of Marketing 2026）。business lead 不是 marketing lead，也不是 sales lead；它们在表达什么、由谁负责、多快腐烂、转化一件值多少钱上都不一样。本文要做的事很具体：定出严格的三层分类，给层与层之间的边界挂上 2026 年的转化率，指出每一层在哪一刻悄悄死于数据腐烂，并提出 account-based 重构，让定义之争真正收场。它不复述 lead scoring，也不从零定义，价值在层与层之间的边界与贯穿全链路的算术。

二、第一层：business lead，公司级记录

business 是一家公司的记录——一家「可能进入寻址宇宙」的公司，带有行业、规模、地域、技术栈等属性，但没有任何已验证的个人意图。它回答的是「谁有可能买、任何时候都可能」。business 来自目录、列表、intent-feed 账号匹配与 account-based 研究，是获取成本最低的一层，也是被滥用最多的一层——按体量卖出、被计入管道、被换算为业绩，而公司内部从来没有人表达过任何想法。business 是一条地址、不是一个人；把它当成需求，正是 18% 注水问题的原罪。

三、第二层：marketing lead，或 MQL

marketing lead 是一个被捕获行为的个人——内容下载、webinar 注册、定价页访问——具备足以通过营销资格门槛的信号。它回答的是「在一家可能的公司里，谁在表现出兴趣」。MQL 是关于某个人的行为观察，而不是关于某家公司购买意图的陈述；同一个人可能是学生、竞争对手，或替已经选定的供应商做尽调的采购研究员。MQL 是被 2026 年 AI 生成表单噪音污染最严重的一层，这也是为什么在它们的上游就需要核验溢价。

四、第三层：sales lead，或 SQL

sales lead 是一个具名联系人，具备已验证的 fit 与明确表达的意图——有人用言语或明确动作说清，自己要解决什么问题、解决的时间窗口是哪一格。它回答的是「本季度谁值得一位销售花时间」。SQL 由资格对话、自举动作或 SDR 针对触发账号的研究产生。这一层按定义就是贵的，也是唯一能预测的一层——SQL 之下的管道数学是算术，SQL 之上的管道数学是占星。

五、2026 年的层间转化率与时效复利

按平均数锚定计划是稳定的。MQL→SQL 平均 31%，健康带宽 24-39%；SQL→商机 52%；商机→成单 21%（Salesforce State of Sales 2026）。比绝对水平更值得记住的是两个性质：第一，时效性，MQL→SQL 的中位时间是 11 天，而未经处理超过 30 天的 MQL 会损失 62% 的最终转化——层在等待中腐烂，因此路由速度是收入变量而不是服务指标。第二，复利，按平均数算，1000 个 MQL 变成 310 个 SQL、161 个商机、34 个成交——MQL→SQL 边界上 5 个百分点的改善，能换 17% 的成交增量；同样精力花在「更努力地数 lead」上，得不到任何东西。

六、不同速度的腐烂

层在不同速度上死去，过程是安静的。联系人数据按 22.5-28% 的年率衰减——人换岗、邮箱失活、电话回收——即使完全没有新增入库，一支未处理的 SQL 池每年也会烂掉大约五分之一。最惨的恰恰是仪表盘最爱看的：老 MQL 在培育炼狱里无限期「活跃」；而在没有任何层级标签的 CRM 记录里，所谓活跃 lead 中有 34% 其实已死——离职的联系人、孤立的账号、或重复记录（Forrester B2B Lead Management 2026）。管道报表一旦混层，三种错误模式同时继承：把 business 当成需求造成的注水、未标日期的 marketing 造成的陈旧、未核验意图造成的幽灵 SQL。层级标签不是官僚，它是让报表变成算术而不是叙事的审计线索。

七、account-based 重构，让定义之争真正收场

account-based 重构是定义之争真正如何收场的方式，2026 年让它成了多数派：63% 的 B2B 组织至少部分运行了 account-based 度量，这样做的组织销售-市场定义之争下降 41%（Gartner Demand Generation 2026）。机制很简单——当分母是「正在推进阶段的 account」时，三层 lead 就变成仪表而不是身份。business 是加入覆盖的 account；marketing 是覆盖 account 上的互动信号；sales 是互动 account 上的对话开局。三层不再为「lead」这个词互相争抢，而是描述同一件事——一家公司朝决策走近或走远——的可观测状态。

八、四字段数据模型 + 一份季度节奏

实务上的数据模型是四个字段加一份节奏，而不是一次平台迁移。强制字段：层级标签（business / marketing / sales）、来源、核验状态（已核验 / 未核验 / 失败）、account 关联——每条 lead 记录挂到一条公司记录上，account 作为报表 rollup。节奏：季度腐烂扫描——两个季度以上的未核验记录归档、失败的核验退役、覆盖范围重新计算。完全按这套跑——不加新工具——的团队通常在第一周就能找出那 18% 的幽灵管道，会看着真实的 MQL→SQL 上升（分母终于排除了鬼魂），也会停止定义之争，因为 account rollup 不再奖励任何一方去给自己的层注水。

九、5000 条记录的算账

把例子具体化。取一家中端市场工业软件公司的 5000 条 CRM 记录，贴上标签后真相浮出：2900 个 business（账号研究，无个人）、1800 个 marketing（行为捕获，中位年龄 14 个月，腐烂调整后约剩 1350 条活的）、300 个 sales，其中 102 个具备当前联系人的验证。1350 条活 MQL 算出的诚实漏斗：419 个 SQL（按 31%）、218 个商机、46 个成交——对比仪表盘最初宣称的「5000 个 lead、600 个 SQL、312 个商机」。同一份数据、同一套率，差异完全来自分层与腐烂。这个差——大约报告管道的三分之一——就是董事会被告知的与真实之间的裂缝。

十、收尾：把层做对、把算术做对

三层不会坍缩成同一个词——这些词太根深蒂固。守纪律的团队做的是把层讲清楚、把率诚实、把腐烂按季度清理、并 rollup 到 account。18% 的误差不是谜，是同一个词干三份工的必然代价。把标签改对，把算术改对，管道报表终于描述了一种能卖出去的东西。