调研探索
设计公司级收入 KPI 框架:从董事会到一线…
当需要为整个组织设计宏观层面的收入 KPI 体系(哪些指标在哪个层级、如何向上汇总、谁负责、配什么护栏)时使用。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
设计公司级收入 KPI 框架:从董事会到通用
解决思路
- 先做访谈再设计:每次只问一个问题,尽量用选择题,已答过的跳过。需确认触发原因(无框架/团队达标但收入不涨/各看板数字不一致/新领导要统一记分板/规划周期要求)、B2B 还是 B2C(若 B2C 再分订阅、交易/电商还是平台)、收入模型(席位订阅、用量/消费、混合、PLG 自助、销售驱动、平台抽成)、公司阶段(pre-seed/seed、A 轮、B 轮、C+ 增长期、上市前)、实际存在并审阅数字的组织层级、老客户收入(留存+扩展)与新客收入占比、已流通的资产(北极星、OKR、指标字典、已命名负责人)、每个候选指标有多少季度历史以及财务与 CRM 是否对得上头条数字、交付截止日期、是一次性记分板还是复利型运营资产、以及投入上限(职能负责人工作坊时长、分析师时间、为争议指标指定单一负责人的政治资本)。
- 明确范围边界:只做框架设计,不写报告、不建看板、不做定义治理,这些路由给兄弟技能。
- 从四个构建深度中选一档,并按访谈答案重新排序,设计前必须获得用户明确同意:①指标短名单(按阶段和商业模式挑 5-7 个董事会/高管指标,不做分解,一个下午);②驱动树(顶层结果 + 3-5 个驱动指标,含对账数学、每个一个负责人和一个护栏,数天含归属谈判);③完整树(驱动分解到团队级和活动级叶子,附高度与节奏图,数周跨职能工作坊);④编码化框架(完整树的定义写入指标字典或语义层,评审接入固定的 WBR/MBR/QBR 节奏,一个季度建立后成为常设工作)。默认选驱动树;当两个团队争同一个指标或规划需要活动级分解来定编制与预算时升到完整树;当同一指标反复出现看板分歧或多个 BI 工具服务同一数字时升到编码化框架,低于该阈值编码是过早的中心化。
- 先定树的顶层,再分解:收入本身通常不是好的北极星(滞后,只说明增长已发生而不指出干预点),好的顶层指标应领先收入且“差一级够不着”(只能通过其输入移动)。常见可辩护的顶层:B2B 订阅用 NRR 或 ARR 瀑布,用量制费用量/消费结果加 RPO,B2C 用复购或队列留存结果。若用户坚持单一复合数字且拒绝分解,说明一次 Cutler 的告诫,然后好好做短名单档而不是糟糕地做树。
- 进入显式头脑风暴:给出 2-3 个候选树设计,每个说明顶层指标、3-5 个驱动及其分解算子、归属落在哪里、该设计优化什么、常设维护成本;随后做权衡对比并给一个带理由的推荐。候选必须真正不同(如 NRR 为顶、留存加权;ARR 瀑布为顶、获客加权;北极星用量为顶、PLG),不能是同一设计的三种换皮。按访谈答案(收入结构、阶段、模型)为当前用户排序并说明哪个答案驱动了推荐。
- 按四种分解算子设计树,按算术而非口味为每个节点选择:乘法(Revenue = Traffic × Conversion × AOV)、加法(Net New ARR = New Logo + Expansion − Churn − Contraction)、漏斗/比率(阶段间转化、coverage = qualified pipeline / target)、输入/输出(可控输入喂养结果)。分支因子:一个顶层指标、3-5 个驱动、每个驱动 2-3 个团队级指标;当叶子是一个团队能在一周内移动的指标时停止分解。
- 对每个节点应用周期时间链测试:活动级叶子应同日可动,团队指标应在自然业务周期内可动,驱动应在报告期内可动;若链条不成立,树是装饰性的而非因果性的。
- 复合指标必须可分解:NRR 本身是 gross retention + expansion − contraction,停在 NRR 的树让团队无从下手;Rule of 40、magic number 及任何比率同理,要把分子分母暴露为独立节点。
- 为每个分支指定唯一直接负责的负责人(对该数字负责的决策者,不一定是干活的人);公司级指标也应在职能级存在并有职能负责人,高管以下无人拥有的指标只是记分板不是杠杆。条件允许时拆分 owner 与 steward:owner 对数字表现负责,steward 对定义与数据质量负责,二者不同不违反单一归属。
- 为每个被拥有的指标配恰好一个成对的反指标,衡量其数量维度看不到的质量维度(Grove 的配对指标,1983,是抵御 Goodhart 定律的唯一持久防线);护栏挂在输入指标层级、与输入并排,而不是事后钉在顶层指标上。把博弈判定规则写进框架:被拥有的指标上升而其配对反指标连续两个评审周期下降,视为博弈而非改进——升级处理,绝不奖励。
- 把树中每个指标映射到审阅它的层级与频率:IC/团队看活动叶子和一个被拥有的驱动输入,日/周(WBR);职能负责人看驱动指标和效率比率,周/月(MBR);高管看顶层指标、NRR、Rule of 40、burn multiple,月/季(QBR);董事会看 ARR 增长、净 ARR、现金、Rule of 40,季度。每个高度强制 5-7 个指标上限;同一棵树服务所有层级,每层只看自己那一片。
- 在评审中要求指标负责人呈现洞察而非数字——朗读数字正是该节奏要防止的失败模式。明确各节奏层的决策权:月度检查执行、改变行为;季度检查战略、改变计划;月度会议若悄悄获得季度权限(改配额、改区域)会摧毁季度层本应检验的计划。
- 对每个候选指标跑阶段门与模型门:阶段门——pre-seed 看激活与留存领先,B 轮 NRR 与全负荷 LTV:CAC 到位,增长期 Rule of 40 与 burn multiple 到位;治理规则是早期可放过效率指标但绝不放过留存,晚期可放过增长率但绝不放过效率,过早强制某指标(PMF 前讲单位经济)与过晚采纳同样是设计错误。模型门——ARR/NRR 惯例是为承诺制月订阅建立的,承诺减弱时退化:用量制用 RPO 和承诺 vs 已消费追踪(与 NRR 并列或替代),平台用 GMV 加抽成率(单看 GMV 是虚荣),B2C 交易用队列曲线和贡献毛利栈。树的数学、归属纪律、护栏配对和高度上限在各模型间不变,只有原子变化。
- 按 B2B/B2C 分别设计:B2B 订阅树以留存加权——顶层 NRR/GRR 与 ARR 瀑布,新客分支下挂管道驱动(coverage、win rate、deal size),留存分支下挂扩展与流失驱动;logo 留存与金额留存是独立节点,混在一起会掩盖相反动态。B2C 订阅/交易树以复购加权——队列留存曲线(必须走平,优秀的会微笑)、复购率、频率真正重要时的 DAU/MAU,以及 CM1/CM2/CM3 贡献栈作为效率脊柱;优先用贡献毛利 LTV 和队列曲线而非点估计 LTV 公式(其输入相互依赖而非独立)。两者相同的是:可对账分解、单一归属分支、Grove 护栏配对、5-7 上限、相对的领先/滞后测试、两周期博弈规则。
- 按输出形态逐个产出工件并逐一让用户验证,绝不整包呈现:metric-tree.md(每个节点含名称、算子、父级数学、相对父级的领先/滞后角色);ownership-map.md(每分支的 owner、steward(若拆分)、高度、评审节奏、该评审层的决策权);guardrail-register.md(每个被拥有指标的配对反指标、所防范的伤害、两周期升级规则);gating-notes.md(阶段/模型门结果——哪些因过早被剔除、哪些计划何时进入);definition-stubs.md(每个指标的建议计算、方法披露(NRR 方法、超量收入处理、排除项)、样本窗口,交给数据治理技能托管)。
- 跑通过阈值检查并迭代直到七条全部成立:每个父节点按声明的和、积或比与其子节点对账,无孤儿指标漂浮在树旁;每个分支恰好一个具名负责人,跨两团队的指标已在交接边界重切而非共享;每个被拥有指标恰好一个配对反指标且两周期升级规则已写下;任何高度的切片不超过 7 个指标且每层切片通过树数学连接到下一层;每个叶子通过“本周期可影响”测试且每个节点相对父级的领先/滞后角色已声明;每个定义桩带方法披露、每个引用的基准带调查、样本量和年份;指标集通过两道门——没有对阶段过早的、没有从错误商业模式借来的。若归属之争卡住某分支,交付框架时把该分支负责人标为具名发起人的待决事项,绝不以共享归属作为妥协。
- 若运行环境有持久记忆,存储已定的顶层指标、树、负责人和护栏配对,使后续报告与规划从已定框架出发而非重新访谈。
- 用框架自身的 KPI 检验其是否有效而非是否存在:指标争议(两个看板或两个职能对头条数字不一致)在采纳后趋零;各评审节奏按期举行且各层决策权被尊重(无月度会议悄悄改计划);被拥有指标上升而配对指标下降时护栏升级确实触发(博弈规则从不触发的框架要么是非常诚实的组织,要么是无人看的登记册);计划偏差能通过树解释——顶层指标未达标时,评审在一个周期内指出哪个分支驱动,而不是另立调查。
适用边界 · 注意事项
- 不要用它来撰写董事会/高管报告本身——那属于 revenue-reporting 技能。
- 不要用它建看板、写 SQL 或做指标定义治理——定义的家与变更控制属于数据治理技能。
- 当用户只想要一次性记分板且无分解需求、或没有发起人支持归属之争时,不要强行做完整树或编码化框架,应停在短名单或驱动树档并说明原因。