多語客服術語表怎麼建？統一產品名與常用說法

從高頻詞盤點、正式名稱與例句，到負責人、新舊詞並存及真實詢問回饋，建立能持續維護的多語客服用語表。

多語客服用語表的目標，不是把每個字逐一翻譯，而是讓產品名稱、流程稱呼與答覆方式在不同語言裡指向同一件事。先整理高頻且容易造成誤解的詞，再補上使用情境、責任人與更新規則，詞表才會被團隊持續採用。詞表也要兼顧地區習慣與客服實際場景。

挑出需要固定翻譯的詞

先從客人真的會看到或聽到的詞開始，不必一開始收錄所有內部術語。把網站頁面、介面按鈕、訂單通知、客服範本、操作文件和客服常見詢問逐一掃過，圈出同一概念出現不同寫法的地方。產品名稱、功能名稱、方案名稱、流程節點、欄位名稱、常見錯誤訊息通常值得先列；只有工程內部使用、客人不會接觸的代號，可留在內部字典，避免外部詞表膨脹。

再用兩個標準排序：出現頻率，以及用錯後會不會讓客人做錯事、找不到功能或誤解下一步。把高頻、高影響的詞放在第一批；偶爾出現且不影響操作的描述，先收進待觀察區。每個候選詞寫清楚它代表的概念，而不是只抄字面，例如「退貨申請」是流程入口，「退款進度」是申請後的狀態，二者看起來相近，實際上不應共用一個翻譯。

跨語言盤點時，也要記錄詞出現的位置和受眾：介面需要短而可辨認，客服說明需要自然完整，教學文章則可以多交代背景。同一名稱若因欄位長度而縮寫，仍要留下完整名稱及縮寫規則。表格可先設欄位：概念、目前用法、出現位置、語言、使用者疑問、影響程度、處理優先順序。把同義詞、拼字差異和只在特定地區使用的說法分開記，避免把不同概念誤當成翻譯不一致。

實作時，可先沿著一個完整任務走一次，例如從查詢訂單、查看狀態到聯絡客服，記下每個畫面如何稱呼同一物件。再把兩種語言並排，標註是同一概念的異寫、翻譯差異，還是其實代表不同狀態。這個步驟能避免只看搜尋結果就把相似詞合併，也能讓優先順序對應到真實操作路徑。

記錄正式名稱與禁用詞

正式名稱要先定義成一個可查詢的概念，再為每種語言記錄團隊認可的寫法。詞條至少包含：概念說明、繁中正式名稱、其他語言的正式名稱、詞性或格式、可接受變體、禁用詞、適用範圍、例句、確認人與最後更新理由。產品名稱保留原文或採在地寫法，也要記下大小寫、空格、標點和是否翻譯；若有多種形式，說明哪一種用在介面、哪一種用在客服敘述。

以下為假設例子，示範同一個概念如何把可用說法和禁用說法分清；實際詞條應依產品定義調整。

禁用詞不用堆成黑名單。每個禁用項目要寫明原因，例如容易誤認成另一個流程、超出目前承諾、或是特定語言中語氣生硬，再提供可替代的寫法。不要只寫「不要用快速」；補上應使用「處理中」或「已完成」取決於實際狀態，避免客服為了避開舊詞而各自創造新詞。若差異只是風格偏好，標成建議而非禁用，並保留討論紀錄。這能讓翻譯者理解邊界，不必猜測什麼都算錯，也讓後續新增語言沿用同一判斷依據。

同一詞若有產品內部正式拼法，優先保存其不可改動部分；一般名詞則按語言習慣調整，不必為了字面一致犧牲清楚度。另記語言代碼和地區，避免把繁體中文視為單一寫法。詞條更新時保留前一版本與修改原因，遇到舊文件或客人引用時，維護者便能判斷應套用別名還是修正文句。

補上情境例句與差異

詞對詞對照只能建立入口，真正的等值關係要看使用情境。每個詞至少配一條短例句，指出說話者、對象、渠道、流程狀態和希望讀者採取的動作；再補充不能套用的情境。例如「確認」可能是請客人核對資料，也可能表示團隊已完成查核，若只收一個對譯，按鈕和客服句子就容易把誰要行動說反。例句要貼近實際句型，讓撰寫者看得到詞和上下文如何搭配，而不是只看到字典裡的單字。

可用成對例句呈現差異：介面按鈕寫「查看退款進度」，讓人知道下一步是查詢；客服回覆寫「我們已為你查詢退款處理進度，目前畫面顯示處理中」，只敘述已確認的狀態，不把它改寫成「退款已完成」。若另一種語言習慣先交代對象或主詞，例句可調整語序，但要保留同一個承諾範圍和動作。

每條例句都應標記可改寫部分和不可更動的核心：稱呼、語氣可按渠道調整；產品名、狀態含義、操作步驟則需一致。若市場用語不同，分別列出地區標籤及適用位置，不要把一地常見的說法當作所有語言使用者都自然。可請熟悉該語言的同事朗讀客服句，檢查是否自然、是否可能被理解成保證或命令，再由產品或流程負責人核對事實。修改例句時同步檢查相關按鈕、文章標題和範本，避免詞條寫得正確，實際回覆仍沿用舊句。對有多種可能解讀的字，可把詞放進一個真實句子，請另一人說出他理解的流程及下一步；若答案不同，就補明確說明或拆成兩條詞。例句應標明版本日期，免得流程改變後仍引用舊說法。

指定詞條確認負責人

每個詞條都要有最後決定者，否則遇到兩種合理譯法時，會由最先修改文件的人自行定案。可按詞的性質分工：產品負責人確認功能與狀態定義；客服或營運負責人確認常見說法是否能直接回答問題；具該語言能力的人檢查自然度與地區差異；內容維護者則把核准結果同步到詞表和使用中的素材。角色可由少數人兼任，但決策責任仍要明確寫在詞條或流程說明中。

建立簡單提交格式，讓提議者提供原詞、所在畫面或對話、建議用法、修改原因、影響語言及需要完成的時間點。審核時依序確認概念是否相同、詞彙是否符合正式名稱、例句是否自然，以及現存介面、範本、說明文件會否因此互相矛盾。意見不同時，先看使用者可能採取錯誤動作的風險，其次看一致性，最後才處理個人風格偏好。

詞多時可以按主題或語言分派審閱，但要保留一位整體維護負責人，負責處理跨類別衝突、提醒未決項目和確認已核准變更有同步到位。審核紀錄可精簡為日期、決定、負責人、理由與受影響素材，不必要求冗長會議。小團隊可用共享文件加指定審閱者；更新前先用待確認標記區分提案與正式詞，避免未核准寫法被複製到新回覆。負責人離開或無法處理時，備援人要接手尚未定案清單，不能只交出檔案連結。完成核准後，由內容維護者回報已更新的位置，讓提出者知道變更已進入可用素材。可約定定期檢視未決項目，並在產品名稱或流程改變時立即觸發，不必讓小修訂等到大型整理。

處理新舊說法並存期

新詞採用後，舊說法不一定能在同一天從所有頁面和客服範本消失。先設定詞條的狀態，例如「提案中」「已核准、待同步」「可並存」「已停用」，並指定哪些地方需要遷移。新介面、新文章和新範本一律採用正式名稱；舊頁面若仍被搜尋或引用，可在一段過渡期保留舊詞作搜尋別名，並在主要文字中清楚指出新名稱。別名只能協助找到內容，不應造成兩個名稱看似兩種功能。

並存是否需要，取決於舊詞是否仍可幫助理解與搜尋、修改會否影響操作、以及維護者能否追蹤兩種說法。若舊詞曾使客人選錯流程，就應優先更正關鍵入口及客服範本；若只是舊文件常見縮寫，可保留索引或括號註記，逐步更新一般內文。每筆過渡安排列出新詞、舊詞、允許出現的區域、負責人、檢查條件和預計重新檢視的時點，避免「先暫時留著」變成永久雙軌。

切換時要檢查翻譯記憶庫、常用回覆、搜尋標籤、教學截圖與內部培訓資料；能批次替換的內容先由人確認語意，不能只做全域取代，因為同一舊詞可能在不同句子指向不同概念。完成後用新詞和舊詞各搜尋一次，查看是否仍有會誤導使用者的入口。達到事先約定的條件，例如主要入口已更新、客服能辨識舊詞且搜尋仍能導向正確頁面，再將舊詞改為停用；若條件未達成，就指出缺少的素材和下一位負責人。

對外發布新詞前，列一張素材清單並逐項檢查；若某渠道暫時無法修改，記錄原因、替代說法和重新檢查條件。這樣客服能解釋差異，維護者也不會把待更新頁面誤標為已完成。

用真實詢問更新詞表

詞表要從真實詢問更新，但客服個案不能直接等同通用詞條。定期檢視已處理的對話，先移除姓名、聯絡方式、訂單識別碼等個人資訊，再判斷問題源自詞彙不一致、流程本身不清楚，還是個別情境特殊。若多人把「啟用」理解成完成設定，但團隊用它表示只打開功能，就需回看定義和例句；若只是單一錯字或罕見個案，記入素材修正即可，不必為每句話增加詞條。

每次提案附上去識別化的原句片段或摘要、客人實際想完成的事、目前詞條和建議修改、可能受影響的語言與渠道。由客服確認問題是否重複出現，由流程或產品負責人判定詞義是否改變，再由語言審閱者核對新寫法。核准後更新詞條、例句和被引用的回覆範本，並保留舊寫法的搜尋別名或停用理由。追蹤時不只看用詞有沒有一致，也看搜尋是否更容易找到答案、客服是否仍需重新解釋；如果變化無法歸因，就不要把結果說成某次翻譯必然帶來改善。

可先挑一個常被問到的功能或流程，整理一小組詞條，再用最近的匿名詢問檢查它們是否足以支援回答。從案例得出的修改應留下足以重現判斷的脈絡，但不複製整段對話。可記錄當時流程狀態、原詞造成的理解、改後詞條與核准依據；再由另一位客服用新例句試讀，確認詞表能支援相似問題，而不是只修好原個案。若使用者表達習慣與團隊預設不同，也要保留原話類型作為觀察線索，不急著將少數說法納為正式標準。下一步是選定這個試行範圍，建立第一批正式名稱與例句，並到ReplyBot 官網了解相關內容。