sales-forecast-diagnostic

预测诊断

调查一次未达预期，或无人信任的预测，并用证据指出根本原因。预测会议会问“数字是多少？”这项诊断会问“这个数字曾经真实吗？”

从业者普遍认为，大多数预测偏差源于检查失误，而非市场失误：在预测未达预期之前，记录中通常已经存在证据，表明某笔已承诺的交易并不属实。

先说明范围边界：此技能使用现有的预测方法——类别集、汇总规则、承诺标准和覆盖率目标均为输入，而非交付成果。设计或重新设计预测方法不在范围内。如果调查发现预测方法本身未定义或含糊不清（“不同销售代表对承诺的理解各不相同”），应将其报告为发现，并止步于此边界。

每个已确认的根本原因都恰好归入以下三类之一，因为每一类的负责人和修复方法都不同：

• 数据：记录有误，但有人知道实际情况。
• 行为：记录忠实反映了存在偏差的人为判断。
• 需求：真实且有证据支持的销售管道仍未达标。

最常见的诊断错误，是把数据问题判定为行为问题。

访谈

分析前先提问：

• 每条消息只问一个问题；尽可能提供多选项。
• 跳过已回答的问题。
• 在问其他问题前，先问完以下前三个问题。它们的修复方案在工作量和影响预测结果所需时间上相差两个数量级，答案将决定整个交付内容的排序。

问题：

• 必须在什么时候之前让数字更可靠——本期预测、下一次预测，还是下一个规划周期？在本期结束后才落实的修复方案对本次预测毫无帮助：如果截止日期在期中，所有耗时超过一个周期的修复方案都会从计划中剔除，剩下的全部重担都落在耗时数小时的 CRM 管理员修复方案上。
• 是只修正这次偏差，还是建立长期准确性计划？一次性修正会优先采用重建、清理僵尸记录和整理日期；长期计划则会优先采用证据门槛、校准记分卡和阈值推导。
• 工作量上限是多少：分析师可投入多少小时，CRM 管理员本周能否上线字段或验证规则变更，以及谁有权重新开放薪酬计划或更改评审节奏？没有管理员，所有数小时级的修复方案都会变成需要一周的请求；没有薪酬方案变更权限，就彻底无法实施薪酬方案修复。
• 这次调查由什么触发——某个特定周期未达预期、长期准确性不佳，还是某种怀疑（隐藏业绩、虚增销售管道）？涉及哪些周期？
• 偏差方向是什么——预测过高（未达预测）、预测过低（大幅超出预测），还是两个方向都不稳定？
• 数字在哪个层级出了问题——单个销售代表、经理汇总，还是公司整体？汇总过程中，哪些环节允许人工覆盖合计值？
• 当前流程是什么样的——使用哪些预测类别、提交频率如何、由谁确定最终数字？（按现状记录；不重新设计。）
• 有哪些历史数据——商机快照、字段历史（阶段、结束日期、类别、金额变更）、活动日志？能追溯多久？
• 业务模式是什么——B2B 交易型、B2C／高交易量／自助式模式，还是混合模式？每个周期大约有多少笔交易？
• 团队的薪酬方式是什么——配额门槛、加速提成、季末折扣权限，或任何与预测数字本身挂钩的奖励或惩罚？
• 本周期是否有干扰因素——CRM 迁移、阶段重新定义、区域变更、批量数据清理？

工作流

1. 运行访谈；在接触交易数据之前，先确认误差发生的期间、方向和程度。
2. 先量化偏差，再解释原因：按期间、汇总层级和预测类别分别比较预测值与实际值。计算有符号误差（偏差）和绝对误差——对称平均会掩盖相互抵消的误差，而且同一偏差会因所选分母不同而呈现出截然不同的含义，因此要先确定一种误差定义。两项指标必须始终同时报告，这是正确性规则，不是供人排序和选择的菜单——参见 references/evidence-and-metrics.md。
3. 清点证据基础：期间开始时的快照、字段历史记录、活动日志。如果没有快照或字段历史记录，现在就开始记录；根据当前状态的特征和访谈进行诊断，并将每项结论标记为低置信度——没有历史记录，行为判断就很难站得住脚。
4. 根据期间开始时的快照，重建未达标期间的情况。按结果分类每笔曾列入某个预测类别的交易（按预测成功、延期、失败、移除、仍在进行），并按来源分类每笔实际赢单（是否在预测中？属于哪个类别？何时创建？）。如果你的运行环境可以执行代码，就用两个文件的导出数据（期间开始时的预测、期间结束时的实际结果）编写脚本完成此操作；否则请用户提供两份清单，再手动核对。
5. 对重建结果应用 references/root-cause-fingerprints.md 中的根因特征。每个疑似原因必须有两个独立信号，其中至少一个来自记录的历史。
6. 就标记出的交易访谈销售代表和经理，以区分数据问题与行为问题。关键问题是：“在 CRM 显示之前，你是否知道这笔交易已经没有希望（或确实有望成交）？”回答“是”意味着记录滞后于现实——这是数据问题。回答“否”则意味着这是行为或需求问题。
7. 最后单独识别需求：用经过事后修正的数据重建期间开始时的预测——移除无效交易，设置真实的类别，并采用有证据支持的成交日期。修正后仍存在的缺口，就是真实的需求或覆盖不足问题，任何预测流程修复都无法弥补；应明确说明。
8. 归因缺口：每一笔偏差金额都要对应一笔明确命名的交易（或高交易量模式中的明确命名模型假设），每项都要有一个主要根因和一个类别。相互抵消的误差（例如虚报的失败掩盖了未纳入预测的赢单）要分别归因，绝不能悄悄抵消。
9. 检查下文“衡量”部分的通过阈值；调整特征并重新运行，直到满足所有阈值。
10. 使用下文“修复杠杆”中的方法，按优先级排列已确认原因以供交付：先按归因金额排序，再除以修复工作量，并明确显示调整过程，不要悄悄合并两种排序。每个原因匹配其类别，只提出一个修复方案，并为每项修复指定能在一个期间内证明其奏效的指标。
11. 按章节逐一交付并征求用户批准；报告结构和示例见 references/worked-diagnosis-example.md。
12. 如果你的运行环境有持久记忆，请记住已确认的原因、根据团队历史得出的阈值、该团队实际所需的工作量级别，以及销售代表级别的校准基线——下一期间重新运行时从这些信息开始。

范围内的根因

简要概览：完整的检测特征、第二信号和修复方案按此处相同顺序列于 references/root-cause-fingerprints.md。

这里无法预先对价值轴进行排序，本技能也不会假装可以做到：哪种原因造成的金额损失最大，应由归因表得出，而且每次合作的结果都不同。稳定不变的是修复方案——交付成本和预测反映变化所需的时间。因此，登记表按此排序，诊断随后再根据实际发现的金额重新排序（参见“修复杠杆”）。

• 修复投入（从高到低）：激励方案驱动的偏差 > 阶段虚报 == 缺少证据 > 后期创建的交易 > 销售代表保守报数 > 经理覆盖 == 类别错误 > 日期过时 == 僵尸交易
• 生效时间（从慢到快）：激励方案驱动的偏差 > 销售代表保守报数 > 经理覆盖 > 后期创建的交易 > 阶段虚报 == 缺少证据 > 日期过时 == 类别错误 > 僵尸交易
• 合规成本（从高到低）：只有两项会产生合规成本——修改激励方案 > 对某位销售代表作出行为判定；其他所有修复都是 CRM 设置或审核习惯，无需外部审批，因此不值得对这一维度进行完整排序。
• 相同投入下的效率（从高到低）：僵尸交易 > 日期过时 == 类别错误 > 阶段虚报 == 缺少证据 > 后期创建的交易 > 经理覆盖 > 销售代表保守报数 > 激励方案驱动的偏差

并非刻意回避的并列项：

• 阶段虚报 == 缺少证据：两者的修复实际上是同一项干预措施，即在提交时设置买方证据门槛；负责人相同、实施周期相同、例行检查也相同。
• 经理覆盖 == 类别错误：两者都需要花一小时配置 CRM（添加原因字段、类别字段历史记录），并且只需与那些因改动而受到判断约束的人员进行一次协商。
• 日期过时 == 僵尸交易：两者都只需更改一项管理设置并定期清理，不限制任何人的判断，且发布当天即可撤销。
• 日期过时 == 类别错误，仅针对生效时间：两者都会在下次编辑时生效，因此无论选哪一个，都需要完整一个周期。 | 根本原因 | 常见类别 | 特征 | 修复所需投入 | | -------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 僵尸 / 重复商机 | 数据 | 早已失效的交易仍处于开启状态并被计入；同一购买意向被重复计算 | 花 1 小时按原因代码清理，然后持续进行卫生检查；同一周期内即可获得真实的覆盖率 | | 过时 / 批量推迟的成交日期 | 数据 | 推迟次数不断累积；日期修改集中在期末的某一天 | 花 1 小时设置必须填写原因的日期变更管理流程，然后设置持续运行的任务；到下一次推迟时才会产生效果，因此需要一个周期 | | 类别分配错误 | 数据或行为 | 类别与阶段和证据相矛盾；使用省略 / 排除类别作为软删除；类别在创建时设定后便从未更新 | 花 1 小时设置有日志记录的类别变更；如果团队必须重新达成类别定义共识，则需要一周 | | 阶段虚高 / 盲目乐观 | 行为 | 处于后期阶段的交易没有买方证据；字段历史中存在跳过阶段的情况；实际赢单数远低于该阶段所暗示的水平 | 花一周定义买方证据门槛并修改评审问题，然后持续检查；一个周期后预测结果会更真实，赢单率则需要两个周期 | | 缺少 / 无法核实的证据 | 数据或行为 | 必填字段中填入占位内容；没人能说清买方最近采取了什么行动 | 与阶段虚高问题采用相同的周期、门槛和负责人——解决其中一个也就解决了另一个 | | 延迟创建的交易 | 数据 | 交易在几天内创建并成交，或直接在后期阶段创建——事后才进行流水账式记录，无法提前看清销售管道 | 花一周制定记录规则，然后改变销售代表的习惯；接下来一两个周期的覆盖率计算都不可信 | | 经理汇总调整 | 行为 | 经理的数字与销售代表的总和存在持续的方向性偏差，且没有记录原因 | 花 1 小时记录原因，但在经理个人评分有意义之前，需要累积一个季度的调整记录，而且经理必须接受被评分 | | 销售代表故意压低预测 | 行为 | 销售代表反复大幅超出承诺；赢单来自预测范围之外 | 花一天建立开放式校准记分卡，至少需要 2 个周期的历史数据才能识别模式；任何涉及激励的事项都应归入下方一行 | | 薪酬驱动的偏差 | 行为（其他问题的根源） | 延期集中在刚过配额门槛之后；可预见的季末折扣让买家学会等待 | 至少需要一个季度——计划修订要到下一个计划周期才会生效，需要财务 / HR / 法务签字，而且一经发布几乎无法撤回 | 效率排序会让佣金驱动的偏差得不到重视，而它才是推动其他问题的根因：在大多数诊断中，它在影响轴上位居首位，却在每次诊断的比率排序中垫底。只看比率的登记表每期都会建议做同样的 CRM 数据规范清理，却不触及产生这种行为的激励机制，行为问题也会卷土重来。

在以下情况下，应将佣金驱动的偏差置于所有问题之上：

• 特征显示，失误集中出现在配额门槛附近。
• 同一位销售代表的偏差会随其达成率位置而变化。
• 上一周期的数据修复已交付，但该类行为并未改善。

此时，低成本修复已无剩余价值，交付内容应明确说明这一点，而不是再次列出这些修复措施。

与相邻技能的界限：此技能会检测缺乏证据却停留在某个阶段的交易，但不会重新设计阶段集合（如果问题出在阶段定义本身，请参阅 mbfinotti/revops-skills@pipeline-stage-definition-audit）。这是针对某次具体失单的根因调查，并非定期清理过期交易或缺失字段（原因修复后，如需预防，请参阅 mbfinotti/revops-skills@sales-pipeline-hygiene）。

修复杠杆

上面的登记表用于打破平局，而不是提供答案。归因表建立后，应分三轮对已确认的原因进行交付排序，并在交付内容中列出这三种排序：

1. 影响排序 - 按归因差额金额对原因排序，直接取自归因表。这是失误的算术结果，绝不能调整；它使每个问题的规模都可审计。
2. 杠杆排序 - 将同一批原因按登记表中的修复工作量等级进行折算。绝不能除以货币金额：分母应为分析师工时、管理或工程工作量、跨团队协商，以及修复影响预测电话会议前所需的预测周期数。
3. 展示调整过程 - 列出所有在两种排序之间变动的原因，并用一行说明导致其变动的工作量。只呈现杠杆排序，会让人觉得影响金额的计算结果被悄然推翻，而高管首先提出的问题总是：为什么金额最大的原因没有排在第一位？

按杠杆排序交付，并在旁边列出影响排序。以最佳比率开篇，这通常并非成本最低的修复——归因金额较大的原因，如果修复所需工时等级相同，就优先于金额较小的原因，也优先于所有需要按周计算工作量的原因。调整示例见 references/worked-diagnosis-example.md。

交付前重新排序

这里的所有排序都是默认顺序，不是铁律。排序会随团队和执行者而变化，因此要根据访谈和重建分析揭示的情况重新排序：

• 截止日期在当前周期内——从本周期计划中删掉所有按周和按季度计的修复项，以及所有需要积累多个周期的历史数据才有意义的修复项；并明确说明删掉了哪些，而不是把它们列在末尾，以免它们又作为范围要求被加回来。剩下的修复顺序是 僵尸商机 > 过时日期 > 错误类别，并明确指出导致这些行为的原因尚未处理。
• 有一位手头有空且有权在本周发布验证规则的 CRM 管理员——按小时计的修复项仍需一个小时，并排在首位。否则，它们就会变成别人队列里按周计的请求，失去相对于证据门槛的时间优势；至少证据门槛能在同一周内落地。
• 销售负责人不愿重新审视薪酬方案——从计划中删掉薪酬修复项，并指出它会导致哪些具体行为原因再次出现。不要把它放在底部，作为降级后的选项。
• 没有快照或字段历史记录——本轮根本无法举证经理覆盖和压单原因。将它们从修复计划中删掉，现在就开始采集历史记录，并安排重新执行。
• 季中，预测周期已开始——现在发布的修复会影响下一次预测会议，而非本次。说明每项修复针对两个周期中的哪一个，并停止提出那些两个周期都影响不到的修复项。
• 默认排序未考虑、但团队已经在用的任何措施——有效的证据门槛、已评分的覆盖日志、数据卫生自动化——都应从登记清单中移除对应原因，而不是再次推荐。

数据 vs. 行为 vs. 需求

• 数据：有人知道实情，但记录没有反映出来。通过数据卫生自动化和字段所有权规则修复（mbfinotti/revops-skills@crm-data-governance），而不是对销售代表进行辅导。
• 行为：记录如实反映了有偏差的判断——乐观、自我保护，或对激励措施的理性反应。通过类别录入的证据标准、激励措施调整和审核纪律来修复。仪表板无法修复行为。
• 需求：真实且有证据支持的销售管道仍未达标——覆盖量确实不足，或赢单率确实发生了变化。修复应着眼于销售管道生成和市场策略，而不是预测流程。覆盖量的经验法则（目标 ≈ 赢单率的倒数，因此常见说法是“3 倍”）是一种广泛流传、但没有可追溯原始研究支持的启发式方法——应根据团队自身的转化历史推导真实目标。

结论纪律：判定为行为问题就是在指控他人。只有满足双信号证据规则并完成销售代表访谈后，才能做出这种判断；还要将准确性讨论与绩效／薪酬讨论分开——如果诊断结果被用于惩罚，就会教会销售代表压低预测，而下一次未达标就会是诊断本身造成的。

B2B vs. B2C / 高交易量 / 自助服务

• B2B 按交易推进：上述工作流按字面适用——逐笔重建，建立交易级特征。

• B2C / 高交易量 / 自助服务：预测通常是一个模型（运行率、群组转化、漏斗计算），再叠加人工调整。对现有的任何人工层应用交易级特征（例如内部销售团队的承诺清单、人工调整）。其余部分则转换到模型层：

  • 转化假设陈旧，对应的是关闭日期过时。
  • 漏斗定义过于宽泛，对应的是阶段膨胀。
  • 长期过于保守的人工调整，对应的是压单。

  对人工调整与模型的准确性进行跟踪，方式与对比经理覆盖与汇总预测的准确性完全相同。

• 两种销售模式都相同：预测偏差分解方法、三类结论体系、衡量阈值和统计纪律均不变。

失败模式

陷阱	错误原因	修正方法
凭一个表现强劲的季度判断故意藏实力	一次超预期只是噪声；故意藏实力是同一人反复出现的模式	要求该模式在 2 个或更多周期内均出现，并与该销售代表自己的历史表现对比
将数据问题判定为行为问题	类别定义含糊，会让诚实的销售代表看起来像在撒谎	先提出能区分情况的访谈问题；检查不同销售代表对定义的理解是否一致
用周期结束时的数据评判周期开始时的预测	后见之明偏差——必须根据当时可知的信息评判预测	根据周期开始时的快照重建情况，绝不要使用今天的记录
锚定在金额最大的延期交易上	一笔显眼的交易很少能解释差距；通常是大量小额交易造成的	得出结论前，先拆解差距涉及的所有金额
将对称准确率指标作为目标	预测过高与预测过低的原因和代价不同，两者还会相互抵消	始终按级别分别报告带符号偏差和绝对误差。这不是供人挑选排名的指标菜单——要让另一项指标具有可读性，就必须同时提供这两个数字
仅按归因金额排列修正措施	薪酬计划重设计的排名会高于本周期内本可落地的现场调整，而这类重设计也无法及时推出	将金额除以修正措施的投入等级，并展示调整结果（修正杠杆），然后结合访谈答案重新排序
删除僵尸项目后就宣告胜利	接纳这些项目的证据标准依然未变；它们会卷土重来	每次清理都要同时修正准入标准，并将持续预防交由卫生审计负责
在薪酬中惩罚预测误差	销售代表会以故意藏实力应对；误差只会反向，而不会缩小	公开衡量准确率，并将其与绩效评估分开
轻信广为流传的基准统计数据	被引用最多的预测准确率数据，大多没有可追溯的原始研究	所有阈值均从团队自身历史数据推导；请参阅证据参考

衡量指标与通过阈值

诊断必须在发布前满足以下所有阈值；持续迭代，直到达标：

• 归因覆盖率：至少 90% 的差距金额归因到具名交易（或具名模型假设），且每项都只有一个主要根本原因和一个类别；剩余部分不得超过 10%，并须明确标记为“无法解释”——绝不能悄然并入其他项。
• 证据规则：每个已确认的原因都必须有至少两项相互独立的信号作为依据，其中至少一项来自已记录的历史记录（快照、字段历史记录、活动日志）。仅凭访谈陈述永远不能确认原因。
• 回测：将相同的特征规则应用于更早的已结算周期，找出该周期内实际从承诺阶段滑落或流失的交易，命中率至少达到 80%。低于 80%，说明这些规则迎合了叙事，而非数据——请修订并重新运行。
• 可执行性：每项发布的修正方案都必须注明其原因类别、负责人、工作量级别，以及一个能在一个周期内显示成效的单一指标。修正方案列表须按杠杆效应排序，并在旁边列出影响力排序，同时解释两种排序之间的每一处差异；只采用其中一种排序的列表不符合此阈值。

修正方案发布后，继续按周期评分：各层级的有符号偏差和绝对误差，以及销售代表相对于自身基线的校准情况。只有指定指标有所改善，才能结束调查——而不是预测会议变得更平静。

可选集成说明

除非用户指定以下某个平台，否则请跳过本节。

Salesforce：

• 预测类别（承诺 / 最佳情况 / 管道 / 排除）与阶段不同，且可独立编辑；请分别诊断这两个字段。
• 字段历史跟踪需要按字段选择启用，且不会追溯记录。请立即为阶段、结算日期、金额和预测类别启用此功能，即使本周期必须在缺少这些数据的情况下进行诊断。
• Pipeline Inspection 功能可在支持的版本中呈现交易的周环比变化。

HubSpot：

• 交易阶段概率是可编辑的默认值，并非实测转化率。在信任任何加权数值之前，请用团队自身的历史数据替换它们。
• 系统会记录手动提交的预测，并可将其与计算得出的汇总值进行比较。

参考资料

• 请参阅 references/root-cause-fingerprints.md，了解各原因的检测信号、区分指标和修正方案，以及如何根据团队自身的历史数据推导阈值。
• 请参阅 references/worked-diagnosis-example.md，了解报告结构、完整诊断示例和反例（错误的诊断及其失败原因）。
• 请参阅 references/evidence-and-metrics.md，了解误差指标的选择、销售代表校准评分卡，以及哪些流传的统计数据可以安全复述。
• 如果特征指向阶段定义本身，请参阅 mbfinotti/revops-skills@pipeline-stage-definition-audit，判断阶段定义是否可由买方验证。
• 请参阅 mbfinotti/revops-skills@sales-pipeline-hygiene，了解防止数据类别原因再次出现的定期审计。
• 请参阅 mbfinotti/revops-skills@crm-data-governance，了解数据类别修正方案背后的字段所有权和事实来源规则。
• 请参阅 mbfinotti/revops-skills@revenue-reporting，了解如何将已完成的诊断转化为面向管理层或董事会的叙述。