FDE 交付手冊

▸ 開始之前

這份教材要把你訓練成什麼

你將負責把一套 AI 覆蓋層方案，從走進客戶辦公室到交接撤出，完整跑完一次。 這份手冊照著實際專案的順序寫：先理解方案在賣什麼（第 0-1 節）， 再學會怎麼診斷與估算（第 2 節），然後是實際的導入、交付與維運（第 6-10 節）。

你的角色：交付型 FDE

這個角色不負責報價與成交，但你必須知道公司賣了什麼給客戶—— 因為你的交付要對得起那個承諾。承諾與交付對不起來時， 站在客戶面前解釋的人是你，不是簽約的人。

決策權界線

這張表是這份手冊最該背起來的一頁。做錯事的成本，遠低於越權做對事的成本—— 前者可以修，後者會讓公司對客戶的承諾出現兩個版本。

四週訓練路徑

0 核心論點

價值分兩層

這兩層的金額量級差很多，提案時必須分開講。混在一起講，會讓小的那一層去背大的那一層的數字。

1 架構：AI 覆蓋層

哪些動作其實是「寫入」

這套架構不修改 ERP 的資料結構，但它不是全程唯讀。以下三件事本質上就是寫入行為， 提案時要主動說明，不要等業主自己發現。

三層橋接（依開放程度遞增）

橋接層決定了通知能多快

層 1 是批次匯出，通知延遲 ≈ 匯出排程間隔 ＋ 處理時間。 如果 ERP 一天只排三次匯出，就不可能做到「10 分鐘內收到庫存預警」。 這是架構決定的，不是調參數能解決的。因此所有即時性的驗收條件都依橋接層分別定義：

2 FDE 五步工作法

FDE 的核心工作流程，從進入客戶現場到完成交付，每一步都有明確的產出與檢查點。 這五步是你日常工作的骨架，之後每一節都掛在這五步的某一步底下。

Step 1 深層：診斷真實業務

Step 2 深層：估算 ROI

先過風險閘門，再打分

風險不是拿來加權的，是拿來否決的。把風險當成權重項會有一個致命後果：一個高頻、有數據、好衡量的流程（例如自動退款），就算風險項拿最低分，加總後仍可能排第一名被選中。以下三題只要中一題，這個場景本階段直接不做，不進入評分。

五條件評分矩陣（通過閘門者才打分）

每項打 1、3、5 三檔（避免不同人對 1-5 的認知不同），加權後滿分 45 分。

ROI 計算公式

實例：客服自動化 ROI（第一層，員工工時）

第二層：老闆時間的真實單價

目標客戶的定義是「年營收破億、10 人以下」，也就是人均產值 NT$1,000 萬以上。這種公司的老闆，時間單價和客服人員完全不是同一個量級：

損益平衡點（提案時直接給業主看這一行）

這個門檻對客服人員時薪（$200）來說過不了，對老闆時間（保守 $1,000）來說綽綽有餘。 所以提案的說服重點不是「省了幾個客服」，而是「哪些事情從此不必經過你」。

還有兩項效益，能算但別亂算

Step 3 深層：接入真實系統

Step 4 深層：設計人機協作

Step 5 深層：推動組織採用

3 提案大綱

以下為遞交給業主的提案書章節結構。你不會單獨寫這份提案書，但其中大部分章節的內容由你產出—— 你交出的診斷資料與試算，會被組成這份文件送到客戶手上。

哪幾章是你的產出

4 目標客戶畫像

這一節是背景知識，篩選客戶不是你的工作。 但你要知道自己會走進什麼樣的公司——這決定了你在現場會遇到什麼。

客戶從哪裡來（背景）

這個規模的客戶主要來自會計師事務所轉介、ERP 經銷商合作、既有客戶轉介三個管道， 由公司的業務端負責開發。你需要知道的只有一件事： 進場前先問清楚這個客戶是怎麼來的。

5 診斷工具與商務背景

前半是你每天要用的工具：初診單與基線量測清單。 後半是你要看得懂但不能自己決定的東西：定價與商務條件。

初診單

基線量測清單（Phase 0 必做，不是選配）

初診單問到的是「感覺」，驗收要的是「數字」。這兩者之間必須有一週的實測。 否則到了第 12 天業主問「所以到底省了多少」，你只能拿估算值回答， 而估算值不能簽驗收單。

客戶會問你的問題

初診與導入期間，客戶會當面丟這些問題給你。先確認這一題是不是你能答的—— 下表最右欄就是判斷依據。答錯的代價不是丟臉，是公司對客戶出現兩個版本的說法。

定價框架（背景知識）

定價不是你的工作，但你必須知道客戶買了哪一個級距—— 因為那決定了你能交付多少東西。接到案子的第一件事， 是問清楚這個客戶簽的是哪一種，以及範圍寫到哪裡。

這個結構對你的三個影響

6 導入路徑

這一節是你的日常。Phase 1 的 12 天你會親手跑過很多次，把它背下來。

Phase 0：初診與基線量測（1 次拜訪 ＋ 1 週實測）

訪談只能拿到「感覺」，報價需要「數字」。Phase 0 是訪談加實測兩件事，不是只喝一次咖啡。

Phase 1：快贏（2 週 / 12 個工作天）

目標：不改 ERP、兩週內交出一條完整可驗收的管線。

第一週：管線打通 ＋ 知識庫 ＋ 分類校準

• D1 — 存取盤點與可行性確認
  確認拿得到哪些資料，以及拿不到哪些
  盤點 ERP 可匯出的報表與格式、排程能力、落在哪一個橋接層。同時確認客服對話的匯出可行性：Line OA 與 FB 的訊息匯出能力、可回溯期限、需要哪些權限審核。這一項如果過不了，D3 的知識庫就沒有原料，必須當天改用替代來源（如既有 FAQ 頁面、Email 記錄）。
• D2 — 自動匯入 Pipeline
  ERP 報表自動讀取 → 結構化儲存
  建置定時排程：ERP 產出 CSV → Agent 自動抓取 → 解析 → 寫入可查詢的資料庫（SQLite/Turso）。之後所有自動化都從這裡讀資料。含失敗重試與斷線續跑。
• D3 — 知識庫建置
  歷史對話 → TOP 20 FAQ ＋ 政策規則
  匯出歷史客服對話，用 LLM 分群提煉高頻問題，人工覆核後成為 FAQ。加上退貨政策、運費規則、保固條件、發票流程。
• D4 — 渠道串接
  訊息統一收斂到 Agent
  串接客戶主要渠道（Line OA 優先），建立統一訊息佇列。此時尚未自動回覆，只是把訊息接進來。
• D5 — 意圖分類校準 ＋ W1 回顧
  用真實資料定出信心值閾值
  拿 Phase 0 標註好的 200 則真實對話跑分類，畫出各閾值下的準確率與涵蓋率，據此決定自動／半自動／轉人工的兩道分界線（不是直接套用預設值）。當天與業主回顧本週進度並確認下週節奏。

第二週：影子模式 → 分批放行 → 驗收

• D6-9 — 影子模式試營運
  AI 起草，員工按送出，逐筆收集誤判
  AI 對每則訊息產生建議回覆，但一律由員工審核後才送出。每天檢視誤判案例並修正知識庫與 prompt。這四天不會省到人力，反而多花約 20 分鐘/天——這件事必須在簽約前就跟業主講明白，否則第 7 天你會收到「怎麼還變慢了」的抱怨。
• D10 — 異常偵測通知上線
  營運指標異常自動推播
  比對同一星期幾的近 4 週基準（不是比昨天），偏離幅度超過設定值才推播。含增減幅度、可能原因提示、異常明細連結。閾值以「每週警報數不超過 3 則」為校準目標。
• D11 — 分批放行自動回覆
  只放行高信心的類別
  先開放「訂單查詢」「商品詢問」兩個全自動類別，其餘維持影子模式。觀察一天，確認高信心分支沒有錯誤送出。
• D12 — Phase 1 驗收
  用 Phase 0 的基線對照實測結果
  拿出 Phase 0 的基線數字與這兩週的實測數字並排比較，逐項核對驗收條件，簽署 Phase 1 驗收單。若未通過，依合約的驗收未通過條款處理（見第 10 節）。同時討論 Phase 2 要做哪 2-3 條管線。

Phase 2：核心管線（W3-W8，選做 2-3 條）

下表列出每條管線的真實工期。依 Phase 0 的五條件評分排序，只做前 2-3 名， 不要全部排進去——這也是第 2 節 Step 5 的採用心法：不要一次推全部。

管線 C（SOP Agent）的三個風險

這條管線的第一個動作是錄員工的螢幕，選它之前先想清楚以下三件事。

Phase 3：規模化與撤出（W9-W12）

7 基礎建設與法遵

前半是你要向客戶要的東西，後半是資料怎麼處理。 後半這一節出錯的代價最高，而且錯了通常補不回來，請完整讀完。

D1 起算日定義

簽約日不等於 D1。D1 起算於下表所有 P0 項目全部完成、並經雙方書面確認之日。 這一條必須寫進合約，否則前置作業一延誤，責任會算在你頭上。

前置作業的交期不是零，實務上通常是這樣：

• 向 ERP 廠商申請唯讀帳號或設定定時匯出，要走報價、簽約、排維護窗口，以週為單位，而且經常另外收費
• Line OA 的 Messaging API 需要認證帳號，FB Page 的訊息權限需要平台端的權限審核，兩者都有等待期

業主端準備事項

我方部署架構

資料處理與法遵

這一節是給業主的會計師和法務看的。年營收破億的公司多半有配合的事務所，他們會逐條問。

資料流向：哪些會送到模型，哪些不會

需要在提案書寫死的六件事

對終端消費者的 AI 揭露

這件事會直接影響「客戶滿意度」這項效益。 消費者以為在跟真人講話、事後發現是機器人，滿意度不會上升，會下降。

• 自動回覆開頭或帳號說明處明示為自動客服，並提供「轉真人」的明確指令
• 轉人工後，明確告知已由真人接手
• 簽約前先確認 Line OA 與 Meta 平台當前的自動化訊息規範，兩家的規則都在變
• 若客戶有歐盟消費者，需另行確認歐盟 AI 法規對聊天機器人的揭露義務

責任與賠償

8 技術橋接作法

Playwright 這一列不是「3-5 天做完就結束」

它是四個選項裡維護成本最高的，成本結構和前三列完全不同：

• ERP 改版、欄位位移、session 逾時、加了二階段驗證，每一次都會讓它壞掉
• 壞掉的時間點通常是客戶最忙的時候，而且沒有錯誤訊息告訴你為什麼
• 可能違反 ERP 廠商的服務條款，簽約前請先確認合約文字

報價方式要跟前三列不同：建置費之外另計較高的月維護費， 或直接在合約寫明「ERP 介面變動導致的重做，依人天另計」。

9 電商客服 AI 流程設計

針對電商場景的客服自動化完整設計。適用於 Line OA / FB Messenger / 網站聊天 / Email 四種渠道。 這是你最常交付的一條管線，本節的每一個細節都會在現場用到。

整體架構

Step 1：意圖分類（AI 判斷客戶想幹嘛）

Step 2：知識庫設計

知識庫是客服自動化的核心 — AI 回覆的品質完全取決於知識庫內容。

兩個前提要先確認，否則這一步從第一天就卡住

Step 3：自動回覆邏輯

決策樹（每則訊息）

分成三段而不是兩段。只設一個門檻的話，中間那段模稜兩可的訊息 （在實際流量裡通常佔一到兩成）會落到某個預設分支，而你不會知道是哪一個。 中間帶必須明確定義為「AI 起草、人按送出」。

1. 意圖分類（訂單查詢 / 商品 / 退貨 / 發票 / 客訴 / 其他）
   │
2. 依信心值分三段（分界線由校準決定，非預設值）：
   │
   ├─ 高信心（≥ 上界）  → 自動送出，事後抽查
   ├─ 中信心（兩界之間）→ AI 起草，客服一鍵送出或修改後送出
   └─ 低信心（< 下界）  → 純轉人工，附 AI 猜測的意圖與信心值
   │
3. 高信心的自動分支：
   ├─ 訂單查詢 → 查 ERP → 生成回覆（含訂單狀態＋物流連結）
   └─ 商品詢問 → 查知識庫 → 生成回覆（含商品連結）
   │
   ※ 退貨開單、發票修改一律走中信心分支（人按送出），
     因為它們會寫入系統，屬於不可逆操作
   │
4. 回覆後追蹤：
   ├─ 客戶若追問（同一話題）→ 再次 AI 處理（最多 2 輪）
   └─ 客戶不滿意／負面情緒 → 立即轉人工

閾值怎麼定：校準，不是套預設值

模型說 0.8，不代表它有 80% 的機率是對的。這個數字在不同任務、 不同提示詞下的意義完全不同，直接套用任何預設值都沒有依據，只是看起來合理。 兩道分界線必須從這個客戶的真實資料算出來。

D5 的校準程序

1. 拿 Phase 0 人工標註好的 200 則真實對話跑分類
2. 對每個候選閾值，算出準確率（判為自動的裡面有幾成是對的） 與涵蓋率（有幾成訊息進得了自動分支）
3. 上界取「準確率 ≥ 98% 的最低閾值」——自動送出的東西幾乎不能錯
4. 下界取「準確率跌破 70% 的閾值」——低於這裡，連當草稿都會浪費客服時間
5. 把兩個實際算出來的數字寫進交付文件，並在每次知識庫更新後重跑一次

回覆品質把關

Step 4：人工交接設計

「誤判」的定義（沒有這個定義就無法驗收）

驗收會同時要求「誤判率 < 10%」和「無錯誤回覆送出」。這兩句話若用同一個「誤判」字眼， 就互相矛盾——誤判率允許到 10%，就不可能保證零錯誤送出。 解法是把誤判拆成三種不同的東西分開量。

Step 5：導入計畫（＝第 6 節 Phase 1，同一份時程）

預期效益

「導入前」欄位一律填 Phase 0 的實測值，不可留白也不可用經驗值。 任何一項如果導入前是空的，這一項就永遠無法驗收—— 沒有對照組，就沒有「上升」可言。客戶滿意度最容易犯這個錯。

注意「員工每天客服工時」在 Phase 1 是持平或略增。 D6-D9 影子模式期間，員工要審核 AI 的每一則草稿，當週的工時會比導入前多。 這是正常的，也是必要的——這四天在做的事，是把 A 類錯誤壓到零。 這一點必須寫進提案書：如果業主以為第一週就開始省時間，第七天看到員工反而更忙， 你會被質疑整個方案。先講，是預期管理；後講，是解釋。

10 交付清單、驗收與維運

交付清單

每階段結束時必須交付的具體產出，逐項核對。

程式碼與智財歸屬

撤出條件寫的是「客戶可獨立完成日常維運」「完全自主運作」。 拿不到程式碼的客戶不可能自主運作，所以這三件事必須在合約寫清楚。

驗收標準

每個交付物必須滿足對應的驗收條件，業主簽字後才算完成。

寫驗收條件的四條規則

驗收條件寫不好，驗收就會變成走過場。以下四條是上表每一項的設計依據， 日後新增管線時照著套。

驗收未通過怎麼辦（合約必須寫）

只寫「簽驗收單才進下一階段」是不夠的，還必須寫沒簽成會怎樣。 留白對雙方都是風險：業主不知道能不能拿回錢，你不知道要無限期重工到什麼時候。

後續維運計畫

維運模式遞減

兩種維護方案的服務內容

服務時間定義

SLA 一定要先定義服務時間，否則「P0 兩小時修復」和「非營業時段隔日處理」會同時寫在合約裡， 而週六凌晨出事時，雙方各執一詞。
你要知道自己被排在哪個 SLA 裡，以及非服務時間發生 P0 時誰負責接。 沒有排班表就承諾 30 分鐘回應是空頭支票——寫得到卻做不到的 SLA，比不寫還糟。

緊急支援 SLA（時間僅於標準服務時間內計算）

撤出條件

當客戶滿足以下所有條件時，可終止維護合約，完全自主運作：

• 客戶指定窗口已能獨立完成日常維運（知識庫更新、異常通報、報表檢閱）
• 連續一個月無 P0/P1 事件
• 客戶內部已建立自主的知識庫更新機制
• 客戶已在自己的環境成功部署過一次，且能自行重跑意圖分類校準
• 客戶決定不再需要外部支援

撤出時交付最終版操作手冊、系統架構圖、Runbook、知識庫匯出檔、 原始碼與部署腳本、提示詞全文。

上列條件中，「能自己部署一次」是唯一真正驗證自主運作能力的一項。 其餘幾項在客戶還完全依賴你的情況下也可能成立。少了它， 「完全自主運作」就只是寫在紙上的話。

✓ 結訓檢核

四週訓練結束時，以下每一項都要由主管實測通過。 沒通過的項目不是重讀，是重做一次演練——這份工作的能力來自做過，不是讀過。

知識檢核（口頭回答，不看手冊）

• 說出這套方案的一句話定位，以及兩層效益各是什麼、量級差多少
• 說出三個橋接層的差異，以及各自能承諾的通知時效
• 說出哪三種動作其實是寫入，以及各自的控制方式
• 說出五條件評分的風險閘門三題，以及為什麼風險不能當權重
• 不看手冊講完 Phase 1 的 D1 到 D12
• 說出 A / B / C 三類誤判的定義，以及各自的驗收標準
• 說出寫驗收條件的四條規則
• 說出 P0 到 P3 的分級，以及 P0 發生時你的第一個動作

實作檢核（交出成品）

• 對指定案例完成五條件評分表，含風險閘門判定與加權總分
• 對指定案例完成兩層 ROI 試算與損益平衡點
• 從一份校準資料算出上界與下界，並說明依據
• 在測試環境建好一條資料匯入 Pipeline，含失敗重試，並通過壞檔測試
• 完成一份資料流向表，正確標示哪些欄位送模型、哪些在本地回填
• 寫出一份 Runbook，並由未參與的同事實測 30 分鐘內完成復原

判斷力檢核（角色扮演，最重要）

• 八題客戶提問，全部正確判斷「你答」或「轉主管」，且未說出任何金額或範圍承諾
• 面對「客戶要求調低閾值以提高自動回覆率」，正確拒絕並說明後請示
• 面對「客戶說不用簽委外處理協議」，正確回報而非自行同意
• 面對「D9 還有 2 筆 A 類錯誤，客戶催上線」，正確處置並請示
• 模擬 20 分鐘一線員工訪談，全程未問「你需要什麼」，並交出痛點清單與 AS-IS 流程圖