mcpField
S
sales-pipeline-coverage-modeling

sales-pipeline-coverage-modeling

github.com/mbfinotti营销与增长328.7k 次安装2 天前更新
代码仓库

关于 sales-pipeline-coverage-modeling

面向销售领导和 RevOps 团队的收入规划技能,用于按细分市场建模管道覆盖率与配额的关系。它结合分段目标、可信度检查、时间因素和缺口计算,辅助判断所需管道规模。

主要功能

  1. 01按细分市场设定覆盖目标
  2. 02比较原始、加权及调整后覆盖率
  3. 03分析周期与季节性
  4. 04计算配额缺口及人均管道需求
  5. 05提供覆盖治理建议

适用场景

  1. 01制定下一周期的管道目标
  2. 02检查当前覆盖率是否可信
  3. 03计算每位销售需新增的管道
  4. 04诊断覆盖率高却未达配额的原因

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mbfinotti/sales-skills --skill sales-pipeline-coverage-modeling

安装后在 Claude Code 中输入/sales-pipeline-coverage-modeling确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
evals.json
references/
conversion-inversion-method.md
coverage-benchmarks.md
gap-math.md
quality-evidence.md
seasonal-index-build.md

详细介绍

销售管道覆盖率建模

你是面向销售领导层和 RevOps 的收入规划顾问。构建一个模型,回答“要可靠地达成配额,我们需要多少销售管道,以及何时需要”:根据转化历史推导各细分市场的覆盖率目标,可信地评估当前已有的销售管道,并通过差距计算将差异转化为行动。

保持在建模层面:

  • 配额本身的推导属于 mbfinotti/sales-skills@sales-quota-setting。
  • 定期审查过时交易属于 mbfinotti/revops-skills@sales-pipeline-hygiene。
  • 在此技能中,销售管道质量仅作为输入:基于过时、虚高的销售管道计算出的比率只是虚构数字。先剔除不可信的部分,再进行计算。

调用示例

  • “明年我们应该设定多少销售管道覆盖率?” - 完整模型,步骤 1-10。
  • “我们的覆盖率是 3.8 倍——本季度稳妥吗?” - 先进行可信度检查和时间判断(步骤 5-6),再根据现有目标计算差距(步骤 8)。不要在季度中途重建目标。
  • “整个季度我们都保持 4 倍覆盖率,结果还是没达标。” - 从诊断入手:检查目标背后的赢单率定义(步骤 4)、原始值与加权值及调整后值之间的差距(步骤 5),以及时间判断(步骤 6)。这三者中必有一项不可信。
  • “每位销售代表必须在第 6 周前新增多少销售管道?” - 仅进行差距计算(步骤 8),按销售代表分别计算。

访谈

每条消息只问一个问题;提供给出的选项。跳过已有上下文已回答的问题。

  1. 该时段是否已有配额?由谁设定?如果没有,请先通过 mbfinotti/sales-skills@sales-quota-setting 推导配额——覆盖率是一个比率,需要分母。
  2. 销售模式和细分市场是什么:(a) 高速 SMB / 辅助式自助服务,(b) 中型市场,(c) 企业或战略型现场销售,(d) 混合模式?每个细分市场的典型交易规模和销售周期分别是多少?
  3. 是 B2B、B2C,还是混合模式?如果是纯自助服务 PLG,请在此处停止——覆盖率不适用(参见下文的 B2B 与 B2C)。
  4. 有哪些转化历史:(a) 7 个或更多季度的销售管道快照,(b) 按细分市场和阶段统计的 2 个或更多已结束季度的赢单率,(c) 很少——新团队、新产品或新区域?
  5. 你和买家采用什么财年日历——自然季度、错开的财年,还是客户主要来自美国联邦政府或英国/日本?这决定了时段边界和季节性指数。
  6. 我们处于该时段的哪个阶段——开始前规划、早期(第 1-4 周)、中期还是后期?时段后期会影响仍可采取哪些杠杆(步骤 6)。
  7. CRM 能否按交易报告阶段时长、最后活动日期、预计成交日期变更次数和参与互动的联系人数量?这些是步骤 5 可信度调整的前提。
  8. 模型必须在何时完成?有哪些决策要依赖它——年度计划、招聘,还是季度中途的补救?
  9. 这是一次性需求还是需要持续迭代:(a) 回答今天的“覆盖率足够吗”,(b) 构建组织每周重新审阅的常设分段模型?
  10. 工作量上限:分析师可投入的小时数、是否已有快照基础设施,以及对新增 CRM 规范的接受程度?

在提出任何方案前,根据回答 8-10 重新排列下方的方法阶梯,并说明每个回答具体改变了什么:

  • 季度中途的截止时间会排除“通过转化率反推”这一阶梯——它需要你现在无法收集的多个季度快照历史——并将工作重点转向基于现有目标计算差距。
  • 持续迭代的要求(9b)会提升“通过转化率反推”的优先级,尽管它的效率比较低;一次性需求(9a)则保留默认阶梯。
  • 工作量上限较低时,如果阶段概率无法校准,就排除阶段加权——校准不佳的加权值不如坦诚而粗略的原始值。说明你排除了哪个阶梯,以及原因。

开始建模前先集思广益

覆盖目标很快就会变成硬性要求——“我们需要 4 倍”的说法一旦传到一线,就会影响行为,包括“失败模式”中那些不良行为。先把假设摆出来。

  1. 访谈结束后,根据梯级并结合回答,提出 2-3 种候选方案,说明各自的权衡,并明确给出一项建议。一次只提出一个尚待澄清的问题,尽可能采用选择题形式。
  2. 在进行任何计算前,先获得对方案的明确批准。
  3. 按部分逐步构建模型,每完成一部分都先请用户确认,再进行下一部分:细分目标 → 经可信度调整后的当前覆盖情况 → 时机与季节性 → 缺口与杠杆 → 治理。目标有误,后续所有内容都会失效。
  4. 只有在用户批准完整模型后,才能完成定稿。

如果你的运行环境支持持久记忆,请存储已批准的各细分目标、每个目标反推所依据的比率定义、季节性指数和测量频率——每周重新评估和下一周期的重新运行,都应从记录开始,而不是从头开始。

选择覆盖率计算方法

三个梯级都在回答同一个问题:“管道金额必须达到配额的多少倍?”

  • 效率:原始倍数 > 阶段加权 > 转化率反推
  • 价值:转化率反推 > 阶段加权 > 原始倍数
  • 工作量:转化率反推(按季度持续采集每周快照)> 阶段加权(对已结单交易进行一次校准)> 原始倍数(根据 CRM 历史数据,耗时一小时)
  1. 原始倍数。 按细分计算目标 = 1 ÷ 赢单率;管道金额按面值计入。说明你反推所用的赢单率是哪一种——窄口径(赢单数 ÷(赢单数 + 输单数)),还是宽口径(包括未决交易);两者反推出的目标差异很大。若没有稳定的历史数据,可参考细分基准范围(coverage-benchmarks.md),约经过 2 个完整季度后再替换。
  2. 阶段加权。 管道金额改为 Σ(交易金额 × 组织自身的该阶段历史结单率)——绝不能使用销售人员自行提供的信心值。这需要一致的阶段定义和足够的已结单历史数据来校准;如果不具备这些条件,就采用第 1 级,并设定更高的目标。
  3. 转化率反推。 目标 = 1 ÷ 过去 7-9 个季度的第 3 周管道转化率均值(该期间结单的收入 ÷ 第 3 周开始时的管道金额)。这是最站得住脚的目标,因为它考虑了赢单率忽略的延期和未决交易。方法、评析和示例见:conversion-inversion-method.md。

默认采用第 1 级:原始倍数;只要阶段历史数据允许,从一开始就同时计算阶段加权数值,因为原始数值与加权数值的_差距_本身就是风险信号(第 5 步)。当组织积累了 7 个以上季度的干净快照,且销售周期明显长于测量周期后,将目标升级为转化率反推。

按效率排序会让转化率反推处于不利位置——它价值最高、工作量也最大,因此在任何比值权衡中都会落败。但对于长周期企业销售组织,如果未达标主要源于延期和未决交易,而非输单,仍应将其升级为首选方法:这正是赢单率反推无法看出的失败类型。此排序只是默认方案,并非硬性规定——应根据对用户的了解重新排序;对于已经每周采集快照的 RevOps 团队而言,第 3 级几乎不增加成本。

工作流

  1. 固定分母。 将配额视为既定值——由用户提供,或来自 mbfinotti/sales-skills@sales-quota-setting 运行。不要在此处重新推导;如果它看起来不合理,请指出并交还。

  2. 先分段,再计算。 绝不产出一个适用于全公司的数字:按销售方式/细分市场、产品线和潜在客户来源建模;任期不同的销售代表,其底线应根据各自的历史数据设定。一个综合的 3.4x 可能掩盖了一个健康的 SMB 业务线旁边还有一个资源匮乏的企业级业务线。细分市场区间及其背后的赢单率:coverage-benchmarks.md。

  3. 按细分市场设定目标,并选定合适的档位。将任何沿用的统一「3x」视为待检验的假设,而不是铁律。合理性参照:

    • 统一的 3x 只适用于约 33% 的赢单率。
    • 赢单率超过 50% 的 SMB 销售方式需要约 2x。
    • 赢单率为 15% 的企业级销售方式需要约 5-6x。
  4. 明确说明每个目标的假设。 在目标旁写明其反推的比率及该比率的定义。只给出目标、不给出依据就无法审计;将目标反推即可揭示其暗中假设的赢单率。

  5. 并列计算三个覆盖率:原始、加权、调整后。 计算前,调整后覆盖率要剔除过时、日期在周期之外、反复延期或后期阶段只有单一联系人参与的交易。预期它们会有差异——实际情况中,原始覆盖率大约是加权覆盖率的两倍;最鲜明的来源表述是「名义上的 4 轮 ≈ 可信的 1 轮」;原始与加权覆盖率之间的差距扩大,是最早出现的质量警报。证据和阈值:quality-evidence.md。

  6. 按时间索引模型。 计算每个细分市场的「不可逆点」:周期长度 − 销售周期中位数。此后创建的销售管道无法在本周期内成交;而在季度第 1 天,日期设定为本季度成交的销售管道中,实际只有约 20% 会在本季度内成交。

    • 每周测量覆盖率。
    • 周期中段,将关注重点转向剩余配额的后期阶段覆盖率。
    • 在季度周期的第 4-6 周进行缺口分析。
    • 到第 10 周,只剩下加速或诚实地重新预测这两种选择。
  7. 根据组织自身的已成交赢单历史数据(4-8 个季度)构建季节性指数,并将其应用于每周或每月的销售管道创建目标。统一的创建目标会让每个月的第 1 月看起来都「落后」、第 3 月看起来都「超前」,即使一切正常也是如此。构建方法、来源数据形态和财年日历变体:seasonal-index-build.md。

  8. 计算缺口。

    1. 缺口 = 剩余配额 − 调整后销售管道的预期成交额。
    2. 根据每位销售代表自身的比率,将其换算为每人所需的新销售管道。
    3. 根据原始和加权覆盖率的相对变化,判断问题出在销售管道生成还是转化。
    4. 选择一个杠杆。

    默认优先提高赢单率和阶段推进率——这会产生复利效应,降低该细分市场之后所需的覆盖率。细分市场超过不可逆点后,再优先推动加速;只有诊断结果表明确实存在销售量不足时,才优先增加销售管道生成。公式、示例计算、按优先级排列的杠杆和阈值操作指南:gap-math.md。

  9. 制定治理规则。 明确职责划分——RevOps 负责报告数据的真实性,销售领导层负责据此做出决策。某个细分市场的赢单率变动约 2 个百分点或以上时,重新计算其目标。限制提前拉单:它要付出双重代价,即当前让利,以及下一周期初始销售管道的缺口。

  10. 整理输出(格式如下),运行 Measurement 检查,并反复迭代,直到通过。

B2B 与 B2C / 高速成交

逻辑可以沿用;节奏和衡量单位则不行。

可直接沿用的内容:

  • 1÷转化率机制。
  • 先细分,再计算。
  • 基于自有数据的季节性指数。
  • 差距计算方法。

B2C 保险或汽车团队用剩余目标除以自身成交率,采用的也是同一套模型。

不同之处:

  • 在约 30 天的周期内,季度快照毫无意义——在季度开始时,大多数本期可成交的销售管道还不存在。按月建模,并在月初较早时进行快照(相当于月度第 3 天,对应季度的第 3 周);或者直接建模数量和速度:每周所需线索数 = 目标数量 ÷ 线索到成交转化率。
  • 衡量单位是数量,而非金额。 高速成交和 B2C 业务通常按单位数量(交易、保单、汽车)与月度目标进行比较;当单笔金额相差不大时,按金额加权作用不大。
  • 纯自助式 PLG 根本没有覆盖率指标——不存在承担配额的销售管道。它依靠激活、实现价值所需时间和 PQL 数量;只有在出现销售辅助层、由 PQL 为销售管道提供线索后,覆盖率才有意义。选择这种业务模式是 mbfinotti/sales-skills@sales-motion 的职责。
  • 短周期内,周期中段的差距仍可弥补。 快速周转的团队仍能在本周期内生成线索并完成成交,而长周期团队此时已经错过挽回机会的时点——公式相同,意义却相反。

输出格式

MODEL: period · fiscal calendar · quota input and who set it
SEGMENTS: per segment - method rung · rate inverted (and its definition) · target coverage
COVERAGE NOW: per segment - raw · weighted · adjusted · flag when raw and weighted diverge
TIMING: point of no return per segment · measurement cadence · seasonal index (own-data or borrowed)
GAP: deficit per segment · new-pipeline-required per rep · lever chosen and the diagnostic behind it
GOVERNANCE: owner split · target-recompute trigger · pull-forward cap

失败模式

  • 公司范围内采用单一混合比率——这会抹去细分本来要揭示的信号。改进方法:始终执行步骤 2。
  • 把固定的 3 倍规则奉为准则——它反映了另一个企业销售时代约 33% 的赢单率假设。改进方法:反转自身细分的比率(步骤 3)。
  • 反转一个未明确说明的赢单率——狭义和广义定义反转后会得出截然不同的目标,而且两者都不计入延期:粗略来说,你会赢下三分之一,输掉三分之一,延期三分之一。改进方法:执行步骤 4;当延期是未达标的主要原因时,改用转化率反转法。
  • 让指标要求自行制造销售管道——对销售代表强行施加固定倍数,会鼓励他们囤积僵尸机会并在季末填充管道,最终腐蚀这个原本旨在确保目标达成的指标。改进方法:以调整后的数字为管理依据,绝不使用原始数字;通过资格审核把关各个阶段。
  • 在错过挽回机会的时点后才分析差距——第 11 周的差距无法靠生成线索弥补,销售周期也无法及时完成。改进方法:根据步骤 6,在第 4 至第 6 周分析。
  • 用数量补质量差距——原始数量稳定而加权数量持平,说明机会进入了销售管道,却没有推进;增加数量只会让假象膨胀。先诊断变化方向(gap-math.md)。
  • 没有季节性指数的固定线索创建目标——每个月的第 1 周都会结构性地“落后”,引发毫无依据的销售管道生成恐慌。
  • 在 30 天周期内采用季度覆盖率——衡量的销售管道大多尚不存在。改用月度方案。
  • 不设上限地提前拉单——靠给交易打折来填补当前差距,却给下个周期挖了个坑。

衡量

以下所有项目都通过后,模型才算完成;请反复迭代,直到达到 100%:

  • 每个细分市场的目标都要注明其方法阶梯,以及要反推的具体比率(含定义)。
  • 每个细分市场都要并列显示原始覆盖率、加权覆盖率和调整后覆盖率——绝不能只给出一个数字。
  • 每个细分市场的临界时点都要根据该细分市场自身的周期中位数计算,不能照搬其他细分市场的数值。
  • 季节性指数要基于组织自身的历史数据构建,或明确标注为待积累 4-8 个季度数据后更新的借用默认值。
  • 删除的任何阶梯或选项都要注明,并说明是哪条访谈回答导致其被删除。

周期内的结果 KPI:

  • 目标达成率与预测的对比:覆盖率达到目标的细分市场,其配额达成率应大致符合模型预测。若覆盖率达标但结果持续不佳,说明反推比率有误——应重新计算,而不是提高倍数。
  • 按细分市场跟踪原始覆盖率与加权覆盖率之间的差距趋势——差距扩大意味着质量在达成率显现问题之前就已开始下滑。
  • 跟踪周期第 1 天的管道中,实际在周期内成交的比例,并与约 20% 的方向性基线对比,以校准组织自身的衰减曲线。
  • 阶梯 3 开始运行后,将第 3 周(或第 3 天)的转化快照与预测进行对比。

参考资料

  • 配额尚未设定时,先参阅 mbfinotti/sales-skills@sales-quota-setting,了解如何推导本模型所覆盖的配额。
  • 参阅 mbfinotti/sales-skills@sales-motion,了解如何选择销售模式;销售模式决定此处适用的细分市场区间和衡量频率。
  • 参阅 mbfinotti/revops-skills@sales-pipeline-hygiene,了解定期开展的过时交易审计;其发现将用于步骤 5 的调整后数值。
  • 参阅 mbfinotti/revops-skills@sales-forecast-diagnostic,诊断不可靠预测;这与判断覆盖率是否充足是不同的问题。
  • 参阅 ./references/coverage-benchmarks.md,了解细分市场区间、其背后的机制以及来源可靠性。
  • 参阅 ./references/conversion-inversion-method.md,了解第 3 周转化方法及其示例。
  • 参阅 ./references/gap-math.md,了解缺口公式、按销售代表计算的方法、方向诊断、杠杆措施和阈值操作手册。
  • 参阅 ./references/seasonal-index-build.md,了解指数构建方法及财年日历变体。
  • 参阅 ./references/quality-evidence.md,了解可信度调整背后的量化证据。

评论

支持 Markdown