关于 revenue-reporting
用于编制高管和董事会营收报告的 Skill,适合需要统一指标、经财务核验数据及清晰叙述计划、实际与预测的团队。它强调稳定的指标集合、书面定义、数据核对和面向决策的报告。
主要功能
- 01访谈以明确受众与节奏
- 02筛选稳定的核心指标
- 03记录指标定义与数据来源
- 04核对 CRM 与财务数据
- 05组织计划、实际与预测
- 06准备未达标说明与审批
适用场景
- 01准备季度董事会营收预读材料
- 02编制定期月度高管评审
- 03按置信度说明营收未达标
- 04统一不同周期的报告指标
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ mbfinotti/ revops-skills --skill revenue-reporting安装后在 Claude Code 中输入/revenue-reporting确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
evals/evals.jsonreferences/metric-dictionary-entry.mdmetric-spine.mdworked-report-example.md详细介绍
营收报告
将高管或董事会营收报告构建成一个连贯的故事:以一组精简、稳定的核心指标为基础,围绕计划值、实际值和预测值,采用结论先行的叙事方式展开。难点往往不在算术,而在于统一定义、核对 CRM 记录与财务记录,并确保董事会不会当场才得知坏消息。
先明确范围边界:
范围内:
- 报告包含哪些内容,以及如何呈现。
- 数字及其可信度。
范围外:
- 在任何特定 BI 工具中构建仪表板。
- 设计组织层级的 KPI 框架(哪些指标适用于哪些组织层级,以及如何汇总)——这是本仓库之外的独立战略工作。
- 调查预测出错的原因——将这项工作交给
mbfinotti/revops-skills@sales-forecast-diagnostic,然后使用此技能将最终诊断转化为董事会叙事。
访谈
提出任何建议前,先提问。每条消息只问一个问题;尽可能提供多选项。已回答的问题跳过。
- 商业模式是什么——B2B 合同订阅、基于用量/消耗的模式、PLG/自助服务、B2C/交易型/市场平台,还是混合模式?
- 要制作哪种材料——季度董事会演示文稿、月度高管评审、每周营收评审、投资者更新,还是整套例行报告?
- 公司处于哪个阶段——机构融资前、创业早期、成长期,还是后期?(核心指标会随阶段收紧并调整。)
- 目前已有些什么——什么都没有、每期临时重做的演示文稿,还是大家已经不再信任的定期报告?
- 是否有任何书面指标定义?目前是否有任意两份仪表板对某项核心指标(经常性营收、留存率、覆盖率)给出不同结果?
- 目前由谁生成数字——RevOps/运营、财务,还是创始人?财务会在发布前核验吗?
- 本期的情况如何——符合计划、未达标、超预期,还是要等对账后才能确定?
- 哪些数据可以访问——CRM/销售管道记录、账单系统、总账、产品使用事件?
- 必须在什么时候完成——下一次董事会会议、本月结账时,还是没有固定日期?
- 这是一次性材料,还是今后每期都会重新制作的常规报告?
- 工作量上限是多少——每期可投入多少分析师工时、财务是否会按要求对账,以及是否已有用于建模营收的数据仓库或语义层?
最后三个问题会在选择任何指标前决定核心指标的优先顺序:
- 截止日期在财务结账期内:本周期剔除所有需要认证的指标(回本期、增长加利润率、三口径明细)。
- 需要持续复用:尽管成本较高,也优先构建经常性营收瀑布和指标词典,因为后续每期都能复用。
- 一次性材料:跳过这两项,使用账单导出数据报告营收桥接。
- 工作量上限较低:将核心指标限制为五项单一系统指标。
- 数据仓库中已有营收模型:将所有群组指标提升到优先顺序的最前面。
工作流
- 开展访谈;在处理指标之前,先确定对象、受众、模型和频率。
- 选定指标主干:五到六项核心指标,绝对上限为八项。按每单位生产成本能带来的决策变化为候选指标排序——分析师工时、系统已生成的数据、与财务核对的负担、需要重建的频率——绝不能按指标看起来有多标准来排序。默认的 B2B 顺序(从比率最高到最低):管道覆盖率 > 赢单率 > 经常性收入瀑布图 > 留存率组合 > 目标达成率分布 > 增长加利润率 > 获客回本期 > 预订额/开票额/确认收入。此顺序只是默认值,并非定律:应根据访谈答案,以及对用户已知的其他所有信息重新排序;如果用户的数据排除了某项指标,就删除该指标,而不是把它排在最后。完整的排序维度、合理说明的并列项、各模型的排序、各阶段的删减,以及此顺序会挤占的持久性指标,见 references/metric-spine.md。每个周期都沿用同一主干,让趋势清晰可见;新增指标必须替换一项,并在脚注中说明此次替换。
- 锁定定义:为主干中的每项指标编写一条字典条目,包括公式、纳入/排除项、事实来源、负责人、时间窗口,以及所有已书面解决的争议规则(条目格式和完整示例见 references/metric-dictionary-entry.md)。字段归属和事实来源规则来自
mbfinotti/revops-skills@crm-data-governance——应引用这些规则,不要在此重新定义。开始起草前先冻结字典;周期中途更改定义会导致数字在不同会议之间变动。 - 先对账,再讲述:CRM 口径(预订额、管道)与财务口径(开票额、确认收入)本来就会不同,而且只有在完整合同期限内按合同逐笔核对才会一致——核查要点是开票额减确认收入等于递延收入的变动,并且关键数据与财务会签的数字一致。当执行环境能够运行代码时,根据两份导出文件(按账户列示的开票额/总账收入,以及按交易列示的 CRM 预订额)编写桥接与对账脚本;否则请财务提供经认证的总额,再手动对账。绝不要发布未经财务审核的数字。
- 为主干中的每项指标建立计划值-实际值-预测值表格——所有讨论都围绕这三列展开。展示变动桥接(期初、增加、损失、期末),而非净变动;凡有分布数据时(目标达成率、交易规模、队列曲线),展示分布而非平均值。
- 先给出答案,再写叙述:在第一页写明结论、原因、应对措施和请求。按下文“叙述”部分的结构组织;完整报告示例以及优秀与糟糕开篇的对比见 references/worked-report-example.md。
- 如果本周期未达标,遵循“汇报未达标”部分:量化差距,按实际把握的置信度说明原因,并指出补救措施及其验证指标。根因分析的深度要求属于
mbfinotti/revops-skills@sales-forecast-diagnostic,不属于本报告。 - 按节奏组装(见“节奏”):主体简短,所有回顾性细节放在附录中,并在会议前几天发送演示文稿作为预读材料。签核前,也可以让人工润色技能处理叙述性文字。
- 执行签核流程:
- RevOps 按截止时间发布。
- 财务根据总账进行认证。
- 各职能负责人核验各自负责的部分。
- CEO/CFO 批准。
- 提前三到四天发送预读材料。
- 提前进行简短沟通,先了解各方反应,再进入会议。
- 检查下文的“衡量阈值”;修正并重新检查,直到全部达标。
- 如果执行环境具有持久记忆,则存储已锁定的字典、主干和重述日志——下一周期直接沿用,不必重新决策。否则,将字典作为带版本记录的文档,保存在团队现有的文档存储位置。
叙事结构
- 先给结论,再列证据(金字塔原理/BLUF):第一页说明本期结论、最重要的单一驱动因素、正在采取的应对措施,以及希望听众做出的决策。读者即使只看到这一页,也能了解完整情况。
- 以计划、实际和预测为主线;每个部分都要回答“发生了什么、为什么、我们正在如何应对”,而不是带读者逐一浏览图表。
- 幻灯片用于会前预读;会议用于做决策。现场议程应聚焦前瞻性决策——实践者通常会将约三分之二的董事会时间用于前瞻性议题,三分之一用于回顾性议题——并将回顾性细节放在预读材料和附录中。静默阅读叙事备忘录的做法也指向同一方向:连贯的文字能迫使论证完整,而项目符号可能掩盖其中的漏洞。
- 控制正文篇幅。正文一旦超过约 20 至 30 张幻灯片,就已经成了预读材料;此时应拆分内容并重做摘要。
- 每次会议都按相同顺序追踪相同指标,让读者无需重新熟悉内容就能看清各期趋势。
汇报未达目标
-
绝不让人意外:所有重大的负面情况都要出现在预读材料中,并在会议前通过预沟通告知相关人员。会上才得知坏消息,比未达目标本身更损害信任。
-
在文档前面尽早说明坏消息,并以最有力且属实的内容收尾;绝不要把未达目标夹在附录里。
-
绝不平滑处理:报告原始序列,让波动如实呈现;平滑处理会推迟棘手的对话,也会抹去读者需要了解的差异。相互抵消的变动应分别报告,而不是相互抵消后并入看似平稳的总数。
-
未达目标的汇报要素:
- 量化与计划之间的差距。
- 说明驱动因素,并如实表述对原因的把握程度(“根本原因已确认”与“仍在调查,结果将在下期公布”)。
- 说明补救措施、负责人,以及用于验证措施是否奏效的单一指标。
- 根据未达目标的原因重新说明预测。
如果原因尚未确认,就应明确说明;过早将某个原因当作事实,是下一次重述的开端。
-
除非数据能够区分市场变动与执行情况,否则“宏观环境”不能算作原因。
对账、重述与签核
-
职责划分:
- RevOps 发布数据。
- Finance 认证数据。
- 领导层做出决策。
RevOps 负责按时发布,而不是负责汇报;如果报告无法与 Finance 的分类账对账,就不得发布。
-
统一定义胜过统一系统:CRM 与分类账在当前周期内总会出现差异;解决方法是书面定义各阶段(线索来源、签约、开票、收入确认)“正确”所指的含义,而不是争论哪个系统说了算。
-
重述规范:已发布的数据存在重大错误时,应明确重述。
- 将列标为“重述后”。
- 在脚注中说明原因和对各行的影响。
- 记录在案。
静默更正会摧毁信任。反复重述说明源头的控制措施存在问题,需要修复,而不是格式问题。
-
预读材料发布后,数据即冻结。此后如需更正,就属于重述,必须按重述方式传达;绝不能在会议上悄悄换成不同的数据。
节奏
有三种产物,而不是同一份报告的三个速度版本——每种产物都有自己的受众、深度和前瞻性承诺:
| 维度 | 每周收入评审 | 每月高管评审 | 季度董事会会议 |
|---|---|---|---|
| 受众 | 收入团队 + 运营团队 | 职能负责人 + CFO | 高管团队 + 董事会 |
| 重点 | 本期执行、交易/客户风险 | 计划与实际趋势、销售漏斗、效率 | 完整主线 + 叙述 + 决策 |
| 产物 | 实时视图,无叙述 | 记分卡 + 一页叙述 | 会前阅读材料演示文稿 + 附录 + 会前沟通 |
| 前瞻范围 | 本期承诺 | 下月优先事项 | 重设目标、资本、招聘 |
| 准备成本 | 实时视图建成后,每次运行的成本几乎为零 | 一到两个小时,取决于财务结账 | 几天:会前阅读材料、附录、会前沟通、审批链 |
这些是不同层次,而非相互竞争的选项,因此不适用效率排名——每种产物回答的都是不同受众的问题;每周执行信号汇入月度趋势解读,再汇入季度重设。给三种彼此不能替代的产物排名,会造成虚假的精确感。
真正需要排序的是,当工作量达到上限时,哪些内容会被删减:
- 首先:月度叙述(每周视图加简短的书面趋势说明即可涵盖)。
- 其次:每周评述。
- 绝不删减:季度董事会材料——它承担了另外两种产物没有的外部义务。
只有一名成员的分析团队应在第 1 周就为这种压缩做好计划,而不是等到第 12 周才发现问题。
只有当某个主题需要更高层级的受众来做决策时,才将其升级到更高层级。
B2B 与 B2C / 交易型 / 基于用量 / PLG
- 所有模式在结构上完全相同,应在交付物中明确说明。 以下内容都可原样沿用:
- 变动桥接结构(期初、增加、流失、期末)。
- 计划与实际与预测的主线。
- 队列逻辑。
- 结论优先的叙述方式。
- 对账与审批链。
- 不制造意外的纪律。
- 节奏体系。
- 变化的是基本构成要素。 基于合约的经常性收入并不存在于基于用量、交易型和消费型模式中——“经常性”数值是行为结果。应相应替换主线的基本构成要素(各模式的主线见 references/metric-spine.md):
- 交易总额与净收入与抽成率。
- 队列留存曲线形态。
- 复购率。
- 贡献利润率层级。
- 参与度比率。
- 基于用量的留存。
- 如果某个月包含一次性或季节性收入,切勿将其年化为运行率而不作说明;尤其是基于用量的业务,在报告之前必须先将季节性与健康度下降区分开来。
- 应以相同模式的基准和团队自身的历史数据作比较——基于席位的订阅业务基准会让其他所有模式显得过于出色或过于糟糕。
失败模式
| 陷阱 | 失败原因 | 改进方法 |
|---|---|---|
| 数据倾倒式演示文稿 | 受众忙于核对图表,而非做出决策 | 首页先给出答案;细节放入附录;主线指标数量设上限 |
| 不同会议中的定义不一致 | 用词相同,数字不同——会议变成定义之争 | 冻结并版本化词典;只有通过脚注重述才能更改 |
| 两个仪表板中的主线指标不一致 | 第一个矛盾一出现,所有数字的可信度都会崩塌 | 演示文稿发布前,先统一到一个书面定义,绝不在会议现场才处理 |
| 平滑或净额处理的序列 | 隐藏了作为信号的变动;原始差异一旦丢弃,就无法恢复 | 保留原始序列;用桥接分析呈现净额变化;单独报告抵消项 |
| 虚荣指标不断增加 | 累计图表和讨喜的细分结果总是向上;它们无法支持决策 | 查看群组和分布;每项指标都必须回答一个问题 |
| 平均值掩盖分布差异 | 两个团队只共享一个均值,别无其他 | 以分布区间报告目标达成率和交易规模 |
| 主线指标与阶段不匹配 | 在早期公司使用后期阶段的效率指标(或反过来)会造成误导 | 在主线指标参考中按阶段分层;不要因受众施压而报告尚未达到阶段的指标 |
| 将基准数据当作事实 | 流传的数字已经过时,且仅适用于特定细分群体 | 根据自身历史数据推导阈值;注明任何外部数据的日期和来源 |
| 会上出现意外 | 信任会立即且永久地受损 | 提前发送预读材料并事先沟通;在文档中尽早披露未达标情况 |
度量指标与通过标准
报告发布前必须通过以下所有检查;反复迭代,直到全部达标:
- 主干指标纪律:正文中的主干指标最多为 8 项(目标为 5-6 项);上一期的主干指标必须 100% 保留且定义完全相同,否则必须以脚注说明这是重述。
- 持久性检查:主干指标至少包含一项持久性指标(留存率组合、队列留存曲线、消费净留存率或经利润率调整的回本周期),或者报告必须说明因何种数据缺口而删除了该指标。如果主干指标只按生产成本排序,就会逐渐只剩速度指标,并且在用户基础开始流失前看起来依然健康。
- 定义覆盖率:每项主干指标都必须有一条词典条目,包含公式、事实来源、负责人和统计窗口;演示文稿中不得有任何未收录的指标。
- 对账:标题中的收入数字必须与财务认证数字完全一致,否则必须在演示文稿中注明调节项目;账单金额/已确认金额/递延金额之间的勾稽关系必须与所示数字相符。
- 先答结论测试:单独将第一页交给一位不了解背景的读者;他们必须能说出本期结论、最大的驱动因素或风险,以及需要提出的请求。三者中任何一项缺失,报告都不合格。
- 未达标事项处理:计划中的每项重大缺口都必须出现在文档前三分之一处,并标注原因置信度、负责人和验证指标;任何重大事项都不得首次出现在附录分界线之后。
- 会议设计(仅适用于董事会会议节奏):现场议程的大部分时间(目标为三分之二)必须用于前瞻性决策,且每项决策都必须说明决策事项、背景和建议。
发布后,持续跟踪以下信号:
- 每年重述次数:次数上升意味着上游控制存在问题。
- 会议是否以记录决策告终:例行会议若不再产出决策,说明材料已退回到单纯的数据堆砌。
可选的集成说明
除非用户提及以下某个平台,否则跳过本节。
- 语义层(dbt MetricFlow、Cube、Looker/LookML):在代码中落实版本化的指标词典规范,在其中为每项主干指标定义一次,并让所有仪表板读取同一套定义。
- Salesforce:预测类别字段可以独立于阶段编辑,报表生成时的汇总也可能与仪表板快照不同;应根据导出数据进行认证,而非依赖实时视图。
- HubSpot:默认交易阶段概率是可编辑的占位值,并非实测转化率;切勿让基于这些概率计算出的加权销售管道金额未经调整就进入演示文稿。
参考资料
- 有关各业务模式对应的指标主干、阶段分层,以及首次发布前需要敲定的争议定义,请参阅 references/metric-spine.md。
- 有关指标词典条目的结构和一则完整示例,请参阅 references/metric-dictionary-entry.md。
- 有关报告结构、包含一次未达标情况的季度示例,以及优秀与糟糕的叙述式开篇,请参阅 references/worked-report-example.md。
mbfinotti/revops-skills@revenue-kpi-framework用于设计本报告选取指标所依据的全组织指标树——该技能决定有哪些指标,以及这些指标如何向上汇总;本技能则将由此得出的指标主干转化为面向单一受众的一段叙述。- 当不同系统或职能部门对定义存在争议时,使用
mbfinotti/revops-skills@revenue-data-governance-strategy——它负责确定以谁的 ARR 为准,以及谁可以修改该定义;本报告的词典会引用这些结论,而不是重新讨论。 - 使用
mbfinotti/revops-skills@sales-forecast-diagnostic调查预测未达标的原因。 - 使用
mbfinotti/revops-skills@crm-data-governance获取指标词典所依赖的字段所有权和事实来源规则。 - 使用
mbfinotti/revops-skills@sales-pipeline-hygiene进行定期审计,确保从销售管道衍生的指标主干(覆盖率、赢单率)值得信赖。 - 当因阶段无法由买方验证而导致加权销售管道不可信时,使用
mbfinotti/revops-skills@pipeline-stage-definition-audit。