客戶說：「我想用 AI 讓客服更好。」
工程師說：「好的，你們的資料在哪裡？」
FDE 說：「我想先了解，你說的『更好』，是指回答速度、準確率，還是人工成本降低？然後我們來看三週能做到什麼。」
這個差距，就是 FDE 面試在測的東西。
面試情境
面試官：「你剛到客戶現場，客戶的 VP of Engineering 說：『我們想用 AI Agent 改造我們的客服流程，你能幫我們做嗎？』你有 45 分鐘的會議時間。你怎麼引導這個對話，讓它結束時有一個可執行的 POC 計畫？」
一、為什麼 Scoping 是 FDE 最核心的顧問技能
沒有 Scoping 的後果：
客戶說「改造客服」
↓ 你直接開始設計
架構圖越來越大
↓
工程師開始做
↓
三週後客戶說「這不是我要的」
↓
FDE 被認為不理解業務需求 → 影響客戶關係
有 Scoping 的流程：
45 分鐘 Discovery → 明確的 POC Scope → 雙方簽字確認
↓
工程師做對的事
↓
三週後 Demo 符合預期
↓
FDE 建立信任 → 後續擴大合作
二、45 分鐘 Discovery 會議的完整流程
時間分配：
0:00 - 0:05 開場 + 議程設定（5 分鐘）
0:05 - 0:20 業務現狀 Discovery（15 分鐘）
0:20 - 0:35 技術現狀 Discovery（15 分鐘）
0:35 - 0:42 POC Scope 提案（7 分鐘）
0:42 - 0:45 確認 Next Step（3 分鐘）
三、業務現狀 Discovery：你要問的 5 個問題
這 5 個問題的目的，是找出一個最小的、有明確價值的切入點。
問題 1：現在的流程是什麼？
「能不能帶我走一遍現在客服處理一個 case 的完整流程？
從客戶發問，到問題解決，中間發生了什麼事？」
你在聽：
├── 有哪些手動步驟
├── 哪些步驟最花時間
└── 哪些步驟重複度高（→ 自動化的候選）
問題 2：規模是多少？
「現在每天大概有多少個客服 ticket？
高峰期是什麼時候？
現在有幾個客服人員在處理？」
你在聽：
├── 量級（決定架構複雜度）
├── 高峰模式（影響 scaling 設計）
└── 人力成本（建立 ROI 計算基礎）
問題 3：什麼情況最讓你們頭痛？
「在現在的客服流程裡，什麼問題最讓你們的 VP 或 CEO 不高興？
是回應速度太慢？還是答案品質不一致？還是夜間無人值守？」
你在聽：
├── 真正的痛點（不一定是他一開始說的）
└── 決策者最在意什麼（影響 Success Criteria 的訂定）
問題 4：有沒有試過什麼解法？
「之前有沒有試過用什麼工具或方案改善這個問題？
為什麼沒有持續？」
你在聽：
├── 失敗的原因（避免重踩）
└── 他們已有的技術基礎（可以利用）
問題 5：成功對你來說長什麼樣？
「如果三個月後我們的解法成功了，
你會怎麼知道？你會看哪些數字？」
你在聽：
└── 具體的、可量化的 Success Criteria
（這個問題很多客戶答不出來 → 你要幫他們訂）
四、技術現狀 Discovery：快速評估可行性
快問快答清單（不超過 15 分鐘）：
問題 你要知道的
──────────────────────────────────────────────────────────
「資料放在哪裡？」 GCS / BigQuery / 本地 DB？
→ 決定 Ingestion 複雜度
「有沒有現成的 FAQ 文件 PDF / Google Docs / Confluence？
或知識庫？」 → RAG 的知識來源
→ 決定 Chunking 複雜度
「工程師熟悉 Python 嗎？」 → 決定 ADK / LangGraph 的選型
「有沒有現成的 GCP 環境？」 → 決定 setup 時間
→ 有的話，直接用 Vertex AI
「對資料合規有特別要求嗎？」 → 是否需要 VPC-SC / Region 限制
→ 影響 Vertex AI 的 deployment 方式
五、POC Scope 提案：三週能做什麼
這是 45 分鐘裡最關鍵的時刻。你要提出一個具體、可執行、有 Success Criteria 的 POC。
POC Scope 的結構
POC Scope 文件（口頭或書面）應該包含：
1. 目標（1 句話）
2. 範圍內（In Scope）
3. 範圍外（Out of Scope） ← 這個最重要
4. Success Criteria（3 個數字）
5. 時程（3 週 Milestone）
6. 雙方的投入（你要什麼、客戶要給什麼）
實際案例：客服 FAQ Agent
POC Scope：客服 FAQ Agent（3 週）
目標：
讓客服人員可以用自然語言查詢 FAQ 知識庫，
減少查找文件的時間，提高回答一致性。
In Scope：
✓ 一個 Slack Bot 介面（客服人員輸入問題 → 得到答案）
✓ FAQ 文件的 RAG Pipeline（現有 50 份 PDF 文件）
✓ 基本的回應準確率評估（50 個測試問題）
Out of Scope（明確說出來）：
✗ 直接對終端客戶開放（只限客服人員使用）
✗ 與 CRM 系統整合
✗ 多語言支援
✗ 生產環境部署（POC 跑在 GCP Sandbox）
Success Criteria：
1. 50 個測試問題中，準確率 ≥ 80%
2. 平均回應時間 ≤ 3 秒
3. 至少 3 位客服人員試用並給予回饋
時程：
Week 1：RAG Pipeline 建立 + 資料 Ingestion
Week 2：Slack Bot 整合 + 基本評估
Week 3：優化 + 客服人員試用 + POC 總結報告
雙方投入：
Google FDE：架構、程式碼、部署
客戶：提供 FAQ PDF、3 位客服試用、GCP 存取權限
六、Out of Scope 的藝術
這是 FDE 最需要練習的技能。Out of Scope 不是在拒絕客戶，是在保護雙方。
客戶說：「可以順便把 CRM 整合也做進去嗎？」
❌ 錯誤回應：
「好，沒問題，我們試試看。」
（範圍擴大，風險增加，時程延誤，最後 Demo 失敗）
✅ 正確回應（三步驟）：
步驟 1：承認這個需求合理
「CRM 整合是很自然的下一步，我完全理解為什麼你想要。」
步驟 2：解釋為什麼現在不做
「但在 POC 階段，CRM 整合需要額外的 OAuth 設置和資料模型對接，
會讓我們的三週時程變成六週，而且風險點增加了兩倍。」
步驟 3：給一個明確的未來路徑
「我的建議是：我們先用這三週確認 FAQ RAG 的準確率可以達標。
如果 POC 成功，CRM 整合會是 Phase 2 的第一個功能——
到時候有了正確的架構基礎，做起來會快很多。」
七、Success Criteria 怎麼訂
這是最難的部分。客戶通常說不清楚「成功是什麼」。
三個層次的 Success Criteria：
層次 1：技術指標（你能控制的）
→ 準確率 ≥ X%
→ 延遲 ≤ X 秒
→ 可用性 ≥ 99%
層次 2：使用者體驗指標（你能影響的）
→ X 位試用者中，Y% 表示「比現在的方式更快找到答案」
→ NPS（試用後問：你願意推薦這個工具給同事嗎？）
層次 3：業務指標（你要幫客戶想的）
→ 每個 case 的平均處理時間從 X 分鐘降到 Y 分鐘
→ 客服人員需要查詢主管確認的次數降低 Z%
訂 Success Criteria 的原則：
├── 具體（有數字，不是「更好」「更快」）
├── 可測量（三週後能拿到這個數字）
├── 雙方同意（不是你單方面定）
└── 現實（不要讓 POC 變成不可能的任務）
八、面試回答的完整示範
面試官問：「你有 45 分鐘，你怎麼引導這個會議？」
好的回答結構：
「我會把這 45 分鐘分成三段：
第一段（前 20 分鐘）：
我不會立刻說架構。我會先問五個問題：
現在的流程是什麼、規模是多少、什麼最讓你們頭痛、
試過什麼、成功對你們長什麼樣。
我要找到一個有明確業務價值的最小切入點。
第二段（中間 15 分鐘）：
快速確認技術現狀——資料在哪裡、有沒有 GCP 環境、
工程師的技術背景。這決定我的 POC 方案是不是可執行的。
第三段（最後 10 分鐘）：
我會提出一個三週的 POC 計畫，明確說清楚
In Scope、Out of Scope、Success Criteria 和雙方需要投入的資源。
我不會要求他當場拍板，但我會問：
『這個方向符合你的預期嗎？如果符合，我們可以約下週確認細節。』
會議結束時，我要帶走三樣東西：
一份 POC Scope 草稿、一個雙方同意的 Success Criteria、
以及一個明確的下一步時間點。」
Scoping 不是在限制客戶的想像力。
是在讓三週後的 Demo 能夠成功——那才是建立長期信任關係的基礎。
