qbr-builder

用途

QBR Builder 面向两类季度回顾场景：一是针对单个客户账户面向其决策者的 QBR，二是面向公司董事会或创始人的董事会材料。两者回答同一个问题：上一个季度换来了什么，下一个季度的押注是什么。如模式不明显需先询问，默认 QBR。

两种模式与受众

QBR 模式：对象是一个客户账户及其决策者，运行在该账户的交付与收入数据上，负责人是客户经理。

BOARD 模式：对象是公司董事会或创始人，运行在整个收入引擎与全部渠道上，由 CEO 与负责收入的人共同负责。

硬性规则

• 计划与实际放在同一张表内。每个指标行包含：指标 · 计划 · 实际 · 占计划百分比。只有实际值的董事会材料视为未完成。
• 无计划不臆造计划。若账户没有达成一致的目标，写明“本季度没有计划；我们正在为下一季度确定基线”，并建立基线。不得回溯填入目标让季度看起来达标。
• 两个计划来源冲突时：同时点名两者，采用受众看过的那个，并标出差距。不得取平均值。
• 价值要换算为客户自己的单位：节省的金额、返还的工时、守住的截止日期、消除的风险。“我们打了 47 通电话”属于活动量。若无法把活动量换算成客户单位，则同时展示活动量，并把缺失的换算写成会议上待解决的开问题。
• 缺失数据写为“无数据”，绝不建模猜测。无法访问的系统（如客户的 CRM、财务工具）中的指标打上标记，不做猜测。
• 使用用户的语言与平实措辞。在乌克兰语中避免外来词：用 прогноз 而非 форкаст，用 припущення 而非 драйвери，用 завантаження команди 而非 utilization，用 кваліфіковані ліди。

输入项（写作前先取数）

• 季度目标：来源为客户计划、董事会材料、收入计划；缺失时标注“无计划”并建立基线。
• 各漏斗阶段实际值：来源为触达平台、CRM、交付跟踪工具；缺失时逐阶段标注“无数据”。
• 账户健康度：来源为 client-health-check 输出；若已安装先运行，否则向账户负责人索取 5 行健康度速读并标注为自述。
• 扩展候选：来源为 upsell-mapper 输出；若已安装先运行（QBR 是扩展落地的场合），否则列出客户未使用的服务，并给出基于本季度事实的理由。
• 本季度交付事件：来源为项目经理笔记、工单、发布记录；向交付负责人询问，最多 5 个问题。
• 上一次 QBR 的承诺：来源为上一次的 QBR 页面；若没有，这是第 1 次 QBR，需说明。
• 每周触达数字（BOARD 模式，外呼渠道）：来源为 weekly-outreach-report 页面（若该技能已安装并使用），否则直接从触达平台取数。

client-health-check 与 upsell-mapper 位于 account-management-skills 包；weekly-outreach-report 位于 outbound-engine-skills 包。

QBR 模式结构

• 账户护照：客户、服务线、合作起始时间、当前价值、对方参会人。
• 核心要点：3 到 4 句。本季度交付了什么、哪里滑落了、下一季度的一步。最后写、最先读。
• 计划与实际：带“占计划百分比”列和 RAG 状态的表格。金额在上，活动量在下。
• 我们做了什么：3 到 5 个事件及其效果——事件，以及它改变了对方哪个数字。任务清单不属于此处。
• 账户健康度：健康检查得分，以及相比上季度的变化。
• 没做成的事：强制项。缺少它的回顾读起来像推销，会在下一次消耗信任。一个原因、一个结论，不自我鞭挞。
• 下一季度：3 到 5 项，每项有负责人和日期。另加需要客户提供什么。
• 扩展提案：来自交叉销售地图的 2 到 3 项，每项含基于本季度事实的理由。以入门步骤表述（“下次状态会上我们展示这在你这儿会是什么样”），绝非推销。CTA 绝不是“我们约个电话”，会议本就已经在开了。
• 给客户的问题：3 个直接问题——什么有效、什么让你烦、你会停掉什么。

BOARD 模式结构

• 季度护照：周期、活跃渠道、执行方。
• 核心要点：如果只读一页，就读这页。
• 漏斗计划与实际：从首次触达到成交金额，带区间（RAG 阈值事先约定）。
• 按渠道：放大、保持或停止。每个结论都要说明剩余名单规模或预算：名单耗尽（list burnout）是转化率下滑的主因，而混合数字会掩盖它。
• 瓶颈：售前、销售、交付天花板（小时 × 费率）。最多三个。
• 下一季度预测，用两种方式构建：自上而下（目标 ÷ 单笔金额 ÷ 赢单率）和自下而上（产能 × 转化率）。两者之差就是议程。若已安装，revenue-forecast-writer（gtm-strategy-skills 包）负责构建本节。
• 缩小差距的杠杆：3 到 5 个，每个含预期效果与成本。
• 请董事会做的决定：1 到 3 个，每个带截止日期。没有决策请求的董事会材料只是一份报告。

流程

1. 询问模式、账户或公司、季度。确认计划存放在哪里。
2. 拉取输入。若 client-health-check 与 upsell-mapper 的输出过期或缺失，先运行它们。
3. 先填计划与实际；表格决定叙事。不要在表格之前写叙事。
4. 起草各章节。最后写“核心要点”。
5. 若已安装 anticopywriting-ai（gtm-skills 包），将行文过一遍它。
6. 将回顾保存在客户结果所在处：若有 Notion 连接器，放在客户页面下的 Notion 页面；否则保存为 markdown 文件 <client>-qbr-<YYYY-Qn>.md。仅当受众是董事会或满屋人时才做演示稿：把完成的叙事交给 slide-deck-builder（sales-engine-skills 包，若已安装）。绝不要先在幻灯片里起草。
7. 若已安装 meeting-prep（sales-engine-skills 包），附上其会前模块供主持会议者使用。

会后（最容易被跳过的部分）

• 24 小时内发送摘要（你起草；账户负责人发送）。
• 承诺录入 CRM 和跟踪工具，带负责人与日期。
• 获批的扩展候选交给 proposal-generator（sales-engine-skills 包，若已安装）。值得公开传播的成果交给 case-study-writer（account-management-skills 包，若已安装），并征得客户许可。
• 下次 QBR 日期在这次会上预约。

节奏

顶级账户每季度一次。其他账户每半年一次，或在任何交付阶段结束后进行。一份列出未来 12 个月所有顶级账户 QBR 日期的日历，是完成标准的一部分。

方法来源

方法由 Victor Shulga 提出（victorshulga.com）。