---
name: decision-memo
description: 按亚马逊叙事体写一份简短的决策备忘录：先给建议，再写背景、2 到 4 个方案及取舍、风险与应对，最后写明决策人和截止日期的请求——用完整的句子，而不是幻灯片要点。需要创始人、高管或团队拍板，并要一份决策备忘录、一页纸（one-pager）、提案、建议书、用叙事代替 PPT，或说“帮我把 X 的理由讲清楚”时使用。
---

# 决策备忘录

决策备忘录要换来的是决定，不是讨论。亚马逊不用幻灯片汇报：它写叙事结构的六页备忘录，会议开始时大家先安静地读（贝佐斯，2017 年致股东信）。这个技能的看法是：完整的句子会暴露要点列表能藏住的含糊思考。这里的备忘录更短（1 到 2 页），第一段就给建议，结尾写明决策人和日期。

## 适用场景

- 某个选择需要别人批准：招人、选供应商、调价、组织调整、自建还是采购。
- 会议一再开完却没有结论。
- 管理层评审时用来替代 PPT。
- 记录已经做出的决定不适用（用 decision-record），长篇战略文档也不适用。

## 需要准备

- 要做的决定，写成一个问题。
- 谁来决定、什么时候之前。不知道就问一次；问不到就写“[决策人：待确认]”。
- 考虑过的方案，以及每个方案的事实：成本、时间、效果。数字绝不编造；缺的标“[待确认：……]”。
- 你的建议。如果作者还没有建议，就中立地写，并在第一段说明“暂无建议”。

## 步骤

1. **先写问题和请求。** 一段话：需要什么决定、建议是什么、决策人、截止日期，以及到期还不决定的代价。读者读到这里就停，也能采取行动。
2. **只给必要的背景。** 1 到 2 段：发生了什么变化、为什么是现在、我们知道什么（附数字及来源）。决策人已经知道的来龙去脉删掉。
3. **列出 2 到 4 个真实的方案。** “维持现状”可行时也列进去。每个方案写：是什么、成本、时间、能带来什么、要放弃什么。数字用对比表，推理用句子。
4. **把取舍说清楚。** 用一段话说明推荐方案为什么胜出，并写明选它要放弃什么。如果这个决定可以撤回，就说出来：贝佐斯 2016 年的致股东信把这类决定称为“双向门”，可以用轻量的流程。
5. **写出风险。** 推荐方案最主要的 2 到 3 个风险，每个配应对措施和早期预警信号。
6. **以请求收尾。** 写清你具体需要什么：批准方案 B、一笔预算、一个人。写明决策人、截止日期，以及批准后的第一步。
7. **用句子写，然后删减。** 除方案对比表外，写成段落，不写幻灯片式要点。控制在 2 页以内。删掉代替数据的形容词（“显著”“巨大”）。

## 输出格式

```markdown
# [写成问题的决定]
**决策人：** [姓名] · **需决定日期：** [日期] · **作者：** [姓名] · **日期：** [日期]

## 建议
[一段话：我们建议 X，因为 Y。如果 [日期] 前不决定，[后果]。]

## 背景
[1–2 段：发生了什么变化、为什么是现在、关键事实及来源]

## 方案
| | A：[名称] | B：[名称] | C：维持现状 |
|---|---|---|---|
| 成本 | | | |
| 时间 | | | |
| 带来什么 | | | |
| 放弃什么 | | | |

[每个方案一段推理。]

## 为什么选 [推荐方案]
[用平实的句子写取舍，包括放弃什么。能否撤回。]

## 风险
| 风险 | 应对措施 | 早期预警信号 |
|---|---|---|

## 请求
[日期] 前 [批准 X / 预算 / 人员]。如果批准，第一步是 [负责人] 在 [日期] [行动]。
```

## 示例

**输入：** “今天是 2026 年 11月10日（周二）。需要 CEO 韩娜在周五前决定，客服要不要从邮件迁到 Zendesk。现在用共享 Gmail 收件箱，2 名客服，每月约 600 张工单，约 5% 会跟丢（客户来催才发现）。Zendesk Suite 报价：每个坐席 [待确认] 美元。另一个选择：Help Scout，便宜些，功能少些。或者不换。我倾向 Help Scout——我们用不上 Zendesk 那么复杂的东西。两种迁移都大约要 2 周。1 月是续费高峰。——刘洋”

**输出：**

```markdown
# 客服是否要从共享 Gmail 迁到专门的工单系统？
**决策人：** 韩娜 · **需决定日期：** 11月13日（周五） · **作者：** 刘洋 · **日期：** 11月10日

## 建议
我们建议把客服迁到 Help Scout。它能解决工单跟丢的问题，成本和上手工作量都比 Zendesk 低；Zendesk 的很多功能以我们的规模用不上。如果周五前决定，迁移能在 1月续费高峰前完成；晚一点开始就会撞上高峰。

## 背景
两名客服在一个共享 Gmail 收件箱里处理每月约 600 张工单。约 5% 的工单（每月 30 张左右）会跟丢，客户来催才被发现。现在看不出每张工单归谁，也看不出客户等了多久。两种工具的迁移都大约需要 2 周。

## 方案
| | A：Help Scout | B：Zendesk Suite | C：继续用 Gmail |
|---|---|---|---|
| 成本 | [待确认：报价] | 每个坐席 [待确认：报价] | 无额外费用 |
| 时间 | 约 2 周 | 约 2 周 | 无 |
| 带来什么 | 工单归属、状态、报表 [待确认：套餐功能] | 同左，另有高级分配规则和更大的应用生态 [待确认：套餐功能] | 没有新东西 |
| 放弃什么 | 暂时用不上的高级分配规则 | 更多配置和管理时间 | 每月约 30 张工单继续跟丢 |

Help Scout 覆盖了我们缺的 3 样东西：分配、状态和报表。Zendesk 多出的分配规则和自动化是为更大的团队设计的。不换在软件上不花钱，但每天还会丢大约一张工单。

## 为什么选 Help Scout
我们放弃 Zendesk 的扩展余量，换一个 2 名客服不用专人管理就能用起来的简单工具。这个决定可以撤回：如果以后 Help Scout 不够用，工单历史可以导出 [待确认：导出条款]。

## 风险
| 风险 | 应对措施 | 早期预警信号 |
|---|---|---|
| 迁移期间工单丢失 | 两个收件箱并行运行 1 周 | 客户回复旧邮件线程 |
| 客服抵触新工具 | 由客服自己定工单状态 | 第 2 周后仍在用 Gmail 回复工单 |

## 请求
请在 11月13日（周五）前批准 Help Scout 及其年费 [待确认：报价]。如果批准，刘洋在 11月16日（周一）开始试用配置。
```

## 发送前检查

- [ ] 建议、决策人和截止日期都在第一段。
- [ ] 有 2 到 4 个方案，每个都写了要放弃什么；“维持现状”可行时也列了。
- [ ] 每个数字都能在输入中找到来源，或标了“[待确认：……]”。
- [ ] 备忘录写明了这个决定能否撤回。
- [ ] 以一个具体请求和批准后的第一步结尾。
- [ ] 篇幅在 2 页以内。

## 常见错误

- 卖关子：背景写一页，建议放最后。建议要放在最前面。
- 列一堆“稻草人”方案，实际只有一个说得通。决策人看得出来，信任会下降。
- 藏起推荐方案的代价。写明要放弃什么，这正是决策人会问的。