---
name: case-study-writer
description: 根據客戶訪談筆記或通話逐字稿撰寫客戶案例：情況、問題、為什麼選擇你們、帶數字的改變，以及一句客戶引言，並列出發布前客戶必須核可的每個項目。適用於有人提供客戶訪談筆記、成功故事或推薦通話內容，要求寫成客戶案例、客戶故事、成功案例或 case study 時。
---

# 客戶案例

客戶案例能帶來成交，是因為潛在客戶在其中看到自己的處境，以及一個可信的數字。從客戶的角度、用客戶的話來寫，客戶沒核可的說法絕不發布。在美國，FTC 的《Endorsement Guides》把客戶引言視為代言：引言「必須反映代言者的真實意見」，而如果該客戶的成果不是一般客戶通常能得到的，頁面必須說明一般的成果是什麼。台灣、香港的規定可能不同 [待確認：當地法規]。

## 適用情境

- 客戶訪談或成功案例通話結束後，要把筆記整理成可發布的故事。
- 業務需要針對特定客群或常見疑慮的佐證。
- 客戶寄來滿意的信或評論，值得寫成完整故事。
- 不適用於跨多位客戶的匿名資料彙整：那是報告，不是客戶案例。

## 需要準備

- 與客戶的訪談筆記或逐字稿。沒有就先索取；只靠內部筆記寫出來的案例讀起來像廣告。
- 客戶的姓名、職稱、公司、規模與產業。缺少的項目寫成「[待確認：……]」。
- 導入前後的數字（時間、成本、營收、錯誤）。沒有就問一次；仍沒有就用具體但非數字的方式描述改變，並在核可清單中標註「無指標」。
- 選填：這個故事要回應的客群或疑慮。

## 步驟

1. **用客戶的話找出導入前的狀態。** 他們以前怎麼做、付出了什麼代價，以及決定改變的那一刻。引用他們的說法；「我們被試算表淹沒了」勝過「他們面臨效率不彰的問題」。
2. **寫出為什麼是他們、為什麼選你們。** 他們還考慮過哪些方案（包括什麼都不做），以及選擇你們的 1 到 2 個理由。正在比較方案的潛在客戶最需要這一段。
3. **整理數字。** 每個導入前後的指標都附上期間：「3 個月內，從每週 6 小時降到 40 分鐘」。數字如果來自你們團隊而非客戶，標註為需要核可。數字絕不往上湊整，也絕不用一個月推算一整年。如果這位客戶的成果特別好，加一行說明一般的成果，或標註「[待確認：一般成果]」（FTC《Endorsement Guides》）。
4. **挑 1 到 2 句引言。** 選講成果或感受的引言，不要功能清單。只要意思不變，可以小幅修正文法；修改過的引言要標註為需要核可。不要捏造或合併引言：代言不能扭曲代言者的實際經驗。
5. **用成果寫標題。** 「[客戶]把[X]減少了[數字]」或「[客戶]如何[成果]」。沒有數字時，用具體的改變。
6. **為快速瀏覽的讀者安排結構。** 成果放最前面（NN/g 的倒金字塔）：最上方放 3 行摘要框（客戶、挑戰、成果），接著依序是：情況、問題、為什麼選擇[公司]、改變了什麼、下一步。此技能的預設長度：訪談內容足夠時寫 1,000 到 1,800 字；筆記很少時寧可寫短，也不要灌水。產品功能只在它帶來成果的地方出現。
7. **列出需要核可的項目。** 每一句引言、每個數字、客戶的名稱與標誌、提到的任何競爭對手，以及任何可能是機密的資訊（營收、人數、使用的工具）。如果客戶因參與而得到任何回饋（折扣、點數、免費一個月），或事先知道可能會得到，頁面上就要揭露（FTC《Endorsement Guides》）。發布前，所有項目都要經客戶同意。

## 輸出格式

```markdown
# [含成果的標題]

| 客戶 | [公司、產業、規模] |
|---|---|
| 挑戰 | [一行] |
| 成果 | [一行，含數字] |

## 情況
[2–3 段短文]

## 問題
[付出了什麼代價，用客戶的話]

## 為什麼選擇[公司]
[考慮過的其他方案、1–2 個理由]

## 改變了什麼
- [指標：導入前 → 導入後，期間]

> 「[引言]」— [姓名，職稱，公司]

## 下一步
[1 段短文]

---
## 發布前請[客戶窗口]核可
- [ ] 引言：「[...]」[已修改／原文]
- [ ] 數字：[...] — [來源：客戶／我們的資料]
- [ ] 姓名、職稱與標誌的使用
- [ ] 因參與而提供的回饋：[無／內容，已在頁面揭露]
- [ ] [機密或競爭對手相關項目]
```

## 範例

**輸入：** 訪談綠程快遞（60 名司機，區域配送）營運主管陳志豪。導入前：派車靠白板和群組聊天，「每天早上都一團亂，光是分配路線就要 2 小時」。試過一套大型車隊管理系統，太複雜。選擇 Routelyn，因為司機本來就看得懂它的手機 App。2 個月後：分配路線只要 20 分鐘；漏送件數從每週約 30 件降到 8 件（來自 Routelyn 的儀表板）。引言：「司機不再早上 7 點打電話給我了。」

**輸出：**

```markdown
# 綠程快遞把早上的派車時間從 2 小時縮短到 20 分鐘

| 客戶 | 綠程快遞，區域配送，60 名司機 |
|---|---|
| 挑戰 | 用白板和群組聊天手動分配路線 |
| 成果 | 派車只要 20 分鐘；漏送件數從每週約 30 件降到 8 件 |

## 情況
綠程快遞在區域內調度 60 名司機。導入 Routelyn 之前，每條路線都是在白板上排好，再用群組聊天發送出去。

## 問題
「每天早上都一團亂。」營運主管陳志豪說。光是分配路線就要花 2 小時。

## 為什麼選擇 Routelyn
綠程快遞先試了一套完整的車隊管理系統，發現太複雜。最後選擇 Routelyn，因為司機本來就看得懂它的手機 App。

## 改變了什麼
- 分配路線：每天早上 2 小時 → 20 分鐘，導入 2 個月後
- 漏送件數：每週約 30 件 → 8 件，導入 2 個月後

> 「司機不再早上 7 點打電話給我了。」— 陳志豪，營運主管，綠程快遞

## 下一步
[待確認：綠程快遞接下來的計畫，訪談中未提到]

---
## 發布前請陳志豪核可
- [ ] 引言：「每天早上都一團亂」（原文）
- [ ] 引言：「司機不再早上 7 點打電話給我了。」（原文）
- [ ] 數字：2 小時 → 20 分鐘 — 來源：客戶
- [ ] 數字：每週漏送約 30 件 → 8 件 — 來源：Routelyn 儀表板
- [ ] 姓名、職稱與標誌的使用
- [ ] 因參與而提供的回饋：訪談中未提到 [待確認：無]
- [ ] 提到先試過一套車隊管理系統（未具名）
- [ ] [待確認：一般成果] — 這些成果對 Routelyn 的客戶來說是一般水準嗎？
```

## 寄出前檢查

- [ ] 標題寫出成果，有數字就放數字。
- [ ] 每個指標都有導入前、導入後與期間。
- [ ] 每句引言都出現在筆記中；修改過的已標註。
- [ ] 核可清單涵蓋每句引言、每個數字、名稱與標誌。
- [ ] 故事中沒有輸入以外的內容；缺漏處寫成「[待確認：……]」。
- [ ] 成果特別好時，已說明一般成果，或標註「[待確認：一般成果]」。

## 常見錯誤

- 寫成功能導覽。功能只在它帶來成果的地方出現。
- 省略「為什麼選我們」。正在比較廠商的潛在客戶會先讀這一段。
- 沒經過客戶同意，就發布來自自家儀表板的數字。