第 11 課 車廠 VoC：先管理預期，再把業務定義磨清楚

一個車廠客戶之聲專案的完整流程

一家車廠希望把分散在客服、銷售與售後管道的回饋整理成可用資訊。專案團隊從需求溝通開始，逐步確認業務定義，完成模型開發、私有化部署與報告交付。先看清整條流程，再確定每個環節由誰負責。

VoC 是 Voice of Customer，客戶之聲：把客服電話、潛在客戶追蹤、社群貼文、售後工單和經授權取得的公開討論整理成可用資訊。品質部門關注故障，行銷部門關注口碑，產品部門關注配置與體驗。同一個「做 VoC」的需求，可能對應三種不同決策。

六段工作，各有交付物

這六段工作可以由多人分工完成，每個環節都要有明確的負責人和交付物。

會上能判斷，承諾要有條件

既懂技術又懂業務的人，可以更快指出哪些可嘗試、哪些需人工支援、哪些缺資料。這裡要區分初步判斷與交付承諾：沒有代表性樣本和測試，不能當場保證準確率。

練習時，可以這樣回答：「歷史工單的觀點整理可以先試；涉及安全故障的判斷先由品質人員複核。請提供一批經授權的去識別化樣本，我們再確定涵蓋範圍、評價標準與本期目標。」會後把本期範圍、排除項、樣本來源、人工職責、驗收方法和變更處理寫下來，由雙方確認。

標籤定義是業務協作，不只是模型調校

同樣是服務態度不佳，購車階段可能歸銷售，保養階段可能歸售後。標籤需要明確含義、適用情境、包含與排除例句、相鄰標籤邊界和確認負責人。遇到同一表達被人工標成不同類別，先複查定義，再判斷是否需要改模型。

今天先做一步

用虛構車主回饋「買車時講得很清楚，第一次保養卻沒人解釋費用」，寫一張需求確認單和兩條標籤定義。分別列出銷售、售後想看什麼；寫明哪些欄位缺失時先待複核。

本章產物與驗收

• 一頁需求確認單：範圍、排除項、樣本、指標、負責人、確認日期齊全。
• 兩條標籤定義：都有正例、反例與邊界說明。
• 由另一位讀者按定義分類；如有歧義，記錄分歧並修訂，不能把分歧直接記作模型錯誤。