# Service Innovation Case Study

> 本 skill MUST 用於完整的服務創新案例分析報告。MUST 觸發於使用者要求研究某品牌、App、平台 或服務,要求依課堂格式完成案例分析,指定做一份某案例風格的服務創新研究, 或要求以 PESTEL、五力、SWOT、STP、BMC、persona、服務藍圖、CJM 等一種以上 框架分析服務創新案例。 必讀子文件（依需要載入）： - `references/01-research-protocol.md` — 資料查核標準與來源驗證流程 - `references/02-analysis-chain.md` — 分析鏈完整邏輯（PESTEL→五力→SWOT→STP→BMC→Persona→藍圖→CJM） - `references/03-section-specs.md` — 各報告區段的詳細規格與品質標準 - `references/04-quality-checklist.md` — 輸出前的自我檢查清單 - `assets/report-template.md` — 空白報告模板 每次開始新案例前，MUST 先讀 `references/01-research-protocol.md` 和 `references/02-analysis-chain.md`。

- Skill: `timlai666/service-innovation-case-study` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add timlai666/service-innovation-case-study`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timlai666/service-innovation-case-study/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: TimLai666 (https://skillmd.com/u/timlai666)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/timlai666/service-innovation-case-study

---


# 服務創新案例研究 Skill

## 核心原則（必讀）

這份 skill 來自一個真實的 Doji 案例研究過程，以下是這個過程中提煉出的最重要原則：

### 原則一：所有內容必須有來源，不得自行捏造
每一個事實、數字、引言都必須來自可查核的網路資料。每次寫入報告前先查詢，查到了才寫，查不到明確說明「無公開數據」。這是整個 skill 最重要的單一規則。

### 原則二：分析鏈必須環環相扣
PESTEL → 五力 → SWOT → STP → BMC → Persona → 服務藍圖 → CJM 是一條邏輯鏈，每一步的輸出是下一步的輸入。STP 的市場區隔必須引用 PESTEL 的高優先分因素；定位必須從選定的主要策略推導；Persona 必須從 STP 的目標客群萃取；服務藍圖和 CJM 必須以 Persona 為主角。

### 原則三：PESTEL 必須有優先分，且下游分析只用高分因素
每個 PESTEL 因素都要打分（重要性 × 影響程度 × 時效性），只有優先分 ≥ 48 的因素才進入 SWOT 和 STP。低分因素明確說明不納入。

### 原則四：CJM 必須反映真實摩擦，不是品牌視角的理想化版本
情緒分數要基於真實用戶反饋（App Store 評論、媒體評測等），不是假設一切順利。服務藍圖的缺口診斷要對應 SWOT 的劣勢。

### 原則五：報告區段順序不能亂
正確順序：案例名稱 → 公司背景 → 創辦人背景 → 推出背景 → 推出時間 → 推薦原因 → 應用情境 → 創新類型/模式 → **生態系地圖** → **PESTEL** → **五力** → **SWOT** → **主要策略** → **STP** → **BMC** → **Persona** → **服務藍圖** → **CJM** → 創造效果 → 相關展示 → 目前成效 → 背後啟發 → **參考資料（最後）**

---

## 執行流程

### 階段 0：啟動前確認

讀取 `references/01-research-protocol.md`，確認：
1. 研究目標的正式名稱與官方網址
2. 是否有同名的其他公司（需要明確區分，如 doji.com vs doji.co.uk）
3. 使用者是否有提供課堂格式要求（若有，記錄下來對照）

### 階段 1：基礎資料研究（查詢 → 寫入）

按以下順序查詢，每個查詢結果立即標記來源：

**1-A 公司基本資料**
- 公司全名、成立年份、總部地點
- 創辦人姓名、職稱、前雇主背景（LinkedIn、TechCrunch、公司官網）
- 目前員工數、融資輪次與金額（Crunchbase、PitchBook、Tracxn）

**1-B 投資背景**
- 每個投資方的詳細介紹（不只是名稱）
- 投資金額、輪次、時間點
- 「如何被發現」的故事（是否有口碑傳播、介紹人、Demo Day）
- **注意**：必須查證每個投資方是否真的投資了這家公司，不能假設

**1-C 推出時間線**
- 找出所有重要節點（成立、stealth、beta、正式上線、融資宣布、功能更新、獲獎）
- 每個節點都要標來源與確切日期
- 若不同來源有衝突，以最可靠來源（TechCrunch、官方聲明）為準並說明

**1-D 推薦原因與口碑**
- 找真實的外部引言（投資人、媒體、用戶、KOL）
- 每則引言標明說話者身份、出處、日期
- 不只找正面回饋，也找批評性評論（App Store、競品評測）

**1-E 應用情境**
- 創辦人自述的使用場景（LinkedIn、訪談）
- 實際用戶的使用方式（媒體報導、社群發文）
- B2B vs B2C 的場景區分

### 階段 2：產業生態系地圖

在 PESTEL 之前完成。讀取 `references/02-analysis-chain.md` 的生態系地圖規格。

**必須涵蓋的層次：**
1. 資金層（所有投資方，含輪次與金額）
2. 技術來源層（創辦人前雇主、技術合作方）
3. 核心（公司本身）
4. 品牌合作方（內容供給、策展品牌、過往合作）
5. 電商導購目的地
6. 通路層（App Store、擴充套件、社群媒體）
7. 終端用戶層
8. 直接競爭者（同類新創，附融資金額）
9. 間接競爭者（大廠自建）
10. 監管環境（相關法規機構）

**輸出格式**：Mermaid 程式碼（可嵌入 Markdown，可在支援 Mermaid 的渲染器中顯示）

**品質標準**：每個節點都要有來源依據。不確定的關係用虛線箭頭，確認的用實線箭頭。

### 階段 3：PESTEL 分析

讀取 `references/02-analysis-chain.md` 的 PESTEL 規格，並參照 `pestel-analysis` skill。

**評分系統（三軸評分）：**
- 重要性（1-5）：對公司的戰略重要程度
- 影響程度（1-5）：實際衝擊的深度
- 時效性（1-3）：近期至長期
- **優先分 = 重要性 × 影響程度 × 時效性**

**有效因素門檻：優先分 ≥ 12**（一般來說 ≥ 48 才進入 SWOT，但至少 ≥ 12 才列為有效因素）

每個有效因素必須包含：
- 因素編號（如 T-01、L-01）
- 詳細描述（含具體數字與事件）
- 來源依據（直接引用原始來源）
- 影響方向（機會傾向 / 威脅傾向 / 中性）
- 各維度評分與優先分

**輸出移交包**：PESTEL 結束時輸出「PESTEL → SWOT 移交包」，列出機會池和威脅池（依優先分排序）。

### 階段 4：五力分析

讀取 `references/02-analysis-chain.md` 的五力規格。

五力分析必須：
- 列出所有有名字的競爭者（直接 + 間接），不能只說「競爭強度高」
- 替代品威脅要分析「為何這些替代品不能完全取代本產品」的理由
- 買方/供應商議價能力要說明對商業模式的具體影響
- 每個力量給出判斷等級（低 / 中低 / 中 / 中高 / 高）

### 階段 5：SWOT 分析

**強制規則：**
- S、W、O、T 各剛好 3 項（S1-S3、W1-W3、O1-O3、T1-T3）
- O 和 T 必須對應 PESTEL 移交包的因素，並標 PESTEL 編號與優先分
- 每項都要有來源
- S/W 來自公司自身（有來源的事實），O/T 來自 PESTEL 高分因素

### 階段 6：SWOT 碰撞策略

**強制規則：**
- 生成 SO × 2、WO × 2、ST × 2、WT × 2，共 8 個策略
- 每個策略標示組合代號（如 [S2×T1]）
- 從 8 個策略中選出 1 個主要策略
- **主要策略的選擇必須有有依據的理由**：
  - 引用 PESTEL 優先分（選最高分威脅/機會）
  - 引用創辦人或媒體的真實話語
  - 說明「為何這個策略比其他策略更強」

### 階段 7：STP 分析（三軌整合）

**強制規則：**
- **只引用 PESTEL 優先分 ≥ 48 的因素**，低分因素明確說明不納入
- S（區隔）：PESTEL 高分因素 + 五力結構共同決定區隔維度
- T（目標）：做三軌聯合篩選矩陣（PESTEL + 五力 + SWOT 三欄並列）
- P（定位）：**只從主要策略推導**，不能同時用多個沒有選中的策略

**市場區隔的維度設計邏輯：**
- 每個維度都要有 PESTEL 因素作為依據
- 維度必須能清楚切割出不同的用戶群
- 交叉出的區隔（如 AX/AY/BX/BY）要有明確的排除或選擇依據

### 階段 8：商業模式圖（BMC）

讀取 `references/02-analysis-chain.md` 的 BMC 規格，並參照 `business-model-architect` skill。

**震央選擇（Epicenter Selection）——必須從分析推導：**

| 震央類型 | 選擇條件 |
|---------|---------|
| 資源導向 | 核心優勢 = 稀缺資源/能力；買方切換成本低（不適合顧客導向）；商業化路徑未確立 |
| 顧客導向 | 有清楚的未被滿足需求；切換成本高；顧客關係是護城河 |
| 財務導向 | 收益模式清晰；成本結構是競爭優勢；規模效益明確 |
| 產品導向 | 產品本身是差異化核心；技術/IP 保護強 |

震央選擇表格必須包含：每個依據的來源（SWOT/五力/STP）、指向結論。

**九格設計順序**（從震央格向外推）：關鍵資源 → 價值主張 → 目標客群 → 通路 → 顧客關係 → 關鍵活動 → 關鍵合作夥伴 → 收益流 → 成本結構

**暫緩要素**：若商業化路徑未確立或財務資料未公開，相關格子標 ⏸ 並說明暫緩原因。

### 階段 9：顧客 Persona

**強制規則：每個屬性都必須有來源依據**

Persona 不是虛構人物，而是從有來源事實萃取出的複合樣本：
- 職業/年齡/地點：從實際用戶報導或beta用戶描述推導
- 品味偏好：從公司的策展品牌或合作對象推導
- 行為特徵：從具名用戶的真實使用方式引用
- 痛點與動力：從SWOT的劣勢和機會，加上用戶反饋

**格式**：製作屬性表格，每列 = 一個屬性、內容描述、來源依據

### 階段 10：服務藍圖

讀取 `references/02-analysis-chain.md` 的服務藍圖規格，並參照 `ecosystem-map-and-blueprint` skill。

**必須呈現的六層（縱軸）：**
1. 實體支援（顧客能看到的實體物件）
2. 用戶行動
3. — 互動線 —
4. 前台（科技層 + 真人層）
5. — 可視線 —
6. 後台
7. — 內部互動線 —
8. 支援系統

**橫軸（流程階段）**：根據服務特性設計 4-6 個階段（如：發現→建立→使用→分享→購買）

**流程缺口診斷（⚡）**：
- 每個缺口標嚴重程度（最高 / 高 / 中）
- 每個缺口對應 SWOT 的哪個劣勢項目
- 每個缺口有具體的改善建議方向

### 階段 11：顧客旅程地圖（CJM）

讀取 `references/02-analysis-chain.md` 的 CJM 規格，並參照 `customer-journey-mapper` skill。

**強制規則：**
- 必須以 Persona 為主角（不是抽象用戶）
- 情緒分數必須基於真實用戶反饋，不是假設
- 旅程中必須包含真實的摩擦點，不是品牌視角的理想化版本
- Aha Moment 若有前提條件必須說明，不能無條件標注

**必要欄位**：動機、行動、情緒曲線（附分數）、接觸點、感受/關鍵時刻、科技服務、行銷方法、目標

**情緒分數標準**（1-5 分）：
- 1：極度負面（放棄使用）
- 2：負面或明顯不滿
- 3：中性（可接受但未被打動）
- 4：正面（有好感）
- 5：強烈正面（Aha Moment）

**情緒分數明細表**：每個階段列出加分原因與減分原因，每個原因都要有來源。

### 階段 12：創造效果 / 解決問題

**三層分析（不能只寫正面效果）：**
1. 宣稱解決的問題（創辦人/品牌自述）
2. 目前實際已解決的程度（✅/⚠️/❌，有來源）
3. 尚未解決的缺口（技術 / 商業 / 體驗層面）

### 階段 13：目前成效 / 獲獎情況 / 外部討論

**強制規則：只呈現可查核的數字**
- 若公司未公開用戶數、MAU、營收，明確說明「無可查核的公開來源」
- 媒體報導做成時間軸表格（時間、媒體、事件）
- 關鍵聲音正反並列，批評性評論不能省略

### 階段 14：背後代表的啟發與意義

**強制規則：每個啟發都必須從上方的具體分析推導**
- 標明依據來源（如「PESTEL T-01 優先分 75」、「SWOT ST1 策略」、「CJM 情緒曲線」）
- 不是泛泛的創業感言，而是從這個案例的具體分析結論提煉出的普遍規律

---

## 品質管制規則

完成每個區段後，在進入下一區段前執行自我檢查：

**每個區段通用檢查：**
- [ ] 所有事實都有來源標注（在當下或區段末尾）
- [ ] 沒有任何「可能」、「應該」、「大概」等推測性語言（除非明確說明是推測）
- [ ] 沒有捏造數字（特別是用戶數、成長率、市佔率）

**分析鏈一致性檢查：**
- [ ] STP 的 S 只用了優先分 ≥ 48 的 PESTEL 因素
- [ ] STP 的 T 有三軌聯合篩選（PESTEL + 五力 + SWOT）
- [ ] STP 的 P 只從主要策略推導，沒有混入其他策略
- [ ] BMC 的震央選擇有從 SWOT + 五力推導的表格依據
- [ ] Persona 的每個屬性都有來源
- [ ] CJM 的情緒分數有真實用戶反饋支撐
- [ ] 背後啟發的每一點都追溯到具體的分析依據

**報告順序檢查（最終輸出前）：**
- [ ] 生態系地圖在 PESTEL 之前
- [ ] PESTEL 在五力之前
- [ ] 商業模式圖在 Persona 之前
- [ ] Persona 在服務藍圖之前
- [ ] 服務藍圖在 CJM 之前
- [ ] 創造效果/解決問題在 CJM 之後
- [ ] 參考資料是最後一個區段
- [ ] 參考資料是獨立的 `## 參考資料` 區段，有清楚編號，不是散落在各區段底部

---

## 常見錯誤（來自 Doji 案例的教訓）

**錯誤一：STP 的定位用了多個策略而非主要策略**
症狀：定位區段同時提到 ST1、ST2、WT2 等多個策略，顯示沒有從主要策略聚焦推導。
修正：定位只從選定的主要策略推導。若主要策略是 ST1，定位就只從 S2 和 T1 的張力推導出差異化位置。

**錯誤二：Persona 屬性沒有來源，是主觀創造的**
症狀：Persona 的職業、年齡、地點等屬性是「感覺合理」的設定，沒有連接到真實數據。
修正：每個屬性都要追溯到有來源的事實（beta 用戶報導、創辦人自述、實際用戶案例）。

**錯誤三：CJM 是理想化的品牌視角，沒有真實摩擦**
症狀：情緒曲線一路上升，Aha Moment 無條件出現，沒有真實的挫折點。
修正：查詢 App Store 評論、競品評測、媒體真實測試記錄，把真實摩擦寫進 CJM。

**錯誤四：Avatar 是否真的還原身材 vs 只是換臉**
這個問題在 Doji 案例中被明確指出：diffusion model 生成的 avatar 體型偏瘦偏高，不是精確身材還原。每次分析「虛擬試衣」類服務時，都要主動查詢「是否真的按用戶體型建模，還是視覺生成」。

**錯誤五：參考資料散落各處或有重複編號**
症狀：編號重複（如兩個「10」）、沒有統一的 `## 參考資料` 區段、部分來源只在區段底部的 `> 來源：` 標注中出現。
修正：最終輸出前，把所有來源整合成一個帶 `## 參考資料` 標題的獨立區段，有序編號，分類整理，放在報告最末尾。

**錯誤六：PESTEL 低分因素進入了 STP**
症狀：STP 的市場區隔引用了優先分只有 18 或 24 的 PESTEL 因素，與高分因素並列，沒有說明篩選邏輯。
修正：在 S（區隔）開頭明確說明「只引用優先分 ≥ 48 的因素」，並說明哪些因素因優先分不足而不納入。

**錯誤七：生態系地圖只畫了幾個大廠，競爭者不完整**
症狀：競爭層只有 Google、Amazon 等大廠，遺漏了直接競爭的新創公司和有名字有融資金額的競爭者。
修正：用 Tracxn、Crunchbase、ProductHunt 查詢同類競爭者清單，把有融資記錄的全部畫進去。

---

## 使用其他 Skill 的時機

本 skill 在以下區段會呼叫其他 skill：

| 區段 | 呼叫的 skill | 原因 |
|------|-------------|------|
| PESTEL 分析 | `pestel-analysis` | 有完整的評分框架和移交包格式 |
| 商業模式圖 | `business-model-architect` | 有震央選擇和九格設計的完整方法論 |
| 服務藍圖 | `ecosystem-map-and-blueprint` | 有六層結構和缺口診斷的格式規範 |
| 顧客旅程地圖 | `customer-journey-mapper` | 有情緒分數和階段設計的規格 |

使用方式：在執行對應區段前，讀取該 skill 的 SKILL.md 確認格式要求，然後依照本 skill 的品質標準執行。

---

## 報告輸出規格

- **格式**：Markdown（.md）
- **路徑**：`/mnt/user-data/outputs/[品牌名]_report.md`
- **更新模式**：迭代更新，每個階段完成後立即寫入同一個檔案
- **結構**：使用 `## 一級標題` 和 `### 二級標題`，表格用標準 Markdown 語法
- **Mermaid 圖**：用 ``` mermaid ``` 包裹，確保可在支援 Mermaid 的渲染器中顯示
- **參考資料**：分類編號，放在最後

詳細的空白模板見 `assets/report-template.md`。