制作董事会/高管收入报告时：用稳定指标脊与答案先行叙事讲清…

当需要制作董事会收入报告、高管指标 deck、QBR 收入部分、月度收入复盘或投资者更新时，用一套可复用的指标、口径、叙事与签核流程，把收入结果讲成一个连贯故事。

适用场景

解决思路

1. 在提出任何方案前先做访谈；每条消息只问一个问题，能多选就多选，已答项跳过。
2. 访谈确认业务模型：B2B contract subscription、usage/consumption-based、PLG/self-serve、B2C/transactional/marketplace，或 mixed。
3. 访谈确认要构建的产物：quarterly board deck、monthly executive review、weekly revenue review、investor update，或整套 cadence stack。
4. 访谈确认公司阶段：pre-institutional、early venture、growth、late；指标脊会随阶段收紧和变化。
5. 访谈确认现状：没有报告、每期临时重做的 deck，还是已不再被信任的周期性报告。
6. 访谈确认是否已有书面指标定义，以及当前是否有两个 dashboard 在某个 spine metric 上互相矛盾。
7. 访谈确认今天由谁生产数字：RevOps/ops、finance、founder；以及 finance 是否在发布前认证这些数字。
8. 访谈确认本期故事：on plan、miss、beat，还是在 reconciliation 前未知。
9. 访谈确认可访问数据：CRM/pipeline record、billing system、general ledger、product usage events。
10. 访谈确认截止时间：下一次 board meeting、本月 close，或无固定日期。
11. 访谈确认是一次性产物，还是从此每期都重建的周期性资产。
12. 访谈确认投入上限：每期 analyst hours、finance 是否愿意按请求 reconcile、warehouse 或 semantic layer 是否已建模 revenue。
13. 根据最后三个访谈问题先设定指标脊排序：截止时间在 finance close 内时，删除所有需要认证的指标（payback、growth-plus-margin、the three-basis lines）。
14. 根据最后三个访谈问题先设定指标脊排序：有 compounding mandate 时，尽管成本高，也先建 recurring-revenue waterfall 和 dictionary，因为后续每期都会复用。
15. 根据最后三个访谈问题先设定指标脊排序：one-off artifact 时，跳过 recurring-revenue waterfall 和 dictionary，直接从 billing export 报告 bridge。
16. 根据最后三个访谈问题先设定指标脊排序：effort ceiling 低时，把 spine 限制为最多五个单系统指标。
17. 根据最后三个访谈问题先设定指标脊排序：warehouse 中已有 revenue model 时，把所有 cohort 指标提升到最高优先级。
18. 先运行 Interview，在碰指标前固定 artifact、audience、model 和 cadence。
19. 选择 metric spine：5 到 6 个核心指标，绝对上限 8 个；按每单位生产成本能改变多少决策来排序候选指标，成本包括 analyst hours、系统已产出的数据、对 finance 的 reconciliation burden、重建频率，绝不按指标看起来是否标准来排序。
20. 默认 B2B 顺序按最高比率优先：pipeline coverage > win rate > recurring-revenue waterfall > retention pair > attainment distribution > growth-plus-margin > acquisition payback > bookings/billings/recognized lines。
21. 把这个默认顺序当作参考而非法律：根据 Interview 答案和已知用户情况重新排序；如果数据排除某指标，直接删除，而不是把它排在最后。
22. 完整排序轴、并列时的理由、各模型排序、阶段删除项和该顺序会饿死的 durability metrics 见 references/metric-spine.md。
23. 同一套 spine 每期重复使用，让趋势可见；一个新指标只能通过替换一个旧指标进入，并在脚注说明替换。
24. 锁定定义：为每个 spine metric 写 dictionary entry，包含 formula、inclusions/exclusions、source of truth、owner、window，以及每一条有争议规则在书面上的解决方式；entry shape 和 worked example 见 references/metric-dictionary-entry.md。
25. 字段所有权和 source-of-truth 规则来自 mbfinotti/revops-skills@crm-data-governance，只引用，不在这里重新定义。
26. 在起草前冻结 dictionary；周期中途改变定义正是让数字在会议之间跳动的元凶。
27. 在叙事前先 reconcile：CRM 读数（bookings、pipeline）和 finance 读数（billed、recognized）按设计就会不同，只在整个合同期内在合同层级对齐；检查 billings 减去 recognized revenue 等于 deferred revenue 的变化，并确认 headline number 与 finance 将认证的数字一致。
28. 当 harness 能执行代码时，从 two-file export（billing/GL revenue by account、CRM bookings by deal）脚本化 bridge 和 reconciliation；否则请求 finance-certified totals 并手工 reconcile。
29. 绝不发布 finance 没看过的数字。
30. 为每个 spine metric 建 plan-vs-actual-vs-forecast 表，这是所有讨论挂靠的三列。
31. 展示 movement bridges（beginning、additions、losses、ending），而不是净额 delta；只要存在分布，就展示分布而不是平均数，例如 attainment、deal size、cohort curves。
32. 按 answer-first 写叙事：verdict、cause、response、ask 放在第一页；结构按 Narrative 部分，worked report 和 good-vs-bad opening 见 references/worked-report-example.md。
33. 如果本期是 miss，按 Presenting-a-miss 操作：量化缺口、按实际持有的置信度陈述原因、点名修复方案及其 proof metric；根因深度属于 mbfinotti/revops-skills@sales-forecast-diagnostic，不属于本报告。
34. 按 cadence 组装：主报告短，所有回顾性和细节内容放 appendix，deck 作为会前 pre-read 提前几天发出；可选在签核前把叙事 prose 过一遍 humanizer skill。
35. 运行签核链：RevOps 按截止时间发布；Finance 对 ledger 认证；每位职能 leader 验证自己的 section；CEO/CFO 批准；pre-read 提前三到四天发出；用简短 pre-wire calls 在正式会场前暴露反应。
36. 检查 Measurement thresholds；不满足就修复并重新检查，直到每一条都成立。
37. 当 harness 有持久记忆时，存储锁定后的 dictionary、spine 和 restatement log；下一期从它们开始，而不是重新决定；否则把 dictionary 作为版本化文档保存在团队已有文档所在处。
38. 叙事结构采用 answer first、evidence beneath（Pyramid Principle / BLUF）：第一页写明本期 verdict、单一最大 driver、正在进行的 response、要向受众请求的 decision；只读第一页的读者也能掌握完整故事。
39. 把 plan vs actual vs forecast 作为组织 spine；每个 section 都是“发生了什么、为什么、我们正在做什么”，绝不按图表顺序巡游。
40. 把 deck 当 pre-read，把会议留给决策；现场议程瞄准 forward decisions，实践者的目标大约是董事会时间三分之二 forward、三分之一 backward，让 backward detail 留在 pre-read 和 appendix；silent-read narrative memo 实践同理：prose 强迫完整论证，bullets 会隐藏漏洞。
41. 保持主报告短；主报告若超过约二十到三十页，就已经变成 pre-read，应拆分并重建 summary。
42. 每次会议追踪同样的指标、同样的顺序，让跨期趋势无需重新适应即可阅读。
43. 绝不制造意外：每个重大负面信息都必须出现在 pre-read 和会前 pre-wire calls 中；现场才得知坏消息比 miss 本身更伤信任。
44. 坏消息在文档中尽早出现，并以最强的真实好消息收尾；绝不把 miss 夹藏到 appendix。
45. 绝不平滑：报告原始序列，让波动显示出来；平滑会推迟不舒服的对话，并毁掉读者需要的 variance；抵消性变动分别报告，不净额成一个看起来平静的总数。
46. 上报 miss 的解剖结构：量化对计划的 gap；以实际持有的 confidence 命名 driver（“root cause confirmed” 对 “under investigation, findings next period”）；给出 fix、owner 和证明其有效的单一指标；重述 forecast 并反映 miss 的原因；如果原因未确认，就说未确认，过早把原因当事实就是下一次 restatement。
47. “Macro environment” 不是原因，除非数据能把市场变化和执行分开。
48. 所有权拆分：RevOps 发布数字，Finance 认证数字，Leadership 做决策；RevOps 持有发布截止时间而不是展示角色；finance 无法对账到 ledger 的报告不发布。
49. 一个定义胜过一套系统：CRM 和 ledger 在期内总会不一致，解决办法是书面定义每个阶段什么算“right”（sourced、contracted、billed、recognized），而不是争论哪个系统赢。
50. Restatement 礼仪：已发布数字出现重大错误时，显眼地重述：列标签写 “as restated”，脚注说明原因和逐行影响，并记录日志；静默更正会杀死信任；重复 restatement 是源头控制问题，不是格式问题。
51. pre-read 发出后数字冻结；此后更正就是 restatement，并必须按 restatement 沟通，绝不在会议室里悄悄换一个不同数字。
52. 把 cadence 设计为三个产物，而不是一份报告三种速度：weekly revenue review、monthly executive review、quarterly board meeting；每个都有独立 audience、depth 和 forward commitment。
53. Weekly revenue review：面向 revenue team + ops，关注 current-period execution、deal/account risk，产物是 live view、无叙事，forward edge 是本 period 的 commit，live view 建好后每次准备成本近乎零。
54. Monthly executive review：面向 functional heads + CFO，关注 plan-vs-actual trends、funnel、efficiency，产物是 scorecard 加 one-page narrative，forward edge 是 next month’s priorities，准备成本一小时到一天，受 finance close 门控。
55. Quarterly board meeting：面向 executive team + board，关注 full spine + narrative + decisions，产物是 pre-read deck + appendix + pre-wire，forward edge 是 reset targets、capital、hiring，准备成本一周或更多，包括 pre-read、appendix、pre-wires、sign-off chain。
56. 这些 cadence 是层级，不是互相替代的选项，因此不要在它们之间做效率排名；每个回答不同受众的问题，weekly execution signals 喂给 monthly trend read，再喂给 quarterly reset。
57. 当 effort ceiling 收紧时，按顺序丢弃：第一，monthly narrative（weekly view 加一段短 written trend note 可以覆盖）；第二，weekly commentary；绝不丢弃 quarterly board artifact，因为它承担另外两者没有的外部义务。
58. 一人 analyst 团队应在第 1 周就为这种 collapse 做计划，而不是第 12 周才发现。
59. 只有当某个主题需要上一层的受众来做决定时，才把该主题升级一层。
60. 在 B2B 和 B2C/transactional/usage-based/PLG 之间，结构上完全相同，并把这一点写进交付物；以下内容原样保留：movement-bridge shape（beginning、additions、losses、ending）、plan-vs-actual-vs-forecast spine、cohort logic、answer-first narrative、reconciliation and sign-off chain、no-surprises discipline、cadence stack。
61. 变化的是 atoms：contractual recurring base 在 consumption、transactional、consumer 模型中不存在，“recurring” 数字是行为输出；按模型替换 spine atoms，见 references/metric-spine.md，例如 gross transaction volume vs net revenue vs take rate、cohort retention curve shape、repeat purchase rate、contribution-margin layers、engagement ratios、consumption-based retention。
62. 绝不在未说明的情况下，把包含 one-time 或 seasonal revenue 的月份年化成 run-rate；consumption 业务尤其必须先区分 seasonality 和 health degradation，再报告任何一项。
63. 用匹配模型和团队自身历史做 benchmark；seat-based subscription benchmarks 会美化或抹黑其他所有模型。
64. 修复 data-dump deck：第一页 answer-first，细节放 appendix，spine 设上限。
65. 修复 definitions drift between meetings：使用冻结的版本化 dictionary；变更只能作为带脚注的 restatement 进入。
66. 修复 two dashboards disagree on a spine metric：在 deck 发布前对账到一个书面定义，绝不在会议现场对账。
67. 修复 smoothed or netted series：报告 raw series，用 bridges 而非 nets，抵消项分别报告。
68. 修复 vanity metric creep：使用 cohort 和 distribution 视图；每个指标都必须回答一个问题。
69. 修复 averages hiding distributions：把 attainment 和 deal-size 报告为 distribution bands。
70. 修复 stage-mismatched spine：按 references/metric-spine.md 中的 stage tiering；抵抗受众压力，不报告尚未达到阶段的指标。
71. 修复 benchmarks asserted as fact：阈值从自身历史推导；引用任何外部数字时注明日期和来源。
72. 修复 surprise in the room：使用 pre-read 加 pre-wire calls；miss 在文档前部出现。
73. 发布前必须通过 Spine discipline：主报告最多 8 个 spine metrics，目标 5-6 个；上一期 spine metrics 100% 以相同定义重现，否则变更必须作为 restatement 加脚注。
74. 发布前必须通过 Durability check：spine 至少包含一个 durability metric（retention pair、cohort retention curve、consumption net retention 或 margin-adjusted payback），否则报告必须说明哪个数据缺口删除了它；纯按生产成本排序的 spine 会漂向全 velocity metrics，并在 base 停止支撑前一直显得健康。
75. 发布前必须通过 Definition coverage：每个 spine metric 都有 dictionary entry，包含 formula、source of truth、owner、window；deck 中零个指标没有 entry。
76. 发布前必须通过 Reconciliation：headline revenue number 与 finance-certified figure 完全一致，或在 deck 中点名 reconciling item；展示的数字满足 billings/recognized/deferred identity。
77. 发布前必须通过 Answer-first test：把第一页单独交给无上下文读者，他们必须能说出 period verdict、最大 driver 或 risk、以及 ask；三者任一缺失即失败。
78. 发布前必须通过 Miss handling：每个对计划的重大 gap 都出现在文档前三分之一，并有 cause-confidence label、owner、proof metric；任何重大内容都不得在 appendix 边界之后才首次出现。
79. 发布前必须通过 Meeting design（仅 board cadence）：现场议程把多数时间，目标三分之二，分配给 forward decisions；每个 decision item 都点名 decision、context 和 recommendation。
80. 发布后持续追踪 Restatement count per year：上升意味着上游 controls 问题。
81. 发布后持续追踪 meetings 是否以记录下来的 decisions 结束；一个不再产出 decisions 的周期性会议，意味着 artifact 已漂回 data dump。
82. 可选集成仅在用户点名平台时启用；Semantic layers（dbt MetricFlow、Cube、Looker/LookML）中，用代码实现版本化 metric-dictionary discipline，在那里一次定义每个 spine metric，让所有 dashboard 读取同一定义。
83. 可选集成 Salesforce 时注意：forecast-category fields 可独立于 stage 编辑，report-time roll-ups 可能与 dashboard snapshots 不同；要基于 export 认证，而不是 live view。
84. 可选集成 HubSpot 时注意：默认 deal-stage probabilities 是可编辑占位符，不是 measured conversion；绝不能让基于它们的 weighted-pipeline figure 未经调整进入 deck。
85. 参考 references/metric-spine.md 获取各业务模型的 spine、stage tiering，以及首次发布前必须锁定的 contested definitions。
86. 参考 references/metric-dictionary-entry.md 获取 dictionary entry shape 和 worked example。
87. 参考 references/worked-report-example.md 获取 report shape、带 miss 的季度 worked example，以及 good-vs-bad narrative opening。
88. 使用 mbfinotti/revops-skills@revenue-kpi-framework 设计本报告从中选择的 org-wide metric tree；它决定存在哪些指标以及如何向上 reconcile，本技能把结果 spine 变成面向一个受众的叙事。
89. 当定义本身在系统或职能间有争议时，使用 mbfinotti/revops-skills@revenue-data-governance-strategy；它裁定谁的 ARR 获胜以及谁可以改，本报告的 dictionary 引用它而不是重新争论。
90. 用 mbfinotti/revops-skills@sales-forecast-diagnostic 调查 forecast 为何 miss。
91. 用 mbfinotti/revops-skills@crm-data-governance 获取 metric dictionary 依赖的 field-ownership 和 source-of-truth 规则。
92. 用 mbfinotti/revops-skills@sales-pipeline-hygiene 做周期性审计，让 pipeline-derived spine metrics（coverage、win rate）保持可信。
93. 当 weighted pipeline 因 stage 不可被买家验证而不可信时，使用 mbfinotti/revops-skills@pipeline-stage-definition-audit。

适用边界 · 注意事项

• 不要用于设计组织级 KPI 层级或指标框架；那属于 mbfinotti/revops-skills@revenue-kpi-framework。
• 不要用于在某个具体 BI 工具中搭建 dashboard；本技能只管报告内容和叙事，不管 BI 实现。
• 不要用于调查预测为何失误的根因；那属于 mbfinotti/revops-skills@sales-forecast-diagnostic，本技能只把已完成的诊断转成董事会叙事。