客服問題怎麼分類？建立能連到處理流程的意圖表

從客服來訊的處理決策出發，設計不重疊的意圖類別、未分類規則、樣本定義與小量試用方法，讓每個分類都能連到負責人和下一步流程。

客服分類的目的，不是替每則訊息貼上更多標籤，而是讓團隊能看懂顧客要完成什麼，並把來訊交給合適的人或流程。先定義要支援的決策，再整理類別、例子與分流方式，才能讓分類表成為日常工作工具。

分類要服務哪個決策

客服意圖表不是把每句話分到一個好看的主題，而是讓接手的人知道下一步要做什麼。開始前先寫下它要支援的決策：由誰接、查哪份資料、是否要補問，以及何時移交。若只記「訂單、付款、商品」等名詞，接手者仍須重新理解來訊，分類就沒有省下判斷。

把「談什麼」和「要完成什麼」分開。「物流」是主題；「查配送進度」是意圖；「核對訂單並回覆」才是處理流程。類別名稱要貼近顧客想完成的事，也要能連到一位負責人或一個明確步驟。這樣團隊回看分類時，才知道問題停在哪個處理環節。

設計每一列時，可一併填入意圖、觸發線索、下一步、負責角色與必要資訊。觸發線索描述顧客怎麼說，不能只列內部術語；下一步則用動詞開頭，例如查詢、確認、補問或轉交。若同一類別會交給不同人處理，應檢查是否其實包含不同意圖，或缺少能決定分流的條件。

先用這張表問一個實際問題：看到意圖標籤後，接手者能否不再猜測便開始處理？若答案是否定的，就要補上必要條件或調整分類。分類的品質看它能否減少重複判讀，而不是類別名稱是否整齊、數量是否充足。

類別如何避免重疊

類別會重疊，常是因為同一張表混用了不同分類軸：有的按產品主題，有的按顧客情緒，有的按處理結果。先選定主軸，通常以「顧客此刻希望完成的主要事情」作為意圖，再把語氣、來源、產品或緊急程度放到其他欄位。不同欄位各自回答一種問題，才不會讓同一則訊息同時符合好幾個類別。

接著替每個類別寫一句定義，包含「包含什麼」和「不包含什麼」。例如，「查配送進度」只收查詢貨件位置或預計到達情況的來訊；要求更改配送地址則走另一個意圖，因為它需要不同確認與處理步驟。定義裡要使用團隊看得到的線索，而非只寫「相關問題」這種無法判斷的描述。

遇到一則訊息同時提出兩個目標，先判斷它們能否由同一流程完成。若顧客說「幫我查訂單，也想改地址」，查詢和修改可能需要不同的資料或負責人，就記成兩個意圖，共用同一對話或案件識別。若兩句話只是同一目的的補充，不必硬拆成多筆，否則會增加交接成本，也不利於回看完整脈絡。

為容易混淆的類別各寫一組正例和反例，並補上一條優先規則。例如，顧客只問貨件在哪裡，歸進度查詢；若明確要求修改地址，則依修改流程處理。當線索不足以決定時，不要靠猜測強行選一類，而要使用補問或待判斷的狀態，並指出還缺哪個條件。

試讀分類表時，刻意拿相似句子成對比較：換了措辭但想完成的事情相同，標籤應相同；表面主題相似但下一步不同，標籤就要能分開。每次發現兩類都說得通，就回頭修定義、加入反例或調整分類軸，不要只要求標記者「記得選對」。

哪些來訊先列未分類

「未分類」應是可檢視的暫時狀態，不是把難處理的訊息永久丟進一個大籃子。先分清幾種原因：這是表裡尚未涵蓋的新意圖、缺少判讀所需資訊、超出目前受理範圍，還是同一則訊息含有多個目標。原因不同，下一步也不同，所以最好保留可辨認的狀態或註記。

如果顧客的目標已經明確，只是欠缺訂單號碼、品項或發生時間等流程所需資料，仍可先標記相符的意圖，再註記待補資訊。這樣負責人能依既有流程追問，不會把「知道要退款但還沒核對訂單」誤當成全新的需求。相反地，若來訊只有「想問一下」，連主題與目的都看不出來，才需要先補問再判斷。

新意圖則保留原始說法與處理結果，供之後檢視是否需要新增類別；不要因為一則罕見訊息就立刻擴張分類表。超出目前受理範圍的訊息也應另做標記，並清楚指定由誰判斷或如何回覆。把它們和資料不足混在一起，會讓團隊看不出是分類缺口、流程缺口，還是受理邊界需要說明。

若一則訊息包含多個目標，可以先保留對話脈絡，再按各個目標分開記錄；若目標不清或互相矛盾，先進入待判斷狀態，避免錯派後讓顧客重述。每個暫存狀態都要有回頭處理的人或時點，例如由值班負責人檢視，而不是任其長期停留。操作規則要讓第一線知道何時補問、何時轉交、何時暫存。

定期查看未分類項目時，先找出重複出現的說法、造成分流差異的缺失資訊，以及實際無法承接的請求。前兩者可能需要新增意圖或補足欄位，後者則可能只需改善說明或交接方式。只有當新類型有穩定的處理路徑，且與既有類別確實不同，才把它正式加入表格。

如何定義一筆樣本

樣本單位應配合你要檢查的決策。若目的是把來訊指派給負責人，一筆樣本最好代表一個可採取行動的顧客目標，而不是把整段對話不加區分地當成一類。對話可以作為保留上下文的容器；裡面的訊息則可能包含一個或多個意圖，應依實際需要分開記錄。

例如，顧客先說「訂單到哪了」，又補一句「地址好像也要改」。前句要求查詢，後句提出修改；若兩者要走不同步驟，就記成同一對話下的兩筆意圖樣本。若顧客接著補上訂單編號，那是查詢所需的資訊，不是新的意圖。這條界線能避免把每一句話都當成獨立案件，也避免把多件工作壓成一筆模糊紀錄。

每筆樣本至少保留足以判斷的原話片段、必要上下文、意圖標籤和預期下一步。可以再記錄判斷依據、待補資料或建議接手角色，讓其他人能理解標籤是怎麼來的。原話不必抄錄整段往返；保留能說明顧客目標的部分，並遮蔽與判斷無關的個人資訊，減少整理時不必要的資料暴露。

遇到語意依賴前文的訊息，不要只截最後一句。像「那可以改嗎？」必須連同前文才知道要修改地址、品項或付款方式；缺少關鍵上下文時，樣本應標示無法判定，不能用標記者的猜想補成事實。相反地，與目標無關的寒暄或重複提醒不需要拆成額外樣本，除非它改變了要採取的處理方式。

開始整理前，先讓參與者一起確認「一筆」代表什麼，再用不同長度、不同語氣的對話試分。若有人按單句計、有人按整段對話計，後續即使使用同一套標籤，結果也不能直接比較。把切分規則寫成例子放在分類表旁，新增樣本時照同一規則處理，才有一致的回看基礎。

何時拆分現有類別

拆分類別的判斷點，不是名稱太寬或大家提出更多細分點子，而是現有類別是否把需要不同處理方式的目標混在一起。若兩種來訊要查不同資料、交給不同角色、要求不同確認，或進入不同後續流程，拆分通常能改善分流。若只是用詞、語氣、入口或產品名稱不同，實際負責人和下一步相同，通常保留同一意圖，再用其他欄位記錄差異即可。

以「訂單問題」為例，它可能同時包含查配送進度和修改地址。前者要核對目前狀態並回覆，後者可能要先確認是否仍可修改，再交相關流程。如果團隊常把兩者交給不同負責人，或漏掉各自必要的確認，就有明確理由拆成兩類。若兩種說法最後都由同一人依同一資料完成，也沒有造成回報混淆，則不必為了分類看起來精細而拆開。

決定之前，收集實際被標記的例子，查看錯派、退回、補問或人工改標的原因。把例子按「顧客目標、所需資訊、下一步、負責角色」並排，確認差異是否會改變決策。不要只因類別名稱聽起來太籠統就拆分；先檢查能否透過定義、反例或補充欄位解決。若同一類別內的例子沒有穩定分界，新增子類只會把判斷變難。

新類別須有可辨認的線索、能與相鄰類別區分的定義，以及實際負責的後續流程。完成拆分後，更新正反例和交接說明，也記下舊類別如何對應到新分類。歷史資料不一定都能可靠重標；只有在原始訊息足以判斷、且回看能解決明確分析或處理需要時，才補標舊樣本，並保留無法判定的狀態。

若不同人持續把同一批訊息分到新舊類別，代表界線還沒說清楚。先回看定義與反例，必要時合併或改名，再觀察錯派是否減少。每次變更都記錄原因、生效版本與受影響的流程，讓接手者知道應使用哪一版規則，也避免表格改了、交接方式卻仍停留在舊分類。

分類表如何小量試用

試用時先選一小批能代表日常來訊、而且處理方式已清楚的樣本，涵蓋常見說法和容易混淆的邊界。初次不必讓分類表直接控制所有分派；可以先由負責人依表格判斷，再由原本熟悉流程的人核對實際應交給誰、要做什麼。這樣能在擴大使用前發現定義缺口，也不會把尚未確認的分類當成成熟流程。

試用前，替每個意圖指定負責角色、必備資訊、下一步與需要升級處理的條件，並先說明未分類項目由誰檢視。讓參與者只依照已寫出的規則判讀，遇到新說法就記下原句和疑問，不要在執行中口頭創造新類別。這些紀錄能區分是操作不一致、定義不清，還是流程本身缺少接手人。

回看時，不只問標籤是否選對，也查看分派後有沒有被退回、是否反覆追問同一資料、誰接到不屬於自己的工作，以及顧客是否需要重新描述目標。把問題連回分類表：若意圖選對但資料不足，調整必要資訊提示；若標籤正確仍派錯人，修正角色對應；若同一句話被合理地分進兩類，就補上排除條件或重新定義主軸。

每輪修訂只針對已觀察到的問題，保留舊例、修改原因與新版規則，再用相似樣本確認新定義能否穩定分流。當負責人能依表格採取下一步、常見邊界有一致判法，且暫存項目有人接手，就可逐步擴大使用。若錯派仍集中在少數類別，先修好那些路徑，再考慮擴大範圍，不要把更多樣本交給不穩定的規則。

下一步可以從近期來訊挑一小批，逐筆寫下顧客目標、預期負責人和處理動作，再用這六項問題檢查是否能分流。若想了解 ReplyBot，請前往ReplyBot 官方網站。