技術方案的死因往往不是架構錯誤，而是你從未和那個能按下否決鍵的人說過話——Stakeholder Mapping 是在第一次會議之前就找到他的方法。
面試情境： 「你有一個企業客戶，窗口聯絡人對你的 AI 方案非常興奮，但已經過了三個月，合約還沒簽。你怎麼判斷問題出在哪裡？你下一步會怎麼做？」
一、為什麼面試官問這個
面試官問利害關係人圖譜，真正在測試的是以下三件事：
你是否把「客戶」當成一個人而不是一個組織。 弱答案：「我們會跟客戶的 CTO 介紹技術方案。」這暴露你只看到一個接觸點，沒有意識到 CTO 背後有法務、財務、採購、資安各自擁有否決權。強答案：在第一次探索電話之後就能列出決策鏈的所有節點，並為每個節點設計不同的溝通材料與時序。
你是否理解企業 AI 採購的政治複雜度。 弱答案：「只要 ROI 夠好，預算就會批下來。」在企業採購中，ROI 是必要條件而非充分條件；隱藏在法規遵循、廠商鎖定、組織利益之中的顧慮，才是真正讓決策卡關的變數。一個 $2M 的 AI 合約在最後一週因為資料主權問題被法務否決，不是因為 ROI 不夠，而是因為 FDE 從未和法務說過話。
你能否主動消除阻力而不是被動應對突襲。 強答案展示一個系統性流程：先建圖譜、再依類型安排 1:1 探索對話、在正式提案之前就把每個阻礙化解在水面下。能說出具體加速效果（如「這個流程在上一個客戶縮短了 8 週成交週期」）的候選人，比只能說「我會多跟客戶溝通」的候選人，面試評分至少差兩個層級。
二、核心原理與技術深度
影響力圖譜的資料結構
Stakeholder Map 本質上是一張有向加權圖（Directed Weighted Graph）：
節點屬性（Node Attributes）
name: 姓名 / 團隊名
archetype: Champion | Economic Buyer | Technical Evaluator | Blocker
concern: 主要顧慮關鍵字（cost / compliance / security / lock-in）
influence: 1–5 決策影響力評分
sentiment: +2（強支持）到 -2（強反對）的情感傾向
status: 未接觸 | 已接觸 | 已對齊 | 仍存疑
有向邊屬性（Edge Attributes）
from → to: A 的決定影響 B 的決定
weight: 影響強度 1–5
type: 直屬 | 技術核准 | 預算核准 | 政治影響
建圖演算法使用拓撲排序（Topological Sort）識別真正的終端決策者——入度（in-degree）為零的節點不依賴任何人的批准，他就是 Economic Buyer。入度高的節點（被多方影響）是需要被最後對齊的人，通常是 PM 或專案主管。
影響力圖譜：典型企業 AI 採購結構
┌──────────────────────────────────────┐
│ CFO / VP Finance │ 影響力 5 / 入度 0
│ 最終預算核准（Economic Buyer） │
└──────────────┬───────────────────────┘
│ 預算核准
┌────────────▼─────────────┐ ┌─────────────────────────┐
│ 業務單位主管 BU GM │◀───────│ CISO / 資安長 │
│ （Economic Buyer 代理） │ 技術 │ （Technical Evaluator） │
│ 影響力 4 / 入度 1 │ 核准 │ 影響力 4 / 入度 0 │
└────────────┬─────────────┘ └──────────────┬──────────┘
│ 指派 │ 審核
┌────────────▼─────────────┐ ┌──────────────▼──────────┐
│ 專案 PM / 窗口 │ │ 首席架構師 / InfoSec │
│ （Champion） │ │ （Technical Evaluator） │
│ 影響力 3 / 入度 2 │ │ 影響力 3 / 入度 1 │
└────────────┬─────────────┘ └─────────────────────────┘
│ 協調
┌────────────┴─────────────┐
│ │
┌───────▼──────────┐ ┌────────▼─────────────┐
│ 法務 / DPA 負責人 │ │ 採購 / Vendor Mgmt │
│ （Blocker） │ │ （Blocker） │
│ 影響力 4 │ │ 影響力 3 │
└──────────────────┘ └──────────────────────┘
四大原型的深度分析
Champion（倡導者）
Champion 是你在客戶組織內部的共同銷售夥伴。他的價值來自兩個不可替代的能力：情境資訊（誰在這個組織有真正的影響力、有什麼歷史包袱、什麼是組織的敏感話題）和政治代理（在你不在場的會議中為你發言）。
Champion 的典型特徵：主動提出問題、願意分享內部文件、協助安排與其他人的會議。警示訊號：Champion 只說「這個想法很棒」但從不幫你安排下一步的會議——這代表他可能熱情但沒有足夠的內部政治資本，無法推動決策。
給 Champion 的「彈藥」必須是可直接轉發的格式：
- 競品在同類客戶的 ROI 數字（「同產業客戶用這個方案節省了每年 $1.2M」）
- 1 頁 A4 的商業理由摘要（非技術語言，他可以直接附在郵件轉給主管）
- 針對已知反對意見的問答清單（如果有人問資料安全問題，他有現成的書面答案）
- 競爭對手已採用類似方案的市場情報（FOMO 對 Economic Buyer 非常有效）
Economic Buyer（預算持有人）
Economic Buyer 控制最終的預算核准。關鍵洞察：他幾乎永遠都不是你最初的接觸窗口。你的窗口聯絡人可能對你非常熱情，但沒有預算簽署權——這是 FDE 最常見的誤判，直接導致花費數週提案精力卻因「我需要請示上面」而無限期卡關。
識別 Economic Buyer 的問法（對 Champion 聯絡人）：
「在貴公司，這個規模的採購決定（$X 金額）最終是哪個層級核准的？流程大概是什麼樣子？需要哪些部門點頭？」
Economic Buyer 關心的三個維度（按優先順序）：
- 財務影響：節省 $X、帶來 $Y 收入、payback period Z 個月、IRR 是否超過資金成本
- 風險轉移：採用後組織承擔的新風險是什麼、供應商如何承擔責任、SLA 違約賠償條款
- 競爭壓力：競爭對手是否已採用類似方案（FOMO 是強大的推力，比任何技術特性都有效）
絕對禁忌：在 Economic Buyer 的會議中用超過 2 分鐘談技術細節。 他的時間非常有限（通常你只有 20–30 分鐘），每一分鐘都應花在業務結果上。技術細節是給 Technical Evaluator 的，不是給他的。
Technical Evaluator（技術審查者）
Technical Evaluator 的角色是找出你方案的漏洞——這是他的工作職責，不是個人態度。最常犯的錯誤是把他的刁難問題當成惡意對待，而不是把它當成建立信任的機會。
黃金原則：主動提交文件，不要等待提問。 在 1:1 之前先發送技術文件包：
Technical Evaluator 標準文件包（Enterprise AI 場景）
安全合規類：
□ 架構圖（含資料流動路徑、信任邊界、加密層位置）
□ 合規認證清單（SOC 2 Type II、ISO 27001、CSA STAR）
□ 滲透測試報告摘要（最近 12 個月內，含修復紀錄）
□ 漏洞管理政策（CVE 修補 SLA：Critical 24h、High 7d）
□ 員工背景查核政策（接觸客戶資料的人員範圍）
資料處理類：
□ 資料處理協議草稿（DPA）
□ 資料保留與刪除政策
□ 跨境傳輸機制說明（Standard Contractual Clauses 等）
□ 資料分類標準（PII / 敏感資料的處理方式）
可靠性類：
□ SLA 保證書（可用性 99.9%、RTO/RPO 數字）
□ 過去 12 個月的可用性報告（實際 uptime 紀錄）
□ 事件回應流程說明（事件分級、通知 SLA、根因分析）
□ 災難復原計畫（DR Plan）摘要
贏得 Technical Evaluator 尊重的信號：他開始問「這個功能怎麼設定」而不是「這個功能能不能做到」。這代表他的心智模型已從「評估是否可信」轉移到「規劃如何導入」。
Blocker（阻擋者）
Blocker 是最常被低估的原型。初級錯誤：試圖繞過 Blocker，期待他在最後不會造成麻煩。 後果：他在合約審查或上線前最後一週現身，帶著強烈的被忽視情緒，此時化解阻力的成本是早期直接對話的 10 倍以上——因為他現在不只在反對技術方案，還在回應被排除在外的不滿。
Blocker 的核心心理學：他反對的不是你的方案，而是一個尚未被解答的具體問題。 找到那個問題，直接回答它，他就從阻礙者變成中立者甚至支持者。
企業 AI 專案的常見 Blocker 類型與對應化解策略：
Blocker 類型 核心顧慮 化解策略
───────────────────────────────────────────────────────────────────────
法務 / DPA 負責人 GDPR 跨境傳輸 提供 DPA 草稿 + 資料台灣 / 歐盟
資料處理協議未簽署 本地化部署架構圖
CISO / 資安長 滲透測試要求 提供近期滲透測試報告
零信任架構符合性 + CVE 修復紀錄 + SSAE 18 報告
採購 / Vendor Mgmt 優先廠商清單不含我方 確認是否需走 RFP 流程
現有廠商合約排他條款 或申請白名單豁免程序
財務 / 會計 CapEx vs OpEx 分類 與財務確認雲端訂閱費用的
影響資產負債表 會計處理方式（通常走 OpEx）
現任廠商代理人 自身業務受威脅 定位為補充而非替換；
（有時不在桌上） 組織利益保護 提供協作路徑與轉型計畫
情感-影響力矩陣與參與優先順序
建完圖譜之後，接下來的問題是：誰要先接觸、接觸頻率要多高？用情感傾向（sentiment：支持 vs 反對）和決策影響力（influence：高 vs 低）兩個維度排列優先順序：
參與優先順序矩陣
決策影響力
低（1–2） 高（3–5）
┌───────────────┬───────────────────┐
│ Supporter │ Champion / │
情 支持 │ 監測即可； │ Economic Buyer │
感 │ 偶爾更新狀態 │ 高頻接觸；給彈藥 │
傾 │ （月頻） │ 和數字（週頻） │
向 ├───────────────┼───────────────────┤
│ Skeptic │ Blocker │
反對 │ 資訊透明化； │ 最高優先； │
│ 等待機會教育 │ Demo 前必須完成 │
│ （雙週頻） │ 1:1（日 / 週頻） │
└───────────────┴───────────────────┘
矩陣中最危險的象限是右下角（高影響力 + 強反對）——這是 Blocker。但第二危險的是右上角（高影響力 + 支持但弱）：Champion 沒有足夠的政治資本時，他對你的熱情毫無幫助，甚至可能給你錯誤的安全感，讓你低估了真正需要觸及 Economic Buyer 的緊迫性。
參與頻率建議（依優先順序）：
| 原型 | 主動接觸頻率 | 核心溝通目標 | 衡量成功的信號 |
|---|---|---|---|
| Blocker | 每週直到顧慮化解 | 找出具體反對理由並書面回應 | 從「反對」變為「有條件支持」 |
| Economic Buyer | 每兩週一次摘要郵件 | 維持 ROI 敘事的顯著性 | 他主動詢問下一步或時程 |
| Champion | 每週非正式同步 | 確認內部政治溫度，及時補充彈藥 | 他主動安排其他人的會議 |
| Technical Evaluator | 按需求，文件問題 24h 回應 | 把每個技術問題變成信任建立機會 | 問題從「能不能做」變「怎麼設定」 |
隱藏阻擋者的出現時序
若未主動做 Stakeholder Mapping，阻擋者在採購週期後段才現身的典型時序：
未做 Stakeholder Mapping 的採購週期（16+ 週）
週 1–2 Champion 窗口熱情洽談，FDE 開始投入
▼
週 3–4 技術 Demo，技術窗口表示讚賞
▼
週 5–6 提案文件交付，等待回應
▼
週 7 「法務說需要審查 DPA」← 法務 Blocker 第一次現身
▼
週 9 「CISO 需要審查資安架構文件」← 資安 Blocker 現身
▼
週 11 「採購說要走 RFP 流程」← 採購 Blocker 現身
▼
週 14 「今年預算已凍結」← Economic Buyer 從未參與
▼
週 16+ 延至下一財年，或流失給已做 Stakeholder Mapping 的競爭對手
---
做了 Stakeholder Mapping 的採購週期（8–10 週）
週 1 Champion 1:1 → 建立影響力圖，識別所有節點
▼
週 2–3 各原型 1:1 Discovery Call（含 Blocker 直接對話）
顧慮被識別、文件包被發送、具體要求被確認
▼
週 4 主要 Demo（敘事已針對所有原型校準）
所有關鍵人物已有立場，沒有「帶回去討論」
▼
週 5–6 提案（已納入所有 1:1 的顧慮回應）
▼
週 7–8 談判 + 合約審查（法務 / 採購已提前對齊）
▼
週 9–10 合約簽署 ← 縮短 6–8 週
三、三個實作層次
Layer 1 — 最小可行（Minimal）
做法： 在第一次客戶電話之前，請 Champion 聯絡人提供組織圖或決策流程說明。手工在試算表上標記每個人的原型分類、主要顧慮、參與狀態與最後接觸日期。至少確認兩件事：誰有預算簽署權、法務或採購是否需要介入。
解決的問題： 避免投入大量提案精力卻因預算持有人從未見過你而被擱置。至少能在主要 Demo 之前確認預算核准層級，防止最嚴重的誤判。
代價/複雜度： 1–2 小時人工研究。工具：LinkedIn 公司頁面、公開年報職稱、Champion 提供的 org chart。無工具成本。
遺留問題： 對內部政治生態理解仍然淺薄；對 Blocker 的具體顧慮沒有足夠的提前了解；沒有系統性的 1:1 安排；Demo 敘事未針對不同原型校準。
適用情境： 合約金額 < $100K 的小型客戶、初期探索性洽談、時間壓力下的快速掃描。
Layer 1 最低限度試算表欄位：
欄位 範例值
─────────────────────────────────────────────
姓名 陳志明
頭銜 IT 專案經理
部門 資訊技術部
原型 Champion
主要顧慮 上線時程壓力、團隊學習曲線
決策影響力 3
情感傾向 +2（強支持）
預算簽署權 無（需 CFO 核准）
最後接觸日期 2026-05-28
參與狀態 已接觸
備註 協助安排 CFO 會議，下週回覆
Layer 2 — 生產就緒（Production-Ready）
做法： 在主要 Demo 之前，安排每個原型的獨立 1:1 探索電話（Discovery Call）。每通電話 30 分鐘，使用不同的問題框架，並根據 1:1 結果調整 Demo 的敘事重點。
Discovery Call 的問題框架（依原型）：
Champion 1:1 問題
「你在內部推動這個方案最大的阻力是什麼？」
「如果你需要向主管報告這個方案的價值，你會怎麼說？」
「除了你，誰還需要點頭這件事才能推進？」
Economic Buyer 1:1 問題
「成功對你的意義是什麼——3 個月後、12 個月後？」
「你目前最主要的業務壓力是什麼？」
「如果什麼都不做，6 個月後會怎樣？」
Technical Evaluator 1:1 問題
「你目前最擔心的安全或合規問題是哪幾個？」
「你的組織有哪些技術標準我需要符合？」
「你評估新系統時，什麼情況下你會說不？」
Blocker 1:1 問題
「我知道在這類專案中，[法務 / 採購 / 資安] 通常會有特定的前提條件，
你能告訴我你最需要確認的是什麼嗎？」
「如果我們能解決 [具體顧慮]，你的立場會如何？」
新增元件：
- Blocker 專屬 1:1，在主要 Demo 之前完成，不可跳過
- 針對 Economic Buyer 的 ROI 一頁紙（含 payback period 計算）
- Technical Evaluator 文件包（見上方清單）
- Demo 敘事校準：根據 1:1 結果調整切入角度
解決的問題： 主要 Demo 中不再出現「帶回去討論」的延遲；Blocker 的顧慮在水面下已被化解或其具體要求已被確認並納入提案。
代價/複雜度： 額外 3–5 個電話，約 5–8 工時。ROI 一頁紙撰寫 2–3 小時。加速成交週期 6–8 週，折算時間價值遠超投入。
適用情境： 合約金額 $100K–$1M 的中型客戶、競爭性採購、已知有多個利害關係人的情境。
Layer 2 的 Discovery Call 到 Demo 的完整工作流：
Layer 2 完整工作流（含時序）
第 1 週
Champion 1:1（60 min）
→ 輸出：影響力圖草稿、已識別 Blocker 清單
→ 動作：發送 Economic Buyer 會議邀請
第 2 週
Economic Buyer 1:1（30 min，Champion 協助安排）
→ 輸出：業務優先事項確認、ROI 一頁紙草稿方向
→ 動作：發送 Technical Evaluator 文件包
Technical Evaluator 1:1（60 min，可多人同時）
→ 輸出：技術要求清單、文件缺口識別
→ 動作：補齊文件缺口、安排 Blocker 1:1
第 3 週
Blocker 1:1（30–45 min，每個 Blocker 分開）
→ 輸出：具體反對理由書面記錄
→ 動作：在 Demo 敘事中加入回應；修改提案框架
Demo 敘事最終校準（內部對齊，30 min）
→ 確認每個原型的關鍵訊息和展示重點
第 4 週
主要 Demo（60–90 min，所有利害關係人參加）
→ 所有人已有基礎立場，沒有第一次聽到的顧慮
→ 輸出：行動清單、下一步決策時程確認
Layer 3 — 企業級（Enterprise-Grade）
做法： 建立正式的 Account Map 文件，版本控制於 CRM，共享給整個帳戶團隊（銷售、FDE、客戶成功、法務）。在整個銷售和交付週期中持續更新，設置季度 Executive Business Review（EBR）機制。
新增元件：
企業級 Account Map 完整結構
一、組織影響力圖
節點：所有利害關係人（含間接影響者）
邊：影響關係 + 強度
狀態色碼：綠（已對齊）/ 黃（仍存疑）/ 紅（阻擋中）
更新頻率：每次客戶接觸後 24 小時內
二、每人詳細頁面
- 主要顧慮（按優先順序排列）
- 已提供的回應（含日期與文件連結）
- 未解決問題（明確列出，不可模糊帶過）
- 風險等級（紅 / 黃 / 綠）與觸發條件
三、競爭情報欄位
- 現任廠商的弱點（客觀記錄客戶提到的痛點）
- 替換成本估算（遷移工作量）
- 客戶的 BATNA（最佳替代方案：繼續現狀 / 競爭對手）
四、成功指標共同定義
- 交付後 30 / 60 / 90 天的量化目標
- 由客戶方簽署確認
- 避免「這不是我要的」的合同後爭議
五、異動追蹤
- 組織變更（人員離職 / 新人到任 / 重組）
- 立場變化（從支持變懷疑的觸發事件）
- 新出現的利害關係人（後期才識別到的節點）
Executive Sponsor 對應機制： 對年度合約金額 > $1M 的策略型客戶，指定公司 VP 或 C-Suite 層級對應客戶的 CFO / CTO，建立跨越個別人員流動的組織層級關係。當 Champion 離職時，Executive Sponsor 的關係確保帳戶不歸零。
解決的問題： 客戶組織異動時帳戶關係不崩潰；競爭對手無法從組織邊緣（例如空降的新任 CISO）發動突襲；交付階段的期望管理有明確量化基準；帳戶知識不因 FDE 換人而流失。
代價/複雜度： 每月 4–8 工時帳戶維護；CRM 工具成本（Salesforce Account Plan 或 Notion 企業版）。適用於 ARR > $500K 的策略型客戶。
三層成本與效益對比：
層次 額外投入工時 工具成本/月 縮短成交週期 適用合約規模
─────────────────────────────────────────────────────────────────────
Layer 1 1–2 h $0 0–2 週 < $100K
Layer 2 7–11 h $0 6–8 週 $100K–$1M
Layer 3 8–12 h/月 $50–$300 8–12 週 > $500K ARR
換算：若一個 FDE 的日費率為 $1,500，Layer 2 的 10 工時投入成本約 $1,500。但縮短 6–8 週等同於讓客戶的 AI 系統早 6–8 週開始創造業務價值，而合約本身的延遲風險（流失給競爭對手）往往遠超 $1,500。投入產出比通常在 1:50 以上。
四、關鍵決策：為什麼選 Blocker 1:1 而不選繞過 Blocker
| 選擇 | 選 Blocker 1:1 的理由 | 不選繞過 Blocker 的理由 |
|---|---|---|
| 直接接觸 | 找到具體反對理由，可定向化解；讓 Blocker 感覺被尊重 | 繞過：他一定在最後一刻現身，且帶著雙倍阻力（技術反對 + 被忽視的情緒） |
| 成本比較 | 30–45 分鐘 1:1 電話 | 合約審查延遲 4–8 週，可能讓整個財年預算落空 |
| 翻轉條件 | 若 Blocker 的顧慮是組織政治（如既有廠商合約）且無法在技術層面解決，才考慮升級到 Executive Sponsor 層面處理 | — |
什麼情況下繞過是不得不的選擇： 當 Blocker 是組織內的「政治玩家」，其反對純粹出自個人利益（保護現有廠商合作關係帶來的個人回扣），且你無法透過技術論據化解，此時應透過 Champion 向 Economic Buyer 呈報問題，由 Economic Buyer 在組織層面裁決。但即使如此，也要對 Blocker 保持尊重，告知他問題已在另一層級處理，而非讓他在不知情的情況下被推翻。
五、常見錯誤與陷阱
| 錯誤模式 | 後果 | 正確做法 |
|---|---|---|
| 把熱情的窗口聯絡人當成決策者 | 投入 40 工時提案，預算持有人從未見過你，直接否決或延至下一財年 | 第一通電話確認：「這個規模的採購，最終核准層級是哪裡？需要哪些部門點頭？」 |
| 把 Demo 設計成單一敘事 | Technical Evaluator 在台下交叉手臂，Economic Buyer 對技術細節失去興趣，Champion 沒有可帶走的業務語言材料 | 為每個原型準備不同切入角度；Demo 前的 1:1 決定 Demo 的敘事重點 |
| 試圖繞過 Blocker | Blocker 在合約審查前一週發動否決，帶著強烈的被忽視情緒，化解成本是早期直接對話的 10 倍 | 主動安排 Blocker 的獨立會議，讓他感覺被尊重，點名具體顧慮並直接回答 |
| 忽略 CapEx vs OpEx 分類問題 | 財務部門在年度預算凍結後才介入，整個採購週期延至下一財年，損失 6–12 個月 | Discovery Call 直接詢問：「貴公司的 AI 投資走 CapEx 還是 OpEx？這對採購流程有什麼影響？」 |
| 以技術功能開場向 Economic Buyer 報告 | Economic Buyer 立刻分心，你的 30 分鐘被浪費在對牛彈琴 | 開場 30 秒只說業務結果：節省 $X / 年、收入增長 $Y、payback period Z 個月 |
| 識別一次就不再更新 | 關鍵 Champion 離職、CISO 換人、新 VP 帶來不同優先順序，帳戶關係從頭開始 | 每次客戶組織異動後 48 小時內更新 Account Map；季度 EBR 確認關鍵節點現狀 |
| 在提案完成後才安排 1:1 | Blocker 在提案審查中第一次提出根本性反對意見，需要大幅修改或重新啟動流程 | 在提案撰寫之前完成所有 1:1；提案是 1:1 結果的書面總結，不應有讓人驚訝的新問題 |
六、與其他核心主題的關聯
Part 9（資料主權 / Sovereign AI）：法務型 Blocker 最常提出的顧慮是跨境資料傳輸與 GDPR 合規。資料主權架構選擇（VPC Service Controls、Cloud KMS 客戶管理金鑰、台灣或歐盟區域隔離部署）直接決定你能否化解該阻擋——這是 Stakeholder Mapping 中技術能力與政治溝通最密切交織的場景，也是最能展示 FDE 跨域價值的時刻。能在 Blocker 1:1 中當場畫出資料流圖並指出哪一層加密的 FDE，和只能說「我們有 SOC 2 認證」的 FDE，在阻擋者眼中是完全不同量級的信任。
Part 20（RAG Triad Metrics）：Technical Evaluator 最常追問「你怎麼知道 AI 的答案是正確的」。提前準備 RAG 可觀測性儀表板截圖（Context Relevance、Groundedness、Answer Relevance 的 P95 數字）是向技術審查者快速建立信任的標準動作，比口頭保證效果強 10 倍以上，能讓對話從「能不能信任」轉移到「如何設定監控閾值」。
FDE Interview Guide Part 33–34（RKK 面試劇本）：Stakeholder Mapping 是 FDE 角色扮演面試的必考情境。考官會模擬「客戶窗口非常熱情但遲遲無法推進決策」的場景，測試你能否在 2 分鐘內診斷出「窗口無預算簽署權」的根本原因，並說明接下來的五個具體行動步驟（識別 Economic Buyer → 安排 1:1 → 建 ROI 一頁紙 → 重新安排 Demo → 調整提案時序）。
Part 6（Prompt Injection 防護）：當 Blocker 是 CISO 且顧慮是 AI 系統的安全性，主動出示 Prompt Injection 防護架構文件（輸入清洗層、輸出過濾層、紅隊測試報告、漏洞評分與修復紀錄）是向技術阻擋者建立專業信用的具體手段，把「安全疑慮」從開放性顧慮轉化為「已有書面緩解方案的已知風險」，讓 CISO 有辦法向他的主管交代。
Part 16（TTFT / 吞吐量優化）：Economic Buyer 通常不在乎 token/s 的數字，但 Technical Evaluator 和 CISO 型 Blocker 可能要求在生產負載下進行性能評估。提前準備 TTFT < 2s（P95）、吞吐量 > 100 QPS 的壓力測試報告，能在 Technical Evaluator 1:1 中提前消除「性能不確定性」這個常見的次要阻擋點，讓技術審查的焦點集中在合規和架構問題上。
七、面試一句話（Killer Phrase）
「Stakeholder Mapping 是在第一次正式會議之前，把所有能影響決策的人識別出來並分配原型——Champion 需要內部傳遞的彈藥，Economic Buyer 需要 $ 數字和 payback period，Technical Evaluator 需要主動提交的文件包，Blocker 需要被直接點名處理而不是被繞過。我的標準流程是：Discovery Call 結束後建立有向影響力圖，確認預算持有人、CISO 型阻擋者、以及法務 / 採購型阻擋者是否都已被接觸；針對每個 Blocker 在主要 Demo 之前安排專屬 1:1，把顧慮從『資料主權或廠商鎖定』層面直接化解，不讓他在提案審查階段第一次現身。這個流程在實際客戶案例中把成交週期縮短了 6 到 8 週，因為主要 Demo 上所有關鍵人物都已有立場，消除了那種永無止境的『我需要把這個帶回去內部討論』的拖延循環。」
系列導航
