---
name: decision-memo
description: 用 Amazon 的敘事風格寫一份簡短的決策備忘錄：先寫建議，再寫背景、2 到 4 個選項和各自的取捨、風險和因應方式，最後寫出請求、決策者和期限，全部用完整句子，而不是簡報條列。適用於需要創辦人、高階主管或團隊做決定，而要寫決策備忘錄、一頁式提案（one-pager）、提案書、建議文件、用敘事文取代簡報，或說「幫我把 X 的理由講清楚」時。
---

# 決策備忘錄

決策備忘錄要換來的是一個決定，不是一場討論。Amazon 不用投影片簡報：他們寫有敘事結構的六頁備忘錄，在會議一開始安靜閱讀（Bezos，2017 年致股東信）。我們的看法是：完整的句子會暴露條列式藏住的模糊思考。這個技能的備忘錄很短（1 到 2 頁），建議放在第一段，結尾寫出具名的決策者和日期。

## 適用情境

- 某個選擇需要別人核准：招募、選供應商、調整價格、組織調整、自建還是外購。
- 會議一再結束卻沒有結論。
- 主管會議檢討時，用來取代簡報。
- 不適用於記錄已經做出的決定（請用 decision-record），也不適用於長篇的策略文件。

## 需要準備

- 要做的決定，寫成一個問題。
- 誰來決定、什麼時候之前。不知道時問一次；否則寫「[決策者：待確認]」。
- 考慮過的選項，以及每個選項的事實：成本、時間、效果。絕不編造數字；缺口標成「[待確認：……]」。
- 你的建議。如果撰寫者還沒有建議，就用中立的方式寫，並在第一段寫明「目前尚無建議」。

## 步驟

1. **先寫問題和請求。** 一段：需要做的決定、建議、決策者、期限，以及在期限前不做決定的代價。讀者只看到這裡也能行動。
2. **只給必要的背景。** 1 到 2 段：什麼改變了、為什麼是現在、我們知道什麼（附數字和來源）。刪掉決策者已經知道的來龍去脈。
3. **列出 2 到 4 個真正可行的選項。** 「維持現狀」可行時也要列進去。每個選項寫：是什麼、成本、時間、能帶來什麼、要放棄什麼。數字用比較表，推理用句子。
4. **把取捨講明白。** 用一段說明為什麼建議的選項勝出，並寫出選它要放棄什麼。如果這個選擇可以反悔，就寫出來：Bezos 在 2016 年的致股東信中把這類決定稱為「雙向門」（two-way doors），可以用輕量的流程處理。
5. **寫出風險。** 建議方案的前 2 到 3 個風險，每個附上因應方式和早期警訊。
6. **以請求收尾。** 明確寫出你需要什麼：核准方案 B、一筆預算、一個人力。寫出決策者、期限，以及獲准後的第一步。
7. **用句子寫，然後刪減。** 除了選項表之外，用段落而不是簡報式條列。目標是 2 頁以內。刪掉用來取代資料的形容詞（「顯著」「巨大」）。

## 輸出格式

```markdown
# [以問句寫出的決定]
**決策者：** [姓名] · **決定期限：** [日期] · **撰寫者：** [姓名] · **日期：** [日期]

## 建議
[一段：我們建議 X，因為 Y。如果 [日期] 前沒有決定，[後果]。]

## 背景
[1–2 段：什麼改變了、為什麼是現在、關鍵事實和來源]

## 選項
| | A：[名稱] | B：[名稱] | C：維持現狀 |
|---|---|---|---|
| 成本 | | | |
| 時間 | | | |
| 能帶來 | | | |
| 要放棄 | | | |

[每個選項一段，說明推理。]

## 為什麼選 [建議的選項]
[用平實的句子寫出取捨，包括要放棄什麼。可否反悔。]

## 風險
| 風險 | 因應方式 | 早期警訊 |
|---|---|---|

## 請求
請在 [日期] 前 [核准 X／預算／人力]。如果同意，第一步是由 [負責人] 在 [日期] [動作]。
```

## 範例

**輸入：** 「今天是 2026 年 11月10日（週二）。需要執行長（王思涵）在週五前決定，客服要不要從電子郵件改用 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 頁以內。

## 常見錯誤

- 賣關子：背景寫一整頁，建議放最後。建議要放在最前面。
- 稻草人式的選項清單，只有一個選擇說得通。決策者看得出來，信任就會下降。
- 隱藏建議方案的缺點。寫出要放棄什麼；那正是決策者會問的。