ChatGPT + Zendesk：起草客服工單回覆

簡而言之： 在Zendesk的工作流程中，ChatGPT應當扮演「起草助手」而非「自動回覆機器人」。把工單內容、你的政策原文與語氣要求交給它，它回傳一份草稿，再由客服人員編輯後送出。它的價值在於每張工單省下幾分鐘、以及口徑一致的品牌語氣——而不是一條無人值守的佇列。

客服佇列出問題，通常不是因為客服打字慢。而是因為同樣的二十個問題會以略有差別的措辭反覆出現，每一個都需要在週五下午四點從零開始寫出一份禮貌、準確、符合政策的回覆。這確實非常適合交給語言模型——但同時，這也正是「用不好就會最快速地損害客戶信任」的地方。本文將拆解：AI起草在Zendesk工作流程中究竟該放在哪個位置、真實可行的幾種整合方式、一個完整範例、與「把整個客服中心外包出去」之間的誠實比較，以及決定這件事是悄然獲益還是悄然埋雷的治理工作——客戶資料、API金鑰與政策準確性。

AI起草在客服工作流程中該放在哪裡？

有一條規則凌駕於其他一切之上：先起草，再人工審閱——絕不自動送出。 一份AI寫好後直接寄給客戶的回覆，等同於你的公司以正式名義、就自身政策做出的一份未經審閱的聲明。模型並不知道你的退款期限、當前是否正在發生服務中斷，也不知道這位客戶距離流失只剩三天。客服人員知道，或者能在幾秒內查到。

放對位置的話，助手應當位於「工單已指派」與「客服回覆」之間。客服打開工單時，已有一份草稿在等著：客戶的問題被重述、相關政策已被套用、給出了建議的解決方案，而且語氣已經調好。他的工作從「撰寫」變成了「查核與判斷」。在常規工單上，這能把一次六分鐘的回覆壓縮到九十秒；在複雜工單上，草稿直接捨棄，成本為零。

Zendesk自身也提供AI能力——智慧分類、回覆建議、AI專員等——但其可用性與命名會隨方案而異且變動頻繁，因此在動手建置任何東西之前，請先確認你訂閱的方案實際包含什麼。而本文描述的自建路線，價值在於你能完全掌控提示詞、語氣，以及模型被餵了哪些知識。

把ChatGPT接進Zendesk

並不存在一個官方的「Zendesk版ChatGPT」開關。真正存在的是三種實務模式，而大多數團隊應當從最簡單的那一種開始。

三種整合方式：手動、應用市集、還是API

手動，在瀏覽器分頁裡完成——客服把工單文字複製進一份儲存好的提示詞，再把結果貼回來。零建置成本、零憑證管理、立刻可用。但它的弱點同樣真實：無法規模化、依賴每位客服正確使用提示詞，而且它是最容易外洩客戶資料的模式，因為沒有任何人在控制「什麼被貼了出去」。作為為期兩週、用來判斷草稿品質是否夠用的試驗，它很合適；作為長期安排則很差。
Zendesk應用市集裡的第三方應用——Zendesk的應用市集中有第三方廠商提供的AI起草與摘要類應用，它們以側邊欄的形式出現在Agent Workspace中。這是最快的受控路徑：客服始終停留在Zendesk裡，管線建置由廠商負責。代價是你同時繼承了該廠商的資料處理條款與其分包處理方鏈條——這屬於資料處理協議（DPA）審查的範疇，而不是「安裝應用」這一次點擊可以帶過的。
基於Zendesk API的自建——最靈活的路徑。工單到達時由Zendesk觸發器或Webhook發出訊號，你的服務透過Zendesk REST API拉取工單及相關歷史，帶上你的提示詞與政策脈絡呼叫OpenAI API，再把結果作為內部備註寫回該工單。把結果寫成內部備註而非公開回覆，是整個方案中最重要的一個設計決定：它讓「誤觸自動送出」在結構上不可能發生，而不僅僅是「不建議這麼做」。

如何調校語氣、品牌口徑與政策準確性

單薄的提示詞只會產出那種人人都認得、卻沒人真正信任的、略帶機械感的平庸回覆。真正有效的提示詞包含四樣東西。角色與語氣：模型以誰的身分在寫、用什麼語域——「溫和但簡潔、不使用驚嘆號、道歉不超過一次」遠勝於「請專業一些」。被檢索到的事實：真實的政策原文、當前的物流時效、已知問題說明。一個在沒有被告知退款期限的情況下被問及退款政策的模型，會捏造一個聽上去合理的答案——而「看似合理但錯誤」正是客戶回覆中最糟糕的失敗形態。約束條件：絕不承諾退款、賠付、日期或例外處理；絕不陳述服務中斷的原因；對任何不確定的內容要標註出來，而不是含糊帶過。升級指令：如果工單涉及法律威脅、資料保護請求、無障礙投訴或情緒激動的客戶，就回傳一份簡短的人工交接說明，而不是一份回覆草稿。

第三項——被檢索到的事實——正是這類專案的正確做法通常是「圍繞說明中心與政策文件做一個小型檢索步驟」，而不是「把提示詞寫得更長」的原因。模型並不需要多聰明，它需要的是被告知事實，然後把它寫得漂亮。

一個完整範例：從工單到審閱後的回覆

一位客戶寫道：*「三週前下的單，到現在什麼都沒有，太誇張了，我要退款。」* 觸發器啟動。服務拉取該工單、從介接的電商系統取回該客戶的訂單狀態，以及說明中心裡的退款政策文章。提示詞要求：承認延誤但不找藉口、說明真實的當前狀態、嚴格按照政策原文套用退款規則、提供政策允許的那一種補救方案、不承諾任何送達日期。

三十秒後，工單上出現一則內部備註，內含一份四句話的草稿，語氣符合公司口徑，訂單狀態填寫正確，並有一行標註著[待查核：退款資格取決於是否已出貨]。客服核對這一處標記，發現訂單尚未出貨，刪掉那句含糊表述，補上一句模型無從得知的、關於該倉庫具體延誤情況的說明，然後送出。九十秒，而不是六分鐘——而且客戶收到的回覆，出自一位需要為它負責的人。

AI起草回覆 vs 完全外包的7×24客服中心

各自真正解決的問題——AI起草讓你現有的客服在他們本就要處理的工單上更快。外包客服中心改變的則是「由誰、在什麼時候」回覆。如果你的問題是單張工單的處理時長，起草有用；如果你的問題是凌晨兩點另一個時區的客戶來信時無人值守，起草完全幫不上忙。
涵蓋時段——起草助手的可用性，取決於是否有客服在審閱它的產出；一條沒人值守的佇列，無論草稿多好，仍然無人回覆。有人值守的客服中心涵蓋夜間、週末與國定假日——而對一家在亞洲多地做生意的公司來說，這意味著好幾套不同的假期行事曆，而不是一套。
成本形態——起草是一筆較小的、按用量計費的API成本，加上建置與維護的時間投入，並隨工單量成長。外包客服中心則是一筆更大、也更可預測的營運成本，它取代的是人力編制而非增強現有人力。兩者並非互相競爭的支出項——不少客服中心內部同樣在用AI起草。
判斷力與升級路徑——兩種方式都無法取代「能夠判斷何時該為一位重要客戶破例」的那個人。訓練有素的人工客服中心既帶有這種判斷力，也帶有一條通往你工程或客戶成功團隊的升級管道；模型不具備這種判斷力，也不該被賦予它。
語言涵蓋——模型確實能用多種語言流暢起草，這一點很有價值。但沒人能校對的流暢產出是風險而非功能：你無法審閱你讀不懂的東西。多語系客服中心提供的是母語審閱者——而這才是真正起作用的部分。

AI起草的侷限

有三種失敗反覆出現。政策漂移：模型拿到的是上一季的退貨政策，或者根本沒拿到，於是它自信地陳述了你並不提供的條款——這是商業問題、有時是法律問題，而不是品質問題。升級盲區：面對一封包含監管申訴或訴訟威脅的來信，它同樣會產出一份友善、看上去很得體的回覆，因為它最佳化的目標是「一份好回覆」，而不是「意識到此刻最正確的動作是先不回覆」。那條明確的升級指令正是為此而設。多語系審閱缺口：一份由模型起草的日文工單回覆，被一位不讀日文的客服「核准」送出，實際上並沒有被審閱過——審閱這一環變成了走過場。你支援哪種語言，就必須有讀得懂那種語言的人在流程之中。

還有一項更隱蔽的代價。整天只做「核准草稿」的客服，寫作能力會退化，也會逐漸察覺不出草稿中細微的錯誤。請輪換這項工作，並持續量測編輯率：如果客服在把大多數草稿推倒重寫，那麼提示詞或檢索環節是壞的，這個工具正在消耗時間而非節省時間。關於同一套「審閱與升級」紀律在內部情境中的應用，可參閱我們那篇用Slack建置IT服務台分流機器人的文章。

把這件事做對：資料處理、API金鑰，以及何時該讓IT介入

客戶資料離開了你的環境。 你傳送給外部模型的每一張工單，至少包含客戶所遇到的問題，通常還包含姓名、訂單細節，以及客戶自己選擇附上的任何內容——有時是他們本不該傳送的身分證件或支付資訊片段。三項實際可行的控制措施：在力所能及處，於呼叫前剝離或遮罩明顯的身分識別資訊；選擇一個你真正讀過而非想當然的資料保存與訓練條款所對應的API層級；並明文寫下哪些工單類別完全不進入AI處理。如果你受GDPR、PIPL、PDPA或類似法規約束，把客戶內容傳送給一個新的處理方是一項需要留痕的決策，而非實作細節——你的隱私權政策與處理方紀錄必須與你實際建置的東西一致。

API金鑰就是正式環境憑證。 一組OpenAI金鑰加上一組Zendesk API權杖，合起來即可讀取你的全部工單歷史。它們應存放在金鑰管理服務或平台的加密憑證庫中——絕不應出現在瀏覽器擴充功能、試算表、自動化工具的明文欄位或程式碼儲存庫裡。請把Zendesk權杖的權限收斂到能跑通的最小角色，按計畫輪換兩者，並記錄每一次呼叫，這樣當需要回答「我們傳送了什麼、什麼時候傳送的」時，不必動用鑑識式調查。

上線之後必須有人負責。 政策一變，提示詞就過期；說明中心的文章會逐漸漂移；而某個模型版本被下架的那天，你的起草品質會無聲地劣化。這屬於最普通的維運歸屬問題，也正是一支客服團隊獨自建置這套東西時最常缺失的一環。

這正是合作夥伴發揮價值的地方。博迅（Brocent）的AI+支援服務涵蓋使用情境梳理與整合實作本身；託管IT支援提供憑證管理、監控與變更管理，讓它能持續正常運作；而如果誠實的結論是「你需要的是佇列上有人，而不是更快的草稿」，我們的7×24多語系服務中心每年處理約15,000起事件，支援英語、普通話與粵語。自2007年在北京創立以來，博迅一直在亞洲各地承接託管IT與資安服務，總部設於新加坡，香港辦事處自2016年起營運。

常見問題

AI起草的回覆可以在未經審閱的情況下自動送出嗎？

不可以。哪怕是「簡單」工單、哪怕在非工作時間、哪怕設了信心分數門檻也不行。失敗案例雖然罕見但代價高昂——錯誤的政策承諾、對喪親或申訴來信的冷漠回覆、捏造的送達日期——而這些後果落在你的品牌上，而不是供應商身上。請把工作流程設計成「自動送出在結構上不可能」，而不是「不建議這麼做」。

如何把客戶個人資料擋在提示詞之外？

只傳送模型確實需要的最小資訊；在呼叫API前，對可以模式比對的識別資訊（卡號片段、證件號、地址）做遮罩；並把整類工單——涉及支付、健康或法律事務的——排除在AI處理之外。然後查核你所選的API層級及其保存條款，因為主管機關追問的是這項決策，而不是去識別化這個動作。

多語系工單怎麼辦？

模型能用多種語言寫出很有說服力的草稿，但只有當審閱者讀得懂時，這份回覆才算被審閱過。要麼為你支援的每一種語言都保留一位母語審閱者，要麼把起草範圍限制在你的團隊真正能讀的語言內。用一種公司裡沒人懂的語言產出流暢卻無人審閱的內容，是兩頭都不討好的做法。

什麼時候把整個客服中心外包更合理？

當瓶頸在於涵蓋而非速度時——夜間、週末、假期，或一種內部無人會說的語言——或者當招募與留住客服人員本身就是瓶頸時。起草能讓一支有人值守的客服中心更有效率，卻無法為一條空無一人的佇列配上人手。

客戶能看出回覆是AI起草的嗎？

如果經過了認真的審閱與編輯，通常看不出來——而且在所有實質意義上，作者仍然是那位客服。客戶真正能察覺的是未經編輯的版本：泛泛的措辭、過度道歉、答的是一個與他所問略有出入的問題。這屬於審閱紀律的問題，而不是是否揭露的問題。

如何衡量這件事是否真的有效？

在同類工單上比較前後的：處理時長中位數、只需輕度編輯即送出的草稿占比、工單重開率，以及客戶滿意度。草稿捨棄率高，說明提示詞或檢索環節需要改進。而當處理時長下降之後重開率卻在上升，說明客服核准得太快了——這是最需要密切盯住的訊號。

從哪裡開始

挑出量最大的五類工單，為每一類寫一份提示詞，並把真實的政策原文貼進去。手動運行兩週，量測草稿實際需要多少編輯量——這個數字會告訴你是否值得建置整合，而它在不同公司之間差異極大。如果草稿的品質站得住，再去建置API版本，並把結果寫進內部備註，而絕不是公開回覆。而如果這次嘗試主要證明了「佇列需要的是更多人手，而不是更快的打字」，那同樣是一個有價值的結論——歡迎聯絡我們，聊聊把它妥善涵蓋起來會是什麼樣子。