不要因为Demo里每个联系人旁边都出现一个“很聪明的分数”，就购买线索评分系统。真正值得买的供应商，必须能回答：这个分数到底推动什么业务决定、哪些数据参与计算、客户匹配度和行为热度怎么区分、缺失数据怎么办、分数怎样进入CRM和路由、销售如何质疑错误分数，以及市场变化以后模型怎么复核。 一个看起来非常精确、却无法治理的评分，往往不如团队能理解和维护的简单模型。

下面这份清单可以直接用于Demo、RFP、试点或续费评审。

先看这张采购清单

必问问题 为什么重要 危险信号
这个分数会触发什么决定？ 分数必须对应动作 只说“越高越好”
哪些数据进入模型？ 输入决定覆盖与偏差 说不清自有/外部数据
能否拆开fit和engagement？ 好公司不等于现在想买 只有一个黑箱总分
缺失值怎么处理？ CRM不完整是常态 缺失直接等于负分
能解释分数变化吗？ 销售需要信任和纠错 没历史、没原因码
怎么回写CRM？ 错误同步会破坏流程 覆盖规则含糊
阈值能否按业务拆？ 不同产品/渠道不同 一个MQL线打天下
模型怎么重新校准？ ICP和行为会漂移 只说“AI自动学习”
系统不可用怎么办？ 路由不能跟着供应商停 服务一断线索停摆
价格随什么增长？ 小试点和全量成本不同 正式规模费用说不清

1. “这个分数到底要改变哪一个业务决定？”

第一问就应该问这个，因为它能最快暴露“为了AI而AI”的项目。

合理答案可能是：

  • 高匹配、高活跃的Inbound线索必须在某个SLA内进入SDR；
  • 给销售生成每天优先处理的账户队列；
  • 把明显不在市场内的联系人排除出高成本人工触达；
  • 选择不同培育路径；
  • 把信息不完整的记录送进人工复核。

如果买方自己都说不出决定，供应商就不可能证明评分创造了价值。

最常见的误区，是把评分理解成“所有人0到100，按分数从高到低打电话”。真实业务里，不同销售动作可能需要不同模型。

HubSpot当前评分工具就把fit和engagement分开，也支持把两个维度组合成等级。这个设计至少提醒采购团队一件事：“这家公司适不适合我们”和“它现在有没有购买信号”不是同一个问题。

2. “哪些数据是我们自己的，哪些是供应商提供的，哪些只是推断？”

让供应商拿一个真实样例，把分数的数据来源逐项画出来。

可能包括：

  • CRM里的公司属性；
  • 表单；
  • 网站行为；
  • 邮件互动；
  • 产品使用；
  • 商机历史；
  • 外部公司数据库；
  • 第三方Intent；
  • 职位变动；
  • 推断属性。

不同来源有不同的新鲜度、覆盖率、权限和错误方式。

“我们用了几千个信号”不是好答案。信号越多，不代表业务决定越准确。

最实用的采购动作，是让对方交一张字段级表格：来源、刷新频率、缺失处理方式、这个值是观察到的还是推断出来的。

3. “数据缺失、互相矛盾或过期时怎么办？”

Demo数据往往太干净。

真实CRM里会有重复账户、旧职位、不完整表单、集团共享域名、收购遗留数据、错误生命周期阶段、销售手工改过的字段。

供应商必须说清楚，缺失值到底会：

  • 算0；
  • 使用默认值；
  • 降低置信度；
  • 不参与评分；
  • 触发补全；
  • 进入异常队列。

还要问：外部数据和CRM人工确认值冲突时，谁优先？

成熟答案会区分**“不知道”和“负面”**。没有员工人数，不等于公司一定太小；没有网站事件，也不等于一定没有意向。

4. “fit、行为、intent和时间能不能拆开看？”

为了路由方便，可以有总分，但运营必须能看见组成。

想象四条记录：

  • ICP非常匹配，但最近没活动；
  • 匹配度很差，却大量下载内容；
  • ICP很好，最近频繁访问价格页；
  • 公司信息不全，但外部出现强烈研究信号。

这四种不应该被同一种方式处理。

HubSpot目前允许fit和engagement分别维护，也能组合出等级；G2的Lead Scoring Buyer Guide同样区分rules-based和predictive，并把公司属性与行为数据视为重要信号来源。

所以采购时真正该问的不是“你们有没有AI”，而是：

我能不能知道，到底是哪一类证据在驱动动作？

5. “分数为什么变化，用户能看懂吗？”

销售最容易放弃评分系统的时刻，就是数字突然变化，却没人能解释。

Demo时直接要求看：

  • 分数历史；
  • 主要加分/减分因素；
  • 重要行为的时间；
  • 阈值变化历史；
  • 模型版本；
  • 人工覆盖；
  • 销售能否反馈明显错误。

如果使用预测模型或AI，再追问：哪些解释能落到单条记录，哪些只能在模型层面看。

HubSpot在2026年8月更新的AI评分流程，可以根据历史生命周期变化来评估联系人并建议fit或engagement条件。但即使系统能自动建议，运营仍然必须知道：这些建议能否先审核、修改，再真正接入自动路由。

6. “到底会向CRM写回什么？”

这其实是系统架构问题，不是营销功能问题。

让供应商逐项列出会新增或修改的字段：

  • 总分；
  • 维度分；
  • 等级；
  • 置信度；
  • 最后评分时间；
  • 原因码；
  • 模型版本；
  • 原始Intent；
  • 路由状态。

再问清楚是单向还是双向，冲突怎么处理。

一个每几分钟刷新的分数，可能反复触发工作流；一个随意覆盖人工字段的集成，可能制造比评分本身更大的问题。

试点阶段最好先写到沙盒或独立控制字段，不要第一天就接生产路由。

7. “阈值能不能按产品、客群、来源和销售模式拆？”

一个统一阈值非常好管理，也可能非常错。

Enterprise Inbound、SMB自助、展会线索、渠道推荐、Outbound，各自的转化基准、跟进成本和购买周期都不同。

至少追问系统是否支持：

  • 多个模型；
  • 分客群阈值；
  • fit和engagement分别设线；
  • 按来源路由；
  • 时间衰减；
  • 排除条件；
  • 最低数据要求。

如果不支持，也不是一定不能买，但必须提前知道业务会牺牲什么。

8. “我们怎么知道模型开始变旧了？”

这句话很能区分“卖软件”和“做运营系统”的供应商。

市场会变，产品包装会变，公司会进入新国家、新行业、新价格带，获客渠道会变，ICP也可能扩大或收缩。

G2的采购指南明确提醒，评分逻辑需要持续修订和优化。这个维护成本不是附加项，而应该进入采购标准。

问供应商：

  • 系统监控什么；
  • 多久复核一次；
  • 能不能对比旧模型和新模型；
  • 阈值修改有没有审计记录；
  • 重新校准需要多大样本；
  • 能不能暂停或回滚模型。

“AI会持续学习”不能代替这些答案。

9. “试点到底怎样算通过？”

不要把“接口成功连上”当成成功。

试点开始前，就把验收写好。例如：

  • 覆盖率：多少符合条件的记录能得到可用分数；
  • 分层差异：高分组后续结果是否确实更好；
  • 路由质量：销售是否更愿意接受模型优先的线索；
  • 稳定性：小的数据变化会不会导致分数剧烈跳动；
  • 延迟：评分是否来得及支持实际工作流；
  • 可解释性：运营能否定位异常分数；
  • 异常工作量：需要人工清洗的冲突有多少。

不要要求供应商承诺一个“所有客户都能提升X%”的数字。你的基础转化率、流量、销售流程和样本量都会改变结果。

10. “如果以后不用你们，我们能带走什么？”

退出问题必须在购买前问。

至少确认能不能导出：

  • 分数；
  • 模型配置；
  • 原因码；
  • 历史评分；
  • 许可允许范围内的原始供应商信号；
  • 字段映射。

还要确认取消以后API、CRM属性、工作流和存储数据怎么处理。

好的评分系统应该让团队的运营方法越来越成熟，而不是让公司离开某个供应商以后连“谁先跟进”都不会判断。

11. “试点便宜，正式规模到底怎么收费？”

不要只比较起步套餐。

追问费用是否随着这些项目增加：

  • 账号席位；
  • 被评分记录数；
  • 被补全记录数；
  • Intent事件；
  • API调用；
  • 数据刷新频率；
  • 历史数据；
  • 多工作区/多业务单元；
  • 高级集成；
  • 预测或AI能力。

用今天的量算一次，再用12–18个月的合理增长量算一次。最便宜的试点工具，如果每一层有价值的数据都单独计费，正式投入以后可能反而最贵。

下一步验收清单

选线索评分供应商之前，确认下面全部能打勾：

  • 我们能说清评分会触发什么业务决定。
  • 我们知道哪些输入是自有、第三方、推断数据。
  • 缺失值和冲突值有明确规则。
  • 需要时可以分开查看fit和engagement。
  • 分数变化能解释、能审计。
  • CRM写回字段和工作流副作用已经列清楚。
  • 阈值可以适配不同客群与销售动作。
  • 模型复核和重新校准有负责人。
  • 试点前已经写好验收标准。
  • 已经按照生产规模测算费用。
  • 退出和数据导出规则已确认。

最好的供应商，不是在Demo里给出“最聪明数字”的那个。

而是能进入你的收入流程、承认不确定性、处理脏数据、允许人纠错，并最终帮助团队做出更好的优先级决定的那个。

资料来源

相关阅读