要用 AI 分析銷售通話轉錄，先由一份已核查權限、有版本號的轉錄和一個小型業務語境包入手。把需要、問題、異議、產品主張、承諾和跟進事項擷取到一張證據表。每一項都附上說話者和時間戳，把詮釋與觀察到的原話分開標示，並把不確定或影響重大的事項交給帳戶負責人。AI 可以準備一份可審核的草稿；它不應為人評分，亦不應把未經核實的結論寫進 CRM。

一般的 AI 使用指南解釋了安全輸入和人手審批。如果你仍需先製作轉錄，請在開始本分析前使用另一個音訊轉錄與字幕流程。

關鍵要點

核實錄音、轉錄、分析、保留期限和服務供應商方面的權限。

凍結轉錄版本、Call ID、說話者、時間戳和已知缺口。

使用已界定的分類架構，而不是要求一次不設限的「銷售分析」。

把觀察到的原話、詮釋和未解決的問題分開。

對照真正的負責人和系統核實產品主張與承諾。

不推斷情緒、性格、誠信、意圖或僱員表現。

每個 CRM 欄位和跟進行動都須經帳戶負責人批准。

銷售通話分析的交付物應該是甚麼？

銷售轉錄分析不是為通話評分。它是一份結構化的證據索引，協助團隊找出說過甚麼、哪些內容需要核實。交付物應回答實際問題：客戶描述了甚麼問題？明確提到哪些限制？哪個問題仍未獲回答？有沒有人作出承諾？哪項跟進有具名負責人？

同一句話可以支持不同的詮釋。「我們需要在續約前處理好」包含時間方面的字眼，但不能證明預算、迫切程度、決策權或購買意向。保留原話，讓帳戶負責人按具體情況判斷其含意。

不要把這項工作與指導或監察混在一起。轉錄中可能既有客戶亦有僱員，分析結果可能影響僱傭或商業決定。讓目的保持狹窄，拒絕未經批准的次要用途。

第 1 步：確認目的與權限

記錄通話為何錄音、轉錄為何可以分析、誰可看到結果、哪家服務供應商可以處理、每份副本保留多久，以及結果可否進入客戶系統。與負責私隱或法律的團隊一同核對適用的法律、合約、公司政策和通知內容。

英國資訊專員辦公室（ICO）表示，監察僱員必須合法、公平、透明，與清晰的目的掛鈎並合乎比例；僱員應能理解並質疑會帶來後果的資料。［1］這份指引針對特定司法管轄區，但只要通話紀錄中出現僱員的話，其中有關目的和公平的問題便是有用的控制點。

建立一份通話控制紀錄：

欄位	記錄內容
Call ID	穩定、無法識別身份的參考編號
已批准目的	例如為跟進作準備
參與者	角色標籤，不寫不必要的個人資料
錄音通知	許可證據的來源和日期
分析許可	容許的工具、工作空間和資料類別
保留期限	轉錄和工作檔案的刪除日期
結果受眾	有業務需要的具名角色
決策負責人	批准 CRM 修改和對外聯絡的人

如果計劃中的分析擴展至表現監察、情緒評分或其他商業目的，便停下來，重新申請審查。已能存取某段錄音，並不代表可以把它用於所有可能的用途。

第 2 步：最小化轉錄與語境

只傳送已批准任務所需的資料。刪除無關的寒暄、登入憑證、付款資料、健康資料、私人聯絡資料、私人連結和其他敏感數值，除非它們必不可少而且獲明確許可。以穩定的說話者標籤取代姓名。

ICO 的資料最小化指引指出，個人資料應當充分、相關，並只限於所述目的所需的範圍。［2］轉錄文字越多，並不自動代表分析越好；反而可能增加私隱風險，並令模型被無關細節分散注意。

使用 AI 私隱風險指南檢查服務供應商的設定、保留期限、存取控制和刪除方式。把原始轉錄留在受管治的系統，只給模型一份受控的工作副本。記錄任何可能影響理解的刪改。

第 3 步：凍結質素與業務語境

分析由質素檢查開始，而不是由寫提示開始。確認 Call ID、錄製日期、轉錄版本、語言、說話者對應、時間戳涵蓋範圍和已知缺失部分。標示多人同時說話、低可信度轉錄、翻譯內容和不清楚的產品名稱。

然後提供一個精簡的語境包，只包含經核實的事實，例如帳戶階段、已批准的產品術語、現行計劃邊界，以及團隊希望回答的具體問題。不要寫入「證明這是一個好機會」之類的期望結果，因為這會令擷取出現偏差。

語境欄位	安全的內容
分析問題	明確提到了哪些需要和跟進事項？
分類架構版本	已批准的類別和定義
產品參考	功能和限制的現行來源
帳戶語境	經核實的階段和過往承諾
排除項目	情緒、性格、表現、預測
輸出負責人	帳戶負責人和必需的審核人

說話者不確定時，使用 SPEAKER-UNKNOWN。欠缺時間戳時，記錄 timestamp unavailable。虛假的精確比清晰可見的缺口更差。

第 4 步：定義提取分類與欄位

在閱讀模型輸出之前選定類別。一個實用的分類架構可以包括：需要、現行流程、限制、問題、異議、決策準則、產品主張、客戶承諾、銷售方承諾、風險和跟進事項。為每個類別下定義，讓審核人對同一段落的分類保持一致。

不要為推斷出的情緒、性格、可信度或購買可能性設立類別。這些標籤難以驗證，亦可能把記錄筆記的工作變成人物側寫。同樣，不要把說話時長、打斷次數或用字作為隱性的僱員表現指標。

每一條擷取紀錄都應包含：

欄位	必填內容
證據 ID	穩定的紀錄識別碼
Call ID 與版本	來源通話和轉錄修訂版
說話者與時間戳	證據的確切位置
轉錄摘錄	簡短而忠實的段落
證據類型	已批准的分類標籤
觀察到的陳述	明確說出的內容
詮釋	獨立、審慎的解讀
其他詮釋	合理的另一種解釋
核實需要	產品、帳戶、法律或時間方面的核查
負責人與期限	負責解決的人
CRM 目標	擬寫入的欄位（如有）
審批狀態	草稿、已核實、已否決或已批准

這張表可防止一段流暢的摘要掩蓋結論的出處。

第 5 步：用 AI 分析銷售通話轉錄，提取並逐項回查

要求模型只複製簡短的相關摘錄，附上說話者和時間戳，並在某欄位欠缺證據時傳回 not stated。告訴它保留否定、條件、數量、日期，以及「可能」「如果」「未有」之類表示不確定的字眼。

逐條把摘錄與轉錄對照。常見錯誤包括：把提問者的問題歸到客戶身上、把假設變成計劃、合併兩位說話者、刪去條件，以及把「我們會調查」變成「我們會交付」。

讓「觀察」和「詮釋」兩個欄位保持獨立。觀察：「客戶說法律審核通常需時兩星期。」詮釋：「審核時間可能影響所要求的推出日期。」第二句有用，但它既不是引述，亦不是已確認的時間表。

第 6 步：驗證主張與承諾

銷售通話經常有需要外部核查的陳述。銷售人員可能描述某項功能，客戶可能提出某項要求，任何一方都可能建議某個日期。轉錄只能證明這些話曾經說過；它不能證明功能確實存在、要求已經完整，或日期可以達成。

設立不同的處理隊列：

產品主張： 對照現行文件或向產品負責人核實。
商務條款： 對照已批准的建議書，並向獲授權的負責人核實。
安全或合規主張： 轉交相關專家。
客戶承諾： 請帳戶負責人確認說話者的權限和原意。
銷售方承諾： 確定誰有權作出並履行這些承諾。
未知項目： 保留沒有證據支持的問題。

至於會出現在建議書或客戶訊息中的主張，使用事實核實流程。NIST 私隱框架提供一套自願採用的結構，用來識別和管理各類系統與資料處理中的私隱風險。［3］以這種管治角度分配責任和控制；不要讓處理轉錄的模型判斷是否合規。

第 7 步：生成不虛構承諾的銷售跟進項

只有經核實的證據才可成為擬議的跟進項。使用會議行動項流程中的行動欄位：行動、負責人、期限、依賴、證據和審批狀態。不要因客戶提到一個大概的時間範圍，便虛構一個截止日期。

好的擬議行動是這樣寫的：「由產品負責人核實需求 R-07 是否獲支援；證據 E-12；期限由帳戶負責人訂定。」差的行動則是：「星期五前確認實施」，但其實沒有人作過這樣的承諾。

如需較完整的敘述，先批准證據表，再使用筆記轉報告流程。報告應連結回證據 ID，而不是取而代之。

第 8 步：人手覆核 CRM

帳戶負責人應對照轉錄和相關業務系統，覆核每個擬寫入的欄位。獨立核實聯絡人角色、需要、階段、下一步、截止日期、產品興趣、風險和承諾。否決只以詮釋為依據的欄位。

對於影響重大的修改，例如商機階段、預測類別、法律狀態或向客戶公開的承諾，採用雙人覆核。給相關人士更正紀錄的途徑。保留擬議值、最終值、覆核人、時間戳和修改理由。

本流程不允許模型直接連接生產 CRM。匯出一份草稿表格，覆核後，經機構一般的存取控制寫入已批准的修改。如日後考慮自動整合，它需要另外的授權、欄位白名單、試行（dry run）、審計紀錄、還原設計和監察。

第 9 步：跨通話測試質素

擴大使用之前，先在一小組具代表性、已審核的轉錄上測試流程。量度欠缺的證據、說話者歸屬錯誤、類別錯誤、否定遺失、虛構的承諾，以及無根據的 CRM 擬議值。逐類審查；單一的整體準確率可能掩蓋高風險欄位中的失誤。

當分類架構、模型、提示、轉錄服務供應商、語言或 CRM 結構有變時，重複測試。保留困難的例子，例如多人同時說話、更正、含糊的時間範圍和有條件的產品陳述。如果合成測試已能檢驗相同格式，便不要重用真實客戶資料。

NIST 的生成式 AI 設定檔指出了虛構內容和私隱問題等風險。［4］模型可能寫出一個連貫卻沒有通話根據的商業故事。可追溯性和人手覆核，正是令草稿真正有用的控制手段。

簡明提示詞契約

告訴模型：只使用所提供的轉錄和已核實的語境；保留 Call ID、轉錄版本、說話者、時間戳、否定、條件和不確定性；只按所提供的 taxonomy（分類架構）分類；把觀察到的陳述與詮釋分開；欠缺的事實傳回 not stated；標示不清楚的段落；不得評判情緒、性格、誠信、表現、購買機率或權限。要求輸出表格，而不是具說服力的敘述。

最終檢查清單

錄音和分析許可涵蓋這家服務供應商、這項目的和這些受眾。
工作用轉錄已最小化、去識別化、有版本號並經質素檢查。
每條紀錄都有 Call ID、說話者、時間戳或明確的缺失標記，以及摘錄。
觀察到的陳述與詮釋和其他詮釋保持分開。
產品主張、商務條款和承諾都經獨立核實。
沒有出現情緒、性格、表現或購買機率評分。
跟進項有人手負責人，而且沒有虛構截止日期。
CRM 數值在模型以外經覆核和批准。
分類架構、測試集、提示和覆核決定都有版本紀錄。

常見問題

所有人同意錄音就夠了嗎？

不一定。還要確認轉錄、AI 分析、所選的處理方、保留、共享和預定用途，亦符合適用的規則和通知內容。

可以讓 AI 評估客戶情緒嗎？

本流程不會這樣做。情緒標籤難以驗證，會失去文化和對話語境，亦可能導致人物側寫或帶來後果的判斷。

模型需要完整帳戶歷史嗎？

不需要。只提供回答分析問題所需的最少已核實語境，並刪除無關的個人或商業資料。

沒有時間戳怎麼辦？

把它標為不可用，並使用其他穩定的定位方式，例如行號範圍。不要虛構時間戳，亦不要暗示比轉錄實際更高的精確度。

轉錄能證明產品有某項功能嗎？

它只能證明有人提過這項功能。要對照現行產品文件或向負責人核實該能力及其條件。

AI 可以選擇最佳銷售動作嗎？

它可以按明確的證據整理擬議行動。選擇行動之前，帳戶負責人必須考慮背景、權限、政策和客戶利益。

可以直接更新 CRM 嗎？

在本流程中不可以。匯出擬議值，逐項覆核，然後由獲授權人士經一般控制寫入已批准的修改。

多語言通話怎麼處理？

保留原文摘錄，寫明翻譯方法，請精通該語言的人審核重要術語，並讓翻譯後的詮釋一直與來源連結。

誰對最終分析負責？

具名的帳戶負責人對業務詮釋和 CRM 交接負責；涉及私隱、產品、法律或安全範疇時，相關審核人亦要參與。

來源

UK Information Commissioner’s Office — Data protection and monitoring workers — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/data-protection-and-monitoring-workers/
UK Information Commissioner’s Office — Principle (c): Data minimisation — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/
NIST — Privacy Framework — https://www.nist.gov/privacy-framework
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 分析銷售通話轉錄：證據表與 CRM 人手審批