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。