測試競品客服，最該先決定的是什麼？
先決定你要用結果做哪個決策。是要調整自己的客服流程、重寫售前說明，還是判斷對手在哪類問題上撐不住？決策不同，要問的問題、要測的管道、要記的欄位都不同。沒有決策目標的神秘客測試，最後只會得到一疊「對手回得比我們快」或「對手語氣比較好」的感想，無法使用。
這是一份設計書的公開版本。原始版本是我們替一家提供企業雲端備份服務的公司所寫，委託方想知道兩家主要對手在售前客服的表現。公司名稱、產品細節與測試結果都已移除，只保留設計方法。
設計原則：五條先講清楚的界線
動手設計之前，我們先和委託方確認五條界線。任何一條不同意，我們就不接。
- 只問一般潛在客戶會問的問題。不問對手的內部價格策略、員工資訊、系統架構或任何營業秘密。
- 不冒用真實公司或真實個人。測試人員以個人身分詢問，或以虛構但不對應任何真實企業的情境詢問，不使用他人名片、統編或電子郵件網域。
- 不耗用對手過多資源。每個管道的測試次數有上限，不安排需要對方派員到場或製作正式報價書的情境。
- 錄音錄影依法處理。是否能錄下通話或對話，須依測試所在地的法規判斷，由委託方的法律顧問確認後才決定。預設只做文字筆記與聊天紀錄存檔。
- 結果只用於改善自己。不公開發表對手的客服表現，不用於廣告比較，不轉給第三方。
第二條和第三條最常被挑戰。委託方曾問，如果用公司名義詢問，對手會不會回得更認真？可能會。但冒用身分的風險，遠大於多得到的資訊。至於測試規模，我們的經驗是，每個管道八到十二次，已經足以看出模式。再多，就開始變成干擾。
步驟一：從決策目標反推測試問題
委託方的決策目標是：要不要把售前技術諮詢從業務部門移到客服部門。所以他們想知道，對手是由誰回答技術問題，回答的深度如何，以及什麼時候會把問題轉給業務。
從這個目標，我們設計了三層問題。
| 層級 | 問題類型 | 想觀察什麼 |
|---|---|---|
| 第一層 | 基本規格，例如支援哪些作業系統、資料存放地區 | 第一線能否直接回答 |
| 第二層 | 情境問題，例如某種備份頻率下的還原時間 | 是否需要轉介，轉給誰 |
| 第三層 | 邊界問題，例如服務不適用哪些情境 | 是否願意誠實說不適合 |
第三層是我們特別加的。一個客服團隊願不願意告訴潛在客戶「這個情境我們不適合」，往往比回答速度更能看出它的訓練方向。
步驟二：設計腳本，但不要寫死
每個測試情境都有一份腳本。腳本包含三部分：測試者的背景設定、開場問題、可能的追問路徑。
背景設定要具體但虛構。例如：「一家約四十人的設計工作室，目前用外接硬碟備份，想改成雲端，擔心大型檔案的上傳時間。」這個設定沒有對應任何真實公司，但足夠讓對方的客服判斷需求。
追問路徑寫成分支，而不是固定順序。如果對方第一句就問預算，測試者要知道怎麼回應；如果對方直接丟一份規格文件，測試者要知道接下來問什麼。我們通常為每份腳本準備三到四個分支，其餘讓測試者自然應對。
腳本寫完後，先拿委託方自己的客服測一次。這一步有兩個目的：確認腳本在真實對話中跑得順，也讓委託方先看到自己的基準線。
步驟三：選管道與時段
同一家公司，不同管道的客服表現常常差很多。我們這次測了四個管道：官網即時聊天、客服信箱、電話專線、社群私訊。
時段要分散。每個管道至少涵蓋平日上班時間、平日傍晚、週末各一次。很多團隊的差異，集中在非上班時段。只在週二上午測，得到的是對手最好的一面。
每次測試之間至少間隔五個工作天，同一個測試者不重複詢問同一家公司。這樣做是為了避免對方察覺，也避免同一個客服人員被重複測到，讓樣本失去代表性。
步驟四：評分表怎麼設計才不會變成主觀印象？
只記錄可以觀察到的行為，不記錄感受。「語氣親切」是感受，「第一句回覆有沒有確認對方的需求」是行為。我們最後用的評分表有八項，每項都是是非題或可以計數的事實。
- 首次回覆時間，以分鐘計
- 第一次回覆是否回應了問題本身，而不只是罐頭訊息
- 第一層問題是否由第一線直接回答
- 第二層問題是否被轉介，轉介給誰，轉介後多久有回應
- 回答中是否有可查證的具體資訊，例如文件連結或數字
- 第三層問題是否得到「不適合」或「有限制」的誠實回答
- 對話中是否主動詢問聯絡資料，在第幾輪
- 對話結束時，是否說明下一步
兩位測試者分別記錄，事後交叉核對。兩人記錄不一致的項目，回看對話紀錄後再決定。這一步會花時間，但能大幅減少「我覺得」的成分。
步驟五：寫下測試者的停止條件
每份腳本的最後，都有一段停止條件。遇到以下任何一種情況，測試者要禮貌結束對話，不再追問。
- 對方要求提供公司統編、合約或正式文件才能繼續
- 對方提出安排業務拜訪、線上簡報或試用帳號開通
- 對方開始透露明顯屬於內部的資訊，例如內部折扣規則或其他客戶名稱
- 對話已超過預定的輪數上限，通常是八輪
第三種情況最需要練習。測試者可能覺得意外收穫很珍貴，但對方的客服人員可能並不清楚自己說了什麼。這類資訊我們不記錄，也不寫進報告。停止條件寫在腳本裡，是為了讓測試者不必在當下自己判斷。
測試者本身也要準備。我們會先做一次半小時的說明，讓測試者理解決策目標、五條界線與評分表。測試者不需要是業界專家，但要能自然地扮演背景設定裡的角色，不刻意刁難對方。
步驟六：分析時要避開的三個陷阱
把單次表現當成常態
某次對手的即時聊天回得特別好，可能只是剛好遇到資深人員。我們只報告在多次測試中重複出現的模式，單次觀察放在附錄。
把回應速度當成服務品質
回得快不等於回得好。這次測試中，有一個管道的首次回覆很快，但多數是自動回覆，真正的回答反而比較慢。評分表把「首次回覆」和「實質回覆」分開，就是為了這個。
用對手的表現直接決定自己的做法
對手把技術問題交給客服，不代表委託方也該這麼做。對手的客群、產品複雜度、人力結構都不同。測試結果是參考，不是答案。
交付給委託方的是什麼？
我們交付三樣東西：一頁摘要、一份模式分析、全部的原始紀錄。
一頁摘要只回答委託方最初的決策問題。這次的摘要大意是：兩家對手都由客服處理第一層問題，第二層問題的轉介方式不同，其中一家轉介後的回應時間明顯拉長。第三層問題，兩家都傾向迴避。摘要的最後一段，是對委託方自己客服的建議，而不是對對手的評論。
原始紀錄會去除對手客服人員的姓名與任何可識別個人的資訊。我們觀察的是組織的流程，不是個別員工的表現。
這些做法在哪些情況下不適用？
第一，如果對手的客服只服務已簽約的客戶，沒有對外的售前管道，就沒有可以合法測試的對象。這時不應該為了測試而簽約或冒用客戶身分。
第二，在高度管制的產業，例如金融或醫療，客服對話可能涉及法規要求的身分驗證或紀錄保存。神秘客測試的設計須先由熟悉該產業法規的專業人士審閱，本文的做法不能直接套用。
第三，如果委託方的真正問題是自己的客服品質，先做內部檢視通常更有效。測對手之前，不妨先測自己。
第四，當市場上只有一兩家對手，而且彼此高度熟悉時，測試很容易被察覺。這種情況下，結果的參考價值會下降，也可能影響雙方關係，需要更審慎地評估是否值得進行。