客戶說：「我們想要 AI。」
這不是需求，這是一個方向。
優秀的 FDE 不直接問「你要什麼功能」，
而是問：「你現在的哪個問題，讓你睡不著覺？」
面試情境
面試官：「一家製造業客戶的 CTO 打電話說：『我們想用 AI 改善營運效率。我看到競爭對手都在做 AI，我們不能落後。』你和他約了第一次 30 分鐘電話。你會怎麼進行？你想挖掘什麼資訊？電話結束時你的目標是什麼？後續步驟是什麼？」
一、為什麼「要 AI」不是需求
「要 AI」的三種真正動機（不同動機 → 完全不同的 POC 策略）：
動機 A：競爭壓力（Follow the Market）
信號：「競爭對手都在做，我們不能落後」「我在新聞上看到 AI 可以做到 X」
真實需求：快速可見的成果，能對外展示
→ POC 策略：優先「Demo 效果最好」的場景，速度第一，3 週出 Demo
→ 陷阱：如果做了一個「很強大但看不見」的 AI，客戶會說失敗
動機 B：內部痛點（Pain-Driven）
信號：「我們的人都在做重複的事」「某個流程效率很低，浪費很多時間」
真實需求：降低運營成本，解放員工時間
→ POC 策略：先量化痛點（N 個人 × M 小時），POC 做完計算節省比例
→ 重點：ROI 對話，不是功能展示
動機 C：技術探索（Innovation-Driven）
信號：「我想了解 AI 能幫我們做什麼」「我們有個想法想驗證」
真實需求：教育和探索，不是立刻部署
→ POC 策略：選一個工程師能理解和參與的場景，目標是建立 AI 直接體感
→ 重點：過程比結果更重要（讓客戶團隊學到東西）
FDE 的工作：
第 1 步：判斷客戶是哪種動機
第 2 步：用對應的語言和框架和客戶對話
第 3 步：設計對應類型的 POC
錯誤做法：
無論客戶是哪種動機，都給同一個 POC 方案
→ 動機 A 的客戶看到「技術很強但 Demo 要等 3 個月」→ 失望
→ 動機 B 的客戶看到「Demo 很漂亮但沒有 ROI 數字」→ 無法簽約
二、三個顧問參與階段
╔══════════════════════════════════════════════════════════════╗
║ Phase 1：Discovery（第一次接觸 → 初步提議） ║
║ 目標：了解真實需求和限制條件，提議一個合理的 POC 起點 ║
╚══════════════════════════════════════════════════════════════╝
時間：1-2 次電話，共 60-90 分鐘
主要活動：
├── 30 分鐘 Discovery 電話（五個核心問題）
├── Stakeholder Mapping（找出誰是誰）
└── 初步 POC 範圍提議（電話結束前）
輸出文件：
└── 1 頁 Discovery 摘要（痛點、量化數字、限制條件、初步建議場景）
成功標準：
├── 客戶確認一個具體的業務場景
├── 了解資料可用性（能快速評估可行性）
└── 客戶願意安排下一步（Technical Assessment）
╔══════════════════════════════════════════════════════════════╗
║ Phase 2：Technical Assessment（技術可行性評估） ║
║ 目標：確認架構可行、資料可用、整合複雜度，精確化 POC 範圍 ║
╚══════════════════════════════════════════════════════════════╝
時間：1-2 週
主要活動：
├── 資料評估（看資料品質、量、格式、存取方式）
├── 技術架構評估（整合現有系統的複雜度）
├── 與 Technical Gatekeeper 對話（確認 IT 政策、安全要求）
└── POC 範圍精確化（從「維修手冊 AI 助手」到「針對 3 台機器，3 週，2 位工程師驗收」）
輸出文件：
└── Technical Assessment Report（資料可行性、架構方案、POC 詳細範圍、風險清單）
成功標準：
├── 確認資料可以在 POC 期間取用
├── IT Gatekeeper 在技術方案上達成共識
└── POC 範圍精確到「誰做什麼、什麼時候完成、怎麼驗收」
╔══════════════════════════════════════════════════════════════╗
║ Phase 3：POC Proposal（POC 提案） ║
║ 目標：獲得 Economic Buyer 的預算批准和資源承諾 ║
╚══════════════════════════════════════════════════════════════╝
時間：1-2 次會議
主要活動：
├── Value Story 呈現（ROI 估算，見第七節）
├── POC 成功標準定義（量化驗收標準）
├── 資源和時間承諾確認（客戶提供什麼、你提供什麼）
└── 風險和緩解策略說明
輸出文件：
└── POC Proposal（目標、範圍、驗收標準、時間線、雙方承諾、費用）
成功標準：
└── Economic Buyer 批准預算，雙方簽署 POC Agreement
三、Discovery 對話的三個層次
三個層次的深度和目的：
┌──────────────────────────────────────────────────────────────┐
│ 層次 1：業務目標（Business Goal） │
│ │
│ 問：「6 個月後，什麼指標改善了，你會說這個 AI 專案成功了？」 │
│ │
│ 目的：讓客戶定義「成功」，把模糊的「AI 改善效率」 │
│ 轉化為可量化的指標 │
│ │
│ 不好的答案（模糊）： │
│ 「提升效率」「改善品質」「讓員工更開心」 │
│ │
│ 好的答案（可量化）： │
│ 「品管員的人工複查時間，從每件 4 小時降到 1 小時」 │
│ 「供應商異常的平均反應時間，從 48 小時縮到 8 小時」 │
│ │
│ 引導技巧： │
│ 「如果你要向你的 CEO 展示這個 AI 專案成功了， │
│ 你會說哪一個數字改善了多少？」 │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 層次 2：現在的痛點（Current Pain） │
│ │
│ 問：「能否描述一個具體的場景，讓我了解今天的問題 │
│ 是怎麼發生的？一週大概發生幾次？需要幾個人？」 │
│ │
│ 目的：讓客戶說出一個真實的工作流程故事（有具體的人、動作、頻率）│
│ 同時把痛點量化（為後續 ROI 計算準備數字） │
│ │
│ 追問量化數字： │
│ 「這個問題大概影響多少人？」→「20 個品管員」 │
│ 「每人每天花多少時間？」→「4 小時」 │
│ 計算：20 × 4h × 250 天 = 20,000 人時/年 │
│ 這個數字後來出現在 Value Story 的 ROI 計算裡。 │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 層次 3：限制條件（Constraints）— 找隱藏地雷 │
│ │
│ 問：「資料在哪裡？IT 對雲端有什麼限制？ │
│ 最終用戶是誰？他們的技術能力如何？」 │
│ │
│ 常見隱藏地雷和對應問題： │
│ │
│ 地雷 問題 高風險信號 │
│ ────────────────────────────────────────────────────────── │
│ 資料不可用 「資料在哪裡存？格式？」 「紙本」「各地 Excel」│
│ IT 封鎖雲端 「IT 對雲端有限制嗎？」 「我們很保守」 │
│ 最終用戶抵制 「用戶知道這個專案嗎？」 「我還沒跟他們說」 │
│ 預算不在 Champion 「誰批准這個預算？」 「我來想辦法」 │
│ Legal/合規障礙 「有資料使用的法規限制？」「有個資保護法」 │
└──────────────────────────────────────────────────────────────┘
四、利害關係人影響力地圖
四個關鍵角色及其影響力：
┌─────────────────────────────────────────────────────────────┐
│ 影響力地圖 │
│ │
│ 高決策影響力 │
│ ↑ │
│ │ Economic Buyer │
│ │ （有預算，決定投資） Champion │
│ │ → 需要看 ROI 數字 （推動者，有熱情） │
│ │ → 不一定有 AI 背景 → 我們的主要聯絡人 │
│ │ → 不一定有預算 │
│ │ │
│ │ │
│ │ Technical Gatekeeper End User │
│ │ （IT/架構師，評估技術） （實際使用者） │
│ │ → 可能是阻力也可能是盟友 → 決定採用率 │
│ │ → 必須早期納入 → 最常被遺漏 │
│ │ │
│ ↓ │
│ 低決策影響力 │
│ ←────────────────────────────────────────────────────→│
│ 反對 AI 支持 AI │
└─────────────────────────────────────────────────────────────┘
每個角色的核心關注和你需要做的事：
角色 核心關注 你需要做的
──────────────────────────────────────────────────────────────
Champion 希望 AI 在組織內成功 讓他成為你的盟友；
自己的 KPI 提供他「向上推銷」的彈藥（ROI、案例）
──────────────────────────────────────────────────────────────
Economic Buyer ROI、風險管控 先讓 Champion 安排見面機會；
投資回報 用業務語言（不是技術語言）說話
──────────────────────────────────────────────────────────────
Technical 安全、整合可行性 早期納入，讓他成為方案的「共同設計者」；
Gatekeeper 現有架構不被打亂 不要最後才讓他評估（他會找一堆問題否決）
──────────────────────────────────────────────────────────────
End User 工作有沒有變輕鬆 Demo 必須讓他們試用；
不想被 AI 取代 強調「AI 幫你做你不喜歡的部分」
──────────────────────────────────────────────────────────────
常見的 Stakeholder 失敗模式：
失敗模式 1：Champion 有熱情，但 Economic Buyer 不知道這個專案
→ POC 完成，預算沒批，專案在等待中死亡
→ 預防：第一次電話後就問「誰批准預算？我需要和他談嗎？」
失敗模式 2：Technical Gatekeeper 最後才被納入
→ 技術方案設計完成後，IT 說「這不符合我們的安全政策」
→ 預防：Phase 2 Technical Assessment 時必須和他深談
失敗模式 3：End User 從未被問過需求
→ Demo 很成功，但真正的用戶說「這個流程我們用不了」
→ 預防：POC 期間讓 End User 試用，收集真實反饋
五、需求挖掘的五個核心問題
30 分鐘電話的五個問題框架：
問題 1（業務痛點，5 分鐘）：
「能否描述一個具體的場景，讓我了解今天的問題是怎麼發生的？」
追問：
└── 「這個問題多久發生一次？」
└── 「每次大概影響多少人，需要多少時間處理？」
成功標準：客戶說出一個有具體細節的故事
不成功：客戶只說「流程很低效」（抽象，無法推進）
─────────────────────────────────────────────────────────────
問題 2（量化影響，3 分鐘）：
「這個問題影響多少人？每週或每年大概花多少時間或多少成本？」
引導技巧（客戶沒有數字時）：
└── 「你估計大概是這個量級嗎？每人每天超過 1 小時？超過 3 小時？」
→ 讓客戶確認範圍，比讓他從零想更容易
成功標準：有一個可以用於 ROI 計算的數字
示例：「20 個品管員，每人每天 4 小時」
→ 後來成為：「如果 AI 減少 75%，每年節省 15,000 人時，
折算人力成本約 $450,000」
─────────────────────────────────────────────────────────────
問題 3（資料可行性，3 分鐘）：
「這個問題涉及的資料，現在存在哪裡？是什麼格式？大概有多少量？」
高風險信號（需要更多評估時間）：
├── 「資料在各地工廠的 Excel，每個廠格式不一樣」
├── 「大部分是紙本，需要掃描」
└── 「在老舊的 ERP 系統裡，沒有 API，需要 DBA 配合」
低風險信號（POC 可能 3 週完成）：
└── 「維修手冊是 PDF，都在 SharePoint 上，大概 500 份」
─────────────────────────────────────────────────────────────
問題 4（成功定義，3 分鐘）：
「3 個月後，你怎麼判斷這個 AI 系統是成功的？」
目的：逼客戶把成功定義量化，不能只說「感覺更好」
不好的答案：「用戶說這個系統很好用」
好的答案：「品管員的複查時間從 4 小時降到 1 小時，且準確率不低於現在」
這個答案後來成為 POC 的驗收標準，避免 POC 結束後的爭議。
─────────────────────────────────────────────────────────────
問題 5（資源承諾，3 分鐘）：
「你希望什麼時候看到第一個可以展示的成果？
你們這邊能投入哪些資源配合（領域專家、IT、測試用戶）？」
最低資源要求（必須確認）：
└── 2 位領域專家，配合 3 週（提供資料、驗收答案品質）
高風險信號：
└── 「你們主導，我們配合」（沒有具體承諾）
→ 後果：POC 期間找不到人驗收答案品質，無法推進
→ 預防：明確說「領域專家每週需要投入約 4 小時配合我們，
這是 POC 成功的必要條件，不只是 nice to have」
六、POC 場景評分矩陣
五個維度的評分（1-5 分），選總分最高的場景：
維度 說明
──────────────────────────────────────────────────────────────
業務影響力 客戶有多在乎這個問題？解決後對業務有多重要？
資料可用性 資料是否數位化、可取用、格式可解析、量足夠？
技術可行性 用現有 AI 技術在 3-4 週內能做出有說服力的 Demo？
Demo 效果 5 分鐘內，非技術 Stakeholder 能看到價值嗎？
擴展路徑 POC 成功後，能以合理代價擴展到全公司嗎？
──────────────────────────────────────────────────────────────
製造業客戶評分示例：
場景 業務影響 資料可用 技術可行 Demo效果 擴展路徑 總分
──────────────────────────────────────────────────────────────────────
維修手冊 AI 助手 4 5 5 5 4 23 ✅
視覺品質檢測自動化 5 3 4 4 5 21
供應鏈異常預警 5 3 3 3 5 19
生產排程優化 4 3 2 2 4 15 ❌
選擇維修手冊 AI 助手（23 分）的具體理由：
為什麼技術可行性 5 分：
└── 文字 PDF + RAG 是最成熟的 AI 技術，不需要自訓練，3 週可完成
為什麼資料可用性 5 分：
└── 維修手冊是 PDF，已數位化，在 SharePoint，取用簡單，500 份夠用
為什麼 Demo 效果 5 分：
└── 維修工程師在手機上問問題，AI 立刻找到相關手冊段落並解釋
非技術的 CTO 一眼看到「這和我現在用 PDF 的差距」
為什麼不選生產排程優化（15 分）：
└── 排程優化是複雜的組合優化問題，需要收集生產線實時數據
3-4 週根本做不出有說服力的 Demo
POC 範圍縮小的原則（越窄越好）：
❌ 過寬（失敗風險高）：
「所有工廠所有機型的維修手冊，支援中英文，整合 SAP 工單系統」
✅ 正確（聚焦、可完成）：
「A 工廠最常出問題的 3 台機器的中文維修手冊，
能回答工程師的故障排查問題，
3 週完成 Demo，
由 2 位資深維修工程師驗收答案品質（準確率 > 80%）」
縮小範圍的對話技巧：
└── 「我知道理想狀態是涵蓋所有機型，
但為了在 3 週內給你一個可以信任的 Demo，
我建議先從你們最頭痛的 3 台機器開始——
成功之後，擴展到其他機型只是重複相同的工作，不是重新設計。」
七、Value Story 框架（如何呈現 ROI）
Value Story 的結構（呈現給 Economic Buyer）：
┌──────────────────────────────────────────────────────────────┐
│ 1. 現在的代價（量化痛點） │
│ │
│ 「你們有 20 個品管員，每人每天花 4 小時做人工複查。 │
│ 一年的人力成本是： │
│ 20 人 × 4 小時 × 250 工作天 × $30/小時 = $600,000/年」 │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 2. AI 能改善多少（保守估計） │
│ │
│ 「根據類似的視覺 AI 導入案例，人工複查時間平均減少 60-70%。 │
│ 保守估計 50%：每人每天節省 2 小時。」 │
│ │
│ 「節省的成本：$600,000 × 50% = $300,000/年」 │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 3. AI 的成本（POC + 生產建置 + 維護） │
│ │
│ 「POC 費用：$30,000（3 週） │
│ 生產建置：$50,000（2 個月） │
│ 年維護：$24,000/年 │
│ 第一年總成本：$104,000」 │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 4. ROI 結論 │
│ │
│ 「第一年 ROI：$300,000 - $104,000 = $196,000 淨節省 │
│ 投資回收期：約 4 個月 │
│ 第二年起（無建置費）：$300,000 - $24,000 = $276,000/年淨節省」│
└──────────────────────────────────────────────────────────────┘
Value Story 的注意事項：
✅ 使用客戶自己說出的數字（問題 2 收集的）
✅ 保守估計（用 50% 而不是「可能 80%」）
✅ 說明數字的來源（類似案例，不是保證）
✅ 明確是「節省人力時間」而不是「裁員」（避免用戶抵制）
❌ 避免：
├── 拍胸脯保證 ROI（你無法保證）
├── 用最樂觀的估計（會在後期被挑戰）
└── 用技術語言（Economic Buyer 不理解 RAGAS 分數是什麼）
八、常見客戶異議的處理框架
異議 1：「AI 的準確率夠嗎？我們的場景要求很高。」
❌ 錯誤回應：「我們的準確率 95%」（沒有依據的承諾）
✅ 正確回應：
└── 「這正是我們做 POC 的原因。POC 期間，我們會和你們的資深工程師
一起定義什麼叫『準確』——在 100 個測試問題上，
你的工程師滿意的比例要達到多少，才算達標？
這個數字由你決定，POC 結束時你用這個標準驗收。
如果達不到，你不需要繼續投資。」
異議 2：「我們的資料很敏感，AI 可以保護好嗎？」
✅ 正確回應：
└── 「這是最重要的設計考量，我們有具體的方案：
（1）資料不離開你們的網路（私有部署或 VPC 隔離）；
（2）所有傳輸加密（TLS 1.3）；
（3）誰存取了什麼資料都有不可篡改的稽核記錄；
（4）POC 期間只使用你們提供的測試資料，不使用生產資料。
我可以在 Technical Assessment 時和你的 IT 架構師詳細討論安全要求。」
異議 3：「我們已經有其他 AI 供應商在評估了。」
✅ 正確回應：
└── 「這很正常，多方評估是正確的做法。
我建議你用相同的問題和驗收標準同時評估：
三週後，每家供應商都在你的實際資料上 Demo 同樣的場景，
你的工程師用你自己定義的準確率標準打分。
誰的 Demo 最符合你的需求，你就選誰。
我有信心在公平評估下，我們的方案有競爭力。」
異議 4：「POC 要多少錢？能不能免費做？」
✅ 正確回應：
└── 「POC 是有成本的——我們的工程師需要全職投入 3 週，
而不是做一個通用 Demo 再換皮。
真正的 POC 是在你的資料上、針對你的場景、
用你的驗收標準設計的。這是 POC 有價值的原因。
如果你現在不確定是否要付費 POC，
我們可以先做一個 1 天的免費技術可行性評估：
我帶工程師到現場看你們的資料，
給你一份書面評估：『POC 成功的機率大約是多少，需要什麼條件』。
這樣你做 POC 決定時有更多資訊。」
九、為什麼選 X 不選 Y：顧問方法論選型
決策 1：評分矩陣 vs 直覺選擇場景
直覺選擇的問題：
└── FDE 可能選「我最熟悉的技術」而不是「客戶最需要的場景」
或者選「業務影響最大的」但忘了評估技術可行性
評分矩陣的優勢：
├── 讓客戶參與評分（他對業務影響的判斷比你準）
├── 把技術可行性和業務影響並列，避免只看一個維度
└── 評分結果可以作為「為什麼選這個場景」的文件依據
例外：如果客戶已經有非常明確的場景（「就是這個，不考慮其他」），
跳過矩陣，直接評估這個場景的可行性。
決策 2：30 分鐘 Discovery 電話 vs 直接出技術方案
直接出技術方案的問題：
└── 沒有了解真實痛點 → 做了一個「技術正確但業務不需要」的方案
客戶感覺「你根本不了解我們的業務」
Discovery 電話的優勢：
├── 讓客戶感覺被理解（比展示技術能力更重要）
├── 發現隱藏地雷（資料、IT 政策、Stakeholder 問題）
└── 獲得量化數字，讓後續 ROI 對話有依據
決策 3：一個 POC vs 多個並行 POC
多個並行 POC 的問題：
├── 資源分散，每個 POC 的深度不夠
├── 客戶也分散注意力，難以配合
└── Demo 效果都「差不多」，無法真正展示 AI 的價值
一個 POC 的優勢：
└── 集中資源 → 一個場景做得很好 → 客戶有「哇」的時刻
「哇」的時刻是 AI 採用的關鍵轉折點
決策 4：3 週 POC vs 3 個月 POC
3 個月 POC 的問題：
├── 範圍過大，容易失焦
├── 3 個月後業務重點可能改變（Champion 可能換部門）
└── 客戶需要等太久才能看到任何成果，熱情消退
3 週 POC 的優勢：
├── 強迫聚焦（範圍不得不縮小）
├── 快速驗證可行性（失敗了也快速失敗，代價低）
└── 3 週後有具體 Demo，讓 Economic Buyer 決定是否繼續投資
決策 5：以功能為主的 Demo vs 以 Value Story 為主的 Demo
功能 Demo：「看，它可以做 X、Y、Z」
└── 非技術 Stakeholder 看完說「好像不錯」→ 沒有購買衝動
Value Story Demo：「看，這是你們工程師每天花 4 小時做的事，
現在 AI 30 秒就做完了，準確率和你的老員工一樣」
└── Economic Buyer 立刻能計算 $300,000/年的節省
十、系統效應
維度 有 Discovery 框架 沒有 Discovery 框架
──────────────────────────────────────────────────────────────────
POC 成功率 高（範圍對齊真實需求） 低（做完才發現客戶要的不是這個）
──────────────────────────────────────────────────────────────────
專案範圍蔓延 有明確範圍和驗收標準， 需求持續追加，
「超出範圍」有文件依據 永遠做不完
──────────────────────────────────────────────────────────────────
客戶期望 第一次對話就對齊 Demo 後客戶說：
「這不是我要的」
──────────────────────────────────────────────────────────────────
隱藏地雷 Discovery 階段發現， POC 中途發現資料不可用，
可以在 POC 設計中規避 整個方案要重來
──────────────────────────────────────────────────────────────────
ROI 對話 有客戶自己說的數字（20人×4h）， 無法計算，
呈現給 Economic Buyer 有說服力 客戶問 ROI 不知如何回答
──────────────────────────────────────────────────────────────────
Stakeholder 風險 早期識別所有 Stakeholder， Technical Gatekeeper
提前處理阻力 在最後否決整個方案
──────────────────────────────────────────────────────────────────
FDE 差異化 客戶感覺「你真正了解我們」 客戶感覺「你只是在賣產品」
──────────────────────────────────────────────────────────────────
結論：
Discovery 框架不是「多花時間在前期」，
而是「把後期可能的 10 倍返工成本，轉移到前期的 1 倍探索成本」。
POC 失敗的第一大原因：
不是技術能力不足，而是做了正確的東西，但不是客戶真正需要的。
Discovery 框架解決的就是這個問題。
十一、面試答題要點
「30 分鐘電話的目標，不是解釋 AI 能做什麼，而是找到一個具體的業務痛點，以及評估這個痛點能否在 3-4 週的 POC 內展示解決。
我會先判斷客戶的動機：這位 CTO 說的是競爭壓力（動機 A），所以 POC 策略是『Demo 效果最好的場景，速度優先』，而不是『業務影響最大的場景』。
電話的骨架：五個問題——業務痛點（具體場景故事）、量化影響（幾個人，多少時間）、資料可行性（在哪裡，什麼格式）、成功定義（什麼指標改善算成功）、資源承諾（客戶能投入什麼）。
同時做 Stakeholder Mapping：Champion 是這位 CTO，但誰是 Economic Buyer？IT 架構師的立場？最終用戶有沒有被納入？如果 Economic Buyer 還不知道這個專案，需要安排下一步對話。
電話結束前提議 POC 範圍：用評分矩陣選出技術可行性和 Demo 效果最高的場景，縮小到最具體的版本（3 台機器，3 週，2 位工程師驗收）。
Phase 2 的 Technical Assessment：和 IT 架構師確認技術限制，評估資料品質，把 POC 範圍精確到每一個交付物。Phase 3 的 POC Proposal：用 Value Story（量化 ROI）和 Economic Buyer 談，讓預算批准有數字依據，而不是靠熱情說服。」
