AI 電話通話轉錄稿：2026 技術主管 RFP 必問的 12 個供應商能力
TL;DR — 通話結束後留下的轉錄稿是 AI 電話導入後 6 個月內 ROI 最高的資料層，但前提是供應商在錄音格式、ASR 模式、speaker 對映、PII 遮罩、寫回 SLO 五件事上都做對。本文把這五件事拆成你簽約前該問廠商的 12 個 RFP 問題，並用業界公開的 WER 5–12%、DER 8–15%、P95 90 秒等基準犀點，告訴你哪個答案合格、哪個答案是紅旗。
為什麼通話結束後的轉錄稿是被嚴重低估的金礦
廠商型錄常把「通話錄音 + 轉文字」收在功能表的最後一行，描述用詞通常只有「自動轉錄」四個字。實際上這層是 AI 通話導入後 6 個月內最高 ROI 的資料層——前提是它做對了。
一通 AI 通話結束後，你會想拿這份轉錄稿做至少 5 件事：
- 教練面板——挑出客戶情緒滑落的對話片段，作為下次 coaching 的素材。
- QA 評分——抽聽 5–10% 通話、逐句打分，落地成季度 KPI（詳見 AI 電話主管即時監聽指南）。
- CRM 時間軸寫回——把通話摘要寫進客戶檔案，下個 touchpoint 的同事不必聽完整通電話。
- 合規 audit——每月批次掃描所有轉錄，驗證個資告知、AI 身份揭露、退出路徑等合規元素是否齊備。
- 產品反饋——客戶說「我想要 X、為什麼沒有 Y」這類句子，是產品團隊最高訊噪比的需求來源。
這 5 個用途共同的工程前提：你的供應商必須能可靠地分辨「這句話是 AI 講的、還是客戶講的」。聽起來簡單，但 90% 的 SMB 在這層就翻車——多半是因為廠商給的是單聲道錄音 + AI 推測式 speaker 分離，結果在情緒上頭、客戶 agent 同時開口的 0.5–2 秒重疊段，speaker 標記就一團糟。
差異化提示：本文是「通話結束後」的後製能力評估。通話進行中的 supervisor 旁聽與暖接手請見 AI 電話主管即時監聽指南；通話結果以標籤分流（answered／no_answer／voicemail／failed）請見 AI 電話自動化：通話結果分流。本文不是教你內部怎麼蓋這條管線，而是教你怎麼判斷外部廠商的這條管線值不值得簽約。
5 件你應該確認供應商有做的事
把下面這 5 件事當成 RFP checklist。每一件都有對應的測試方法與紅旗信號。
| 編號 | 必備能力 | 業界基準 | 紅旗信號 |
|---|---|---|---|
| 1 | 雙聲道（stereo）通話錄音 | Twilio／Vonage／Plivo 都把 stereo 列為標配 | 廠商說「我們只支持單聲道」或「stereo 是付費加購」 |
| 2 | 多通道（multichannel）ASR 引擎 | speaker error rate 0%（通道分離是物理事實） | 廠商強調 diarization 但避談 multichannel |
| 3 | speaker 對映寫死、不依賴 AI 推測 | 雙人通話固定對映，不靠機率模型 | 廠商說「我們的 AI 會自動分辨」 |
| 4 | 客戶真名 PII 遮罩 + 後段還原 | 個資法第 5、6 條的可驗證實作 | 廠商說「靠應用層權限控管就好」 |
| 5 | 通話結束 → 轉錄落地的 SLO | 業界合理目標 P50 60 秒／P95 90 秒 | 廠商不承諾 SLO、或說「視 ASR 引擎而定」 |
每一條都不是錦上添花，是後製分析能不能跑的根本前提。下面逐條展開。
💡 為什麼是 90 秒不是 30 秒？ 5 分鐘 stereo 通話的端到端 ASR 處理約 20–40 秒，加上 webhook ingress、檔案下載、寫入資料庫的時間，90 秒是合理但不寬鬆的 P95 目標。30 秒是「短通話 + 順風」情境，60 秒是 P50。如果廠商說「即時轉錄」但不肯給 P95 數字，那是話術。
第 1 件：stereo 錄音為什麼非要不可
這是整條後製管線的物理基礎。錯了這一步，後面 4 件事都救不回來。
單聲道 + diarization 為什麼會翻車
單聲道（mono）錄音檔把 AI 與客戶的聲音混在同一條音軌。ASR 引擎必須靠 AI 推測「這段是 A 講的、那段是 B 講的」——這就是 speaker diarization。
問題在重疊語音（overlapping speech）：客戶情緒上頭、AI 試圖打斷說明、兩個人同時說話 0.5–2 秒。即使是當前最佳的開源模型（Pyannote），在 VoxConverse 公開資料集上也有 8–15% DER（Diarization Error Rate）（Pyannote benchmark、VoxConverse Dataset）。
8% DER 意味著什麼？一通 100 句的對話，平均 8 句 speaker 標記是錯的。這 8 句若剛好落在「客戶說想退費／AI 說可以退費」這種句對上，audit 與 CRM 寫回就會變成系統性錯誤。每月 1 萬通就是 8 萬筆錯誤標記。
stereo 是國際業界標配
主流國際 API 通話平台都把 stereo 列為錄音標配。Twilio Programmable Voice 的 Stereo Recording 透過 RecordingChannels=dual 將 caller／callee 拆分到兩個獨立聲道（Twilio Recording docs）。Vonage 與 Plivo 也提供類似 boolean flag。
廠商的合格回答應該是：「我們預設啟用 stereo，左聲道是雲端到端點（AI 講的）、右聲道是端點到雲端（客戶講的）。」
RFP 問題 1：「請出示一個 stereo 錄音樣本」
直接要一份 .wav 檔。在電腦上用 Audacity 打開，看是不是兩條獨立波形。如果只有一條，廠商在話術。
⚠️ 單聲道是歷史包袋：很多 SMB 還在用 mono 錄音，理由通常是「過去做客服時為了省檔案大小」。stereo 檔案大兩倍但無法逆轉的重疊語音失誤值得這個成本——一個 5 分鐘 stereo .wav 約 5–10 MB，每月 1 萬通約 100 GB，雲端儲存成本不到 NT$100。對 audit 與 QA 的價值遠超過這個檔案費。
第 2 件：multichannel ASR vs diarization——你拿到哪一個？
stereo 錄音檔到手後，下一個工程選擇是「ASR 引擎用 multichannel 還是 diarization 模式」。這兩個模式很容易被廠商混為一談，但本質完全不同。
兩個模式的差異
multichannel 模式針對「每個聲道一位說話人」的 stereo 錄音檔做獨立轉錄，不依賴 AI 推測。diarization 模式則對單聲道做 AI 推測式 speaker 分離。
| 維度 | multichannel | diarization |
|---|---|---|
| 輸入 | stereo（雙聲道）錄音檔 | mono（單聲道）錄音檔 |
| speaker 來源 | 物理通道（deterministic） | AI 推測（probabilistic） |
| Speaker error rate | 0%（通道分離是物理事實） | 8–15% DER |
| 重疊語音 | 完全分離 | 失敗率高 |
| 適用情境 | 雙人通話 + stereo 錄音 | 多人會議 + mono 檔 |
| 計算成本 | 兩聲道分別處理（×2） | 單聲道（×1）+ diarization |
| 延遲 | 略長（多一個聲道） | 略短 |
實務上，AI 電話的雙人通話（AI + 客戶）情境，永遠選 multichannel。把 ASR 計算成本翻倍，換來 speaker error rate 從 8–15% 降至 0%，是非常劃算的交易。
RFP 問題 2：「你們的 ASR 預設是 multichannel 還是 diarization？」
合格回答：「我們預設 multichannel，diarize 只當 mono fallback 用。」
不合格回答：「我們的 AI speaker 分離很準。」——這代表他們在用 diarization，把 8–15% 的錯誤率包裝成 feature。
RFP 問題 3：「中文（zh-TW）的 WER 是多少？怎麼測的？」
主流中文 ASR 引擎在乾淨單聲道錄音條件下 WER 約 5–12%（Common Voice Dataset 13.0、Open ASR Leaderboard）。實際電話通話因為頻寬窄、背景噪音、口音，WER 通常落在這個區間的中上緘。
廠商若說「我們 WER 低於 3%」，要他們給測試資料集名稱與測試條件——10 之 9 是行銷話術或在某個 cherry-picked 子集上的數字。
RFP 問題 4：「我給你 100 通真實通話，你們的 WER 落在哪個區間？」
這才是真正的合約條件。要求廠商在你的真實通話樣本上跑出實測 WER，並把「WER ≤ 12%」寫進 SLA。
第 3 件：speaker 對映要寫死，不能靠 AI 推測
multichannel ASR 回來的結果含 channel 0／1 兩條轉錄。把 channel 對映到「AI」或「客戶」這一步，必須在通話 setup 時就寫死，不能事後讓 AI 模型猜。
為什麼不能靠 AI 推測
雙人通話的 speaker 對映是物理事實——錄音時哪一條音流是雲端送出去的、哪一條是端點傳回來的，平台層完全知道。讓 AI 推測等於放棄這個確定性，引入沒必要的錯誤。
廠商該給的對映規則應該長這樣：左聲道 = 雲端送出（AI 講的），右聲道 = 端點回傳（客戶講的）。寫死、永不變動。
RFP 問題 5：「在你們的後製管線裡，speaker 對映是寫死還是 AI 推測？」
合格回答：「在錄音 metadata 寫死，不依賴模型。」
不合格回答：「我們會自動判斷。」——這代表他們把確定性問題推給機率模型。
RFP 問題 6：「邊界情境（3 人會議、AI 對 AI、stereo flag 漏設）的 fallback 是什麼？」
合格回答應該包含三層：
- 3 人以上同線：stereo 只有 2 聲道、不夠用，回退到 mono + diarization 並在通話 metadata 標記。
- AI 對 AI（測試或 escalation 串接）：兩聲道都是 AI，需在 metadata 標記避免污染分析。
- stereo flag 漏設：回來的 channel 數會是 1 而不是 2，自動 fallback 到 mono diarization 並在 ops log 記錄 warning。
✅ 判斷標準：要求廠商出示一份「sanity check 規則表」——即使 stereo flag 漏設這種沉默錯誤也能被偵測、不會連續發生而沒人發現。沒有這層校驗的廠商，過幾個月後你會發現某個通話批次的 speaker 全部標反了。
第 4 件：客戶真名 PII 遮罩——這是 RFP 紅線
這是技術主管最容易忽視的一條，也是法遵團隊最會打回票的一條。
為什麼 ACL 不夠
很多廠商的回答是：「轉錄稿存在資料庫裡，我們用權限控管誰能讀。」這是把雞蛋全放在 ACL 這一籃裡。
問題是 ACL 漏一次（誤設、誤部署、admin 自己看、資料庫匯出檔被偷），客戶真名就外洩。轉錄稿同時包含客戶身份 + 通話細節（病史、財務狀況、糾紛內容），是個資法第 6 條意義下的特種個資組合，這比一般 PII 更敏感。
合格做法是 defense-in-depth
廠商該做的是：在 ASR 完成、寫進儲存層之前，把轉錄文字裡的客戶真名替換成占位符號。需要還原時（在 supervisor 介面顯示給授權使用者看），才從聯絡人資料表拉真名替回去。
中間的 supervisor、教練、QA、合規 audit 人員看到的，全是占位文字。即使資料庫匯出檔外洩，外洩的也只是占位符號。
法律基礎：
- 通保法第 29 條的一方同意原則允許錄音與後製分析（通保法第 29 條）。
- 個資法第 5 條要求個資處理「不得逾越特定目的之必要範圍」（個資法第 5 條）。轉錄稿的目的是品質分析，不需要客戶姓名，所以該遮蔽。
- 個資法第 6 條把醫療等資料列為特種個資原則禁止處理（個資法第 6 條）。對醫療美容、健康險、長照業務，遮蔽姓名是降低法律風險的可驗證實作。
RFP 問題 7：「轉錄稿存進資料庫之前，客戶真名有沒有遮罩？」
合格回答：「寫入前替換成占位符號，UI 渲染時才從聯絡人資料拉真名替回。」
不合格回答：「我們用權限控管。」
RFP 問題 8：「請出示一筆儲存層的轉錄樣本（去識別化版本）」
直接要一筆從資料庫匯出來的轉錄紀錄。如果裡面真名直接出現，這條 RFP 不過。
第 5 件：寫回 SLO——下個同事打開客戶頁面前資料要到位
這是把後製管線從「技術 demo」變成「業務可用」的最後一哩。
90 秒是業界合理目標
通話 hangup webhook 觸發 → 轉錄稿落地 → CRM 時間軸寫回，整段端到端的合理 SLO：
- P50 60 秒：一半的通話該在 1 分鐘內完成所有寫回。
- P95 90 秒：絕大多數通話 1.5 分鐘內。
- P99 180 秒：極少數長通話或 ASR 排隊延遲。
超過 90 秒會發生什麼？下個 touchpoint 的同事打開客戶頁面時，看到的時間軸沒有剛剛那通電話的摘要，整個體驗就破了。客服 agent 會習慣性地等 5 分鐘再開檔案，反過來拖慢回覆速度。
RFP 問題 9：「通話結束到轉錄落地的 P50／P95／P99 是多少？」
合格回答：「P50 60 秒、P95 90 秒、P99 180 秒，並把這三個數字寫進 SLA。」
不合格回答：「即時。」「視 ASR 引擎而定。」「依網路狀況。」——這是不肯背數字。
RFP 問題 10：「SLO 違反時的補償機制是什麼？」
要進服務等級協議。沒有違約條款的 SLO 是裝飾品。
你應該要求供應商儲存的欄位
廠商儲存的轉錄資料結構決定你後續分析的天花板。要的不是看到他們的資料表設計，而是確認以下能力：
| 能力 | 為什麼需要 | 怎麼驗 |
|---|---|---|
| 逐句（utterance）拆分 | 整段 transcript 沒法做句級 QA 評分 | 要求出示一筆樣本：每筆是 1 個 utterance 還是整通整塊？ |
| speaker 標記欄位 | 沒有 speaker 標記等於沒拆分 | 樣本要有 speaker 欄位 + 取值範圍清楚 |
| 時間戳記（timestamp） | 教練面板要倒帶 30 秒 | 樣本要有起始秒數欄位、精度 ms 等級 |
| 信心分數（confidence） | 低信心句子需要人工複審 | 樣本要有 0.0–1.0 的 confidence 數字 |
| 全文檢索能力 | 跨通話搜「想退費」「為什麼沒有」要 ms 等級回應 | 要求 100 萬筆資料量下的檢索延遲承諾 |
| PII 遮罩欄位 | 確認儲存的版本是去識別化的 | 樣本裡的客戶真名應該不可見 |
RFP 問題 11：「給我看一筆轉錄資料的 schema 文件 + 一筆樣本」
合格回答：條列每個欄位的型別、約束、用途，並附一筆去識別化的真實資料。
不合格回答：「客製化開發」「依客戶需求調整」——這代表他們沒有積定 schema、未來升級會踩坑。
5 個下游用途——把每個用途轉成 RFP 問題
把上面的 11 個問題答對之後，5 個下游用途各對應一個工程接點。把這張表貌進 RFP，逐個對廠商提問。
| 用途 | 對廠商的問題 | 合格答案的關鍵字 |
|---|---|---|
| 教練面板 | 「能不能在主管介面把 30 秒片段標記成 coaching note？」 | 倒帶 + 標記 + 寫進獨立資料表 |
| QA 評分 | 「能不能對抽樣的逐句轉錄套 rubric 打分、做季度趨勢？」 | 抽樣 + rubric 欄位 + 季度報表 |
| CRM 時間軸寫回 | 「通話結束後 90 秒內，CRM 時間軸是不是已經有摘要？」 | webhook + 90 秒 SLA + 摘要欄位 |
| 合規 audit | 「能不能每月批次掃描所有轉錄、找開頭 60 秒缺漏的合規句？」 | 個資告知 + AI 揭露 + 退出路徑 |
| 產品反饋 | 「能不能批次掃描客戶說『想要 X／為什麼沒 Y』、tag 進產品反饋池？」 | LLM tagging + dashboard |
教練面板：跟主管即時監聽是同一張表的兩個讀取窗口
通話進行中的主管即時監聽（in-call observability）與通話結束後的教練面板（post-call coaching），共用同一份逐句轉錄資料，只是讀取窗口不同。in-call 是即時串流、post-call 是完整檔。詳見 AI 電話主管即時監聽指南。
對 AI 電話 vs 真人 ROI 對照 的「教練閉環 ROI 量化」，本文是原始素材的供應端 RFP 規格。
QA 評分：rubric 該包含什麼
每月抽 5–10% 通話的逐句轉錄，套 QA rubric 打分。Rubric 欄位至少包括：
- 開場合規：個資告知、AI 身份揭露、錄音告知。
- 事實準確率：AI 回答產品／價格資訊有沒有 hallucination。
- 情緒處理：客戶情緒上頭時 AI 有沒有適當降溫。
- 退出路徑：客戶說「我不想聽」時有沒有立刻結束。
把分數落進獨立的 QA 資料表，做季度趨勢。要求廠商支持這四個欄位的批次評分介面。
CRM 時間軸寫回：90 秒是使用者體驗紅線
通話結束 90 秒內，後製管線跑完應自動把通話摘要寫進 CRM 時間軸。下個 touchpoint 的同事打開客戶頁面就能看到摘要，不用聽 5 分鐘錄音。
技術主管最常忽視的點：摘要的 LLM 模型用便宜的就好（gemini-3-flash 或同等），但合規 audit 與產品反饋 tagging 對精度敏感，建議用 frontier 模型。LLM 推論成本相比 ASR 是兩個量級，不必省這層錢。
合規 audit：用轉錄稿驗證答錄機偵測
每月批次掃描所有轉錄，找出每通開頭 60 秒是否包含「個資告知」「AI 身份揭露」「退出路徑」三個必備句。這是個資法第 5 條的可驗證實作。
轉錄稿同時也是驗證答錄機偵測準確率的金標準資料——人工抽聽 200 通、對照系統的 voicemail／human 標記，計算 false positive／false negative 率。詳見 AI 電話答錄機偵測：為什麼台灣 AMD 失效。
產品反饋：客戶的「為什麼沒有」是金礦
客戶在通話中說「我想要 X、為什麼沒有 Y」這類句子，是產品需求最高訊噪比的來源。每週批次跑 LLM 對轉錄做模式比對，把符合條件的句子打 tag、寫進產品反饋池。產品 PM 季度 review 直接看 dashboard。
Handoff 接點
通話中升級到真人時的 context preservation——詳見 AI 客服轉真人 handoff 設計——的「30 秒倒帶聽」也是從同一份逐句轉錄資料取最近 30 秒渲染卡片。in-call handoff 與 post-call 分析共用同一份資料，差別只在窗口長度與 hydration 時機。
「轉錄稿不是廠商型錄上的『支持自動轉文字』，是你後續 6 個月所有資料層的最大公因子——廠商沒做對，後面每個分析都會被噪音污染。」
常見問題
雙聲道錄音是不是檔案大兩倍、儲存成本翻倍？
差不多兩倍。一個 5 分鐘 stereo .wav 約 5–10 MB（取決於 codec 與取樣率）。每月 1 萬通約 100 GB，雲端儲存成本不到 NT$100。把重疊語音失誤從 8–15% 降至 0% 與這個檔案費比，CP 值非常高。把「stereo recording 必備」列為 RFP 否決條件。
如果廠商只給單聲道錄音，能不能補救？
只能用 diarization 走 backup 路徑、接受 8–15% DER。長期建議要求廠商升級到 stereo recording，否則所有後製分析都帶系統性 speaker 標記噪音。短期應急可以接受 mono fallback，但要在合約裡寫明 stereo 升級的時程承諾。
multichannel 跟 diarization 可以同時開嗎？
可以，且建議都開。主流 ASR 引擎容許同時設 multichannel 與 diarize：multichannel 處理 stereo 主要路徑；diarize 作為 mono fallback——若 stereo flag 漏設、或檔案只有 1 聲道時，diarize 提供 backup speaker 推測。生產環境建議兩個 flag 都開。
zh-TW 轉錄的 WER 期望值是多少？要怎麼自己評測？
主流中文 ASR 模型在乾淨單聲道錄音條件下 WER 約 5–12%。實際電話通話因為頻寬窄、背景噪音、口音，WER 通常落在這個區間的中上緘。自己評測的 SOP：抽 100 通真實通話、人工標註 ground truth 轉錄、跑 jiwer 或類似工具計算 WER。重點不是絕對數字，是「升級模型後的相對改善」與「你的專有名詞失誤率」。
客戶真名遮罩的合格做法是什麼？
在 ASR 完成、寫進儲存層之前，把轉錄文字裡的客戶真名替換成占位符號。讀取時在 UI 渲染端從聯絡人資料拉真名替回。中間的 supervisor、教練、QA、合規 audit 看到的全是占位文字。defense-in-depth 的精神：即使權限控管失效，外洩的也只是占位符號。
通話結束到轉錄落地的 SLO，業界合理數字是多少？
P50 60 秒、P95 90 秒、P99 180 秒。要進 SLA、要有違約補償。沒有違約條款的 SLO 是裝飾品。
轉錄稿要不要全文檢索？性能怎麼承諾？
要。教練、QA、產品反饋三個用途都需要跨通話搜「想退費」「為什麼沒有」這類關鍵字。要求廠商在 100 萬筆資料量下保證 ms 等級的檢索延遲、並支持中文斷詞。沒有這層能力的後製管線，第二個月就會被 PM 與主管放棄使用。
後製 LLM 跑轉錄做摘要要選什麼模型？
對 5 個下游用途分別不同：摘要寫回 CRM 用便宜的 chat model 即可（gemini-3-flash 或同等）；合規 audit 與產品反饋 tagging 對精度敏感，建議用 frontier 模型（gpt-4o、gemini-2.5-pro 之類）。LLM 推論成本相比 ASR 是兩個量級，不必省這層錢。
想看完整 AI 電話導入路徑、選型方法與產業案例？閱讀本系列的支柱長文 AI 電話行銷完整指南。也可看 Brightalk.ai AI 電話功能介紹 與 AI 電話方案。