chore: import zh skill board-deck-builder
This commit is contained in:
wehub-skill-sync
@@ -0,0 +1,9 @@
|
||||
# WeHub 来源说明
|
||||
|
||||
- Skill 名称：`board-deck-builder`
|
||||
- 中文类目：Open Design 演示模板批次1
|
||||
- 上游仓库：`alirezarezvani__claude-skills`
|
||||
- 上游路径：`.gemini/skills/board-deck-builder/SKILL.md`
|
||||
- 上游链接：https://github.com/alirezarezvani/claude-skills/blob/HEAD/.gemini/skills/board-deck-builder/SKILL.md
|
||||
- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理
|
||||
- 原作者、版权和许可证信息以上游仓库为准
|
||||
@@ -0,0 +1,183 @@
|
||||
---
|
||||
name: "board-deck-builder"
|
||||
description: "整合所有 C 级高管视角，构建全面的董事会和投资人更新演示文稿。适用于准备董事会会议、投资人更新、季度业务回顾或融资叙事。涵盖结构、叙事框架、坏消息传达及常见错误。"
|
||||
license: MIT
|
||||
metadata:
|
||||
version: 1.0.0
|
||||
author: Alireza Rezvani
|
||||
category: c-level
|
||||
domain: board-governance
|
||||
updated: 2026-03-05
|
||||
frameworks: deck-frameworks, board-deck-template
|
||||
---
|
||||
|
||||
# Board Deck Builder（董事会演示文稿构建器）
|
||||
|
||||
构建能讲述故事的董事会演示文稿——而非仅仅展示数据。每个板块都有负责人、一条叙事线索和一个"所以呢"。
|
||||
|
||||
## 关键词
|
||||
董事会演示文稿、投资人更新、董事会会议、董事会材料包、投资者关系、季度回顾、董事会汇报、融资演示文稿、投资人演示文稿、董事会叙事、QBR、季度业务回顾
|
||||
|
||||
## 快速开始
|
||||
|
||||
```
|
||||
/board-deck [quarterly|monthly|fundraising] [stage: seed|seriesA|seriesB]
|
||||
```
|
||||
|
||||
提供可用的指标。构建器会用显式占位符填补空白——绝不编造数字。
|
||||
|
||||
## 演示文稿结构（标准顺序）
|
||||
|
||||
每个板块遵循：**标题 → 数据 → 叙事 → 请求/下一步**
|
||||
|
||||
### 1. 执行摘要（CEO）
|
||||
**三句话，不能再多。**
|
||||
- 第一句：业务现状（我们在哪里）
|
||||
- 第二句：本期内发生的最大事件
|
||||
- 第三句：下季度我们要去哪里
|
||||
|
||||
*错误示范：* "我们本季度表现不错，各方面都取得了很大进展。"
|
||||
*正确示范：* "Q3 结束时我们的 ARR 达到 240 万美元（环比增长 22%），签下了最大的一笔企业合同，并以 14 个月的现金流跑道进入 Q4。向中端市场战略转型正在奏效——ACV 增长 40%，销售周期缩短 3 周。Q4 的优先事项：完成 300 万美元的 A 轮融资，ARR 达到 280 万美元。"
|
||||
|
||||
### 2. 关键指标看板（COO）
|
||||
**最多 6–8 个指标。使用表格。**
|
||||
|
||||
| 指标 | 本期 | 上期 | 目标 | 状态 |
|
||||
|--------|-------------|-------------|--------|--------|
|
||||
| ARR | $2.4M | $1.97M | $2.3M | ✅ |
|
||||
| 月度增长率 | 8.1% | 7.2% | 7.5% | ✅ |
|
||||
| 烧钱倍数 | 1.8x | 2.1x | <2x | ✅ |
|
||||
| NRR | 112% | 108% | >110% | ✅ |
|
||||
| CAC 回收期 | 11 个月 | 14 个月 | <12 个月 | ✅ |
|
||||
| 员工人数 | 24 | 21 | 25 | 🟡 |
|
||||
|
||||
挑选董事会实际关注的指标。替换掉任何他们表示不关心的内容。
|
||||
|
||||
### 3. 财务更新（CFO）
|
||||
- 损益表概要：收入、销售成本、毛利率、运营支出、净烧钱额
|
||||
- 现金状况及跑道（月数）
|
||||
- 烧钱倍数趋势（三个季度视图）
|
||||
- 与计划的偏差（哪些不同及原因）
|
||||
- 下季度预测更新
|
||||
|
||||
**每个偏差写一句话。** 董事会讨厌只说"收入低于目标"却不给解释。要说明原因。
|
||||
|
||||
### 4. 收入与管线（CRO）
|
||||
- ARR 瀑布图：期初 → 新增 → 扩展 → 流失 → 期末
|
||||
- NRR 和客户流失率
|
||||
- 按阶段划分的管线（以金额计，而非仅数量）
|
||||
- 预测：下季度含置信度
|
||||
- 前三大交易：名称/金额/预计关闭日期/风险
|
||||
|
||||
**预测必须附有置信度。** "我们预计收入 280 万美元"太弱。"高置信度 260 万美元，若两笔后期交易关闭，上行空间至 290 万美元"才是有用的信息。
|
||||
|
||||
### 5. 产品更新（CPO）
|
||||
- 本季度已发布：3–5 条要点，每项说明对用户的影响
|
||||
- 下季度计划发布：3–5 条要点，含目标日期
|
||||
- PMF 信号：NPS 趋势、DAU/MAU 比率、功能采用率
|
||||
- 客户研究中的一项关键发现
|
||||
|
||||
**不要列功能清单。** 只写有用户影响证据的功能。
|
||||
|
||||
### 6. 增长与市场（CMO）
|
||||
- 按渠道划分的 CAC（表格）
|
||||
- 各渠道对管线的贡献（金额）
|
||||
- 与阶段相关的品牌/知名度指标（流量、声量占比）
|
||||
- 什么在起作用、什么正在削减、什么正在测试
|
||||
|
||||
### 7. 工程与技术（CTO）
|
||||
- 交付速度趋势（最近四个季度）
|
||||
- 技术债务比率及应对计划
|
||||
- 基础设施：正常运行时间、事故、成本趋势
|
||||
- 安全状况（一句话，如有待处理事项请标注）
|
||||
|
||||
**除非有重大问题，否则保持简短。** 董事会不需要知道冲刺细节。
|
||||
|
||||
### 8. 团队与人员（CHRO）
|
||||
- 员工人数：实际 vs 计划
|
||||
- 招聘：已发 Offer、人才库、招聘周期趋势
|
||||
- 离职率：可惜离职 vs 非可惜离职
|
||||
- 敬业度：上次调查得分及趋势
|
||||
- 本季度关键招聘及关键空缺岗位
|
||||
|
||||
### 9. 风险与安全（CISO）
|
||||
- 安全状况：关键控制项状态
|
||||
- 合规：进行中的认证及截止日期
|
||||
- 本季度事故（如有）：影响、解决、预防
|
||||
- 前三大风险及缓解措施状态
|
||||
|
||||
### 10. 战略展望（CEO）
|
||||
- 下季度优先事项：3–5 项，按优先级排序
|
||||
- 需要董事会做出的关键决策
|
||||
- 请求事项：预算、引荐、建议、投票
|
||||
|
||||
**"请求事项"页面最重要。** 要具体。"我们希望获得 3 次向 B 轮公司 CFO 的 warm introduction"远好于"任何帮助都感激不尽"。
|
||||
|
||||
### 11. 附录
|
||||
- 详细的财务模型
|
||||
- 完整的管线数据
|
||||
- 群组留存率图表
|
||||
- 客户案例研究
|
||||
- 详细的员工人数分解
|
||||
|
||||
---
|
||||
|
||||
## 叙事框架
|
||||
|
||||
董事会每季度要看 10 多份演示文稿。你的那份需要一条贯穿始终的主线。
|
||||
|
||||
**四幕结构：**
|
||||
1. **我们曾说过要达成的目标**（上季度的目标）
|
||||
2. **我们实际达成的结果**（诚实的评估）
|
||||
3. **差距存在的原因**（每个偏差一个原因，不是借口）
|
||||
4. **我们正在采取的措施**（具体且有日期的行动）
|
||||
|
||||
这套框架既适用于好消息也适用于坏消息。它的可信之处在于承认现实。
|
||||
|
||||
**开篇框架：** 从最重要的一件事开始——董事会应该在第 3 页而非第 30 页就知道核心信息。
|
||||
|
||||
---
|
||||
|
||||
## 传达坏消息
|
||||
|
||||
永远不要隐瞒。董事会最终总会知道。越晚被发现，后果越严重。
|
||||
|
||||
**框架：**
|
||||
1. **直截了当地陈述**——"我们 Q3 的 ARR 目标差了 30 万美元（缺口 12%）"
|
||||
2. **承认原因**——"主要原因是企业客户群的销售周期超出预期"
|
||||
3. **展示你理解问题所在**——"我们分析了 8 个流失/停滞的交易；模式是 X"
|
||||
4. **提出解决方案**——"我们已做出三项调整：[具体且有日期的调整]"
|
||||
5. **更新预测**——"Q4 修订目标为 260 万美元；以下是自下而上的构建过程"
|
||||
|
||||
**哪些不该做：**
|
||||
- 不要先用好消息铺垫来缓和坏消息——董事会会注意到并质疑你的表述方式
|
||||
- 不要只解释而不担责——"市场环境"不是原因，而是背景
|
||||
- 不要提出没有数据支撑的解决方案
|
||||
- 不要展示修订后的预测却不说明你的假设条件
|
||||
|
||||
---
|
||||
|
||||
## 董事会演示文稿常见错误
|
||||
|
||||
| 错误 | 修正方法 |
|
||||
|---------|-----|
|
||||
| 页面过多（超过 25 页） | 果断删减——如果你不能在会上口头解释清楚，那这页就是多余的 |
|
||||
| 指标没有目标值 | 每个指标都需要目标值和状态 |
|
||||
| 没有叙事 | 只有数据没有故事，会迫使董事会自行得出结论 |
|
||||
| 隐瞒坏消息 | 放在最前面、承认、解决 |
|
||||
| 请求含糊不清 | 请求必须具体、可操作、落实到人 |
|
||||
| 没有偏差解释 | 每个与目标的差距都需要一句话说明原因 |
|
||||
| 附录过时 | 附录只有在内容是最新的时候才有用 |
|
||||
| 为读者而非会议现场设计 | 演示文稿是用来口头呈现的——必须适合说出来 |
|
||||
|
||||
---
|
||||
|
||||
## 节奏说明
|
||||
|
||||
**季度（标准）：** 完整演示文稿，所有板块，20–30 页。提前 48 小时发送。
|
||||
**月度（适用于早期阶段）：** 精简版——指标看板、财务数据、管线、主要风险。8–12 页。
|
||||
**融资：** 以市场/愿景开场，以请求事项收尾。参见 `references/deck-frameworks.md` 中的 Sequoia 格式。
|
||||
|
||||
## 参考资料
|
||||
- `references/deck-frameworks.md`——SaaS 董事会材料包格式、Sequoia 结构、投资人定制
|
||||
- `templates/board-deck-template.md`——完整董事会演示文稿的填空模板
|
||||
Reference in New Issue
Block a user