客服交給人工時要留下什麼？一頁式交接紀錄欄位表

客服轉交人工時，如何交代問題、核對結果、已做處理與下一步？整理成可直接套用的一頁式交接欄位表。

客服問題從自助回覆轉交人工時，最重要的是讓接手者不用重問一遍，也不必猜測先前做過什麼。把交接紀錄寫成一頁，依序留下問題、核對、處理、期待與責任，能讓下一步有明確起點。以下欄位可套用在不同客服工具或團隊流程，再依實際工作量調整。一份好的交接不追求欄位愈多愈好，而是讓接手者分辨已知與未知、已做與未做，並知道怎麼確認責任交接。內容只保留下一步需要的線索，完整對話仍放在可回查的位置。

一句話問題摘要怎麼寫

一句話摘要的任務，是把接手者的注意力放到同一個問題上，而不是先重述整段對話。可以用「客戶身分或訂單線索＋正在發生的狀況＋希望解決的結果」組成一句；若同一客戶同時提兩件事，就把主問題放前面，另一件列為次要事項，避免把退款、改地址、登入問題混成一條。摘要要描述可觀察的狀況，例如假設案例：「會員表示付款後仍看不到訂單，提供的訂單編號末四碼為 4821，請確認入帳並回覆何時能查詢」，不要寫「客戶很生氣」或「系統出錯」這類推測或情緒標籤。引用客戶原話只保留理解問題所需的短句，若原話有電話、地址或完整帳號，不要整段複製。

摘要中若資訊尚未證實，寫「客戶表示」；若是內部查到的結果，才寫「後台顯示」，把來源與說話者分開。寫完後用兩個問題自查：新接手的人能否只讀這句就知道要處理什麼？能否分辨事實、客戶主張與尚待確認處？若不能，刪掉背景形容，補上具體物件、狀態或待確認點。遇到多步事件，可用時間順序留下最關鍵的一個轉折，例如何時付款、何時聯絡、目前卡在哪裡，再把完整對話連結放在紀錄旁，讓摘要仍能一眼讀完。若摘要無法涵蓋背景，可保留最能解釋現況的日期與先後，例如「昨天付款、今天查詢仍未見訂單」，再標明這是客戶陳述還是畫面核對結果。當一個問題已拆成幾個待辦，摘要仍只寫共同主題，把待辦細節放在相應欄位，避免讀者在一句話裡找不到主旨。最後避免在摘要承諾處理結果或時限，除非已獲授權且能履行；摘要只界定問題，不替下一位同仁做出尚未確認的判斷。

已核對資料列哪些

核對欄位要回答「看過什麼、從哪裡看到、結果是什麼」，不只勾選「已查」。紀錄客戶提供的識別線索時，採團隊允許且足以辨識案件的最少資料；例如訂單末碼、聯絡管道與聯絡時間，避免為了方便把完整付款資料或個人資訊貼進交接。每一項都要保留來源，因為客戶敘述、系統畫面與第三方通知的可信範圍不同。若資訊不在手邊、沒有權限或畫面未更新，明確寫「未核對」以及原因，不能把空白當成沒有問題，也不要用「正常」概括多項彼此無關的檢查。先用這張一頁式欄位表建立共同格式，再填入個案資料：

每格都要能獨立理解，不要只打勾或寫「有」；固定縮寫也應附完整名稱，免得跨班的人看不懂。記錄日期、金額或時區時保留必要單位與來源，例如假設紀錄「截圖顯示 1,200 元」，而不是自行判定已入帳。只引用處理本案所需的識別資料，遮蔽非必要欄位；附件也要確認權限設定，避免把無法開啟或不該共享的連結當成證據。核對時間同樣有用，可在結果後註記查詢時間，讓接手者知道是否需要重新查。若兩個來源不一致，並列各自顯示內容與時間，不要挑一個方便的結果寫成定論。交接人能一眼看出已知、未知與下一個核查來源，核對清單才算完整。

已嘗試步驟如何記錄

記錄已嘗試步驟時，要讓另一位同仁看得懂「誰在何時做了什麼、看見什麼結果、因此還缺哪一步」。每次嘗試各佔一列或一段，寫下時間、動作、觀察到的回應，以及對問題造成的影響；不要只寫「已處理」或「試過了」，因為接手人無法判斷是否重複操作。若同一步驟在不同時間重試，分開記錄，並補充兩次結果有何差異。舉例來說，若客戶反映表單送出後沒有確認訊息，假設紀錄可寫「14:05 依客戶提供的頁面重送一次；畫面停留在送出中，未收到確認信；未再重送，避免產生重複資料」。這是說明寫法的假設情境，不代表任何特定系統行為。

把已排除、仍可能與問題有關、尚未測試三種狀態分清楚；「沒有看到錯誤」不等於問題不存在，「客戶說成功」也不等於內部已核實。若步驟涉及付款、取消、刪除或會改變客戶資料，應註明是否完成以及依據，避免下一人不知情地再執行。不要貼入密碼、驗證碼或不必要的敏感內容；如需參照畫面，保存可授權存取的案件連結與必要截圖位置。操作若需等待對方、系統或另一部門回覆，記下開始等待的時間、已詢問的窗口與預計再確認的時點；沒有確切回覆時間就寫下一次檢查點，不要猜何時會好。遇到無法重現的問題，也要說明當時使用的步驟和條件，讓接手者知道證據不足而非誤認為已修復。若同一步驟有風險，先說明尚未重做的原因以及需要誰授權。最後指出下一個最能縮小原因的檢查，讓接手人從證據接續，而不是從頭猜測。

客戶期待怎麼保留

客戶期待要記錄成可回覆、可確認的目標，不能只留下「希望儘快」或「要求處理」。先寫客戶想看到的結果，例如查明一筆款項、收到可使用的帳單，或知道申請目前進度；再寫他在意的條件，像是希望用原管道回覆、需要在某個時點前知道進展，或不能接受哪種替代方式。若客戶說了具體時間，保留原意並標示那是客戶提出的期待，不要改寫成團隊承諾。若雙方已確認回覆時間，另放在下一步欄位並標明承諾者，避免期待與承諾混在一起。可以用一句話確認理解：「我記下您希望先確認款項是否入帳，並在今天收到進度；目前我會先核對紀錄，確認可回覆時間後再告知。」

若尚未問清楚，就列出待問的一題，例如客戶要的是退款結果，還是先知道審核進度；不要替他推定。客戶情緒可以簡短記錄對服務有影響的部分，例如「對等待時間有疑慮，盼先收到進度」，不必使用「難搞」「不理性」等評語。留意客戶提出的限制是否與案件處理直接相關；不必要的家庭、健康或財務背景不必搬進紀錄。對含糊的時間詞也要補上確認，例如「今天下班前」究竟是客戶希望知道結果，還是只要收到進度；若客戶尚未指定時點，照實寫「未提供期限」，不要替他填急件。客戶中途改變期待時，保留最新版本並標明更新時間，避免接手者照舊承諾回覆方式。若要求的結果目前無法保證，記錄已向客戶說明的範圍，讓後續回覆維持一致。交接的價值在於保留對方如何判定問題已被解決，接手者就能在回覆時核對同一個標準，不會只完成內部動作卻沒有回答客戶真正想知道的事。

下一步由誰何時完成

「下一步」應寫成一項能執行的動作，並指定一位明確負責人與可追蹤的時間。欄位可包含負責人、動作、完成或回報時間、所需依賴，以及完成後要留下的結果；例如假設格式：「怡君於 10 月 18 日 16:00 前查核訂單紀錄，若仍無法確認，回報目前缺少的資料並聯絡客戶」。這是格式示例，不代表已發生的客戶案件。避免寫「客服跟進」「稍後處理」或只填部門名稱，因為多人都可能以為別人會做。若事項需要另一個團隊提供資料，標出依賴對象與已提出的請求，並安排在等待期間誰更新客戶；若有多個待辦，依客戶影響與前置關係排序，第一項要能推動其他步驟，而非把所有工作堆成一串。

時間只填已約定的期限或團隊可掌握的下一次檢查點；尚未能承諾時，寫明「待確認回覆時程」與由誰確認，不要用精確時間製造承諾。負責人若休假或需轉交，先指定代理人或寫清楚觸發轉交的條件。每個動作完成後更新結果與時間，未完成則保留原因和新檢查點，避免把舊待辦當成仍在執行。若案件同時有客戶回覆與內部查核兩件事，拆成兩個待辦，分別指定負責人；避免單一負責人欄位掩蓋誰要做哪個動作。若責任在不同隊伍間移動，記下交出和接收的時間，並在接收前保留原負責人作為追蹤點，直至新負責人確認。跨時區或跨日期的期限，寫出年月日與時區；避免「明天」等相對說法。完成條件也要具體，例如是否需回填查核結果及通知客戶。交接前由原處理人檢查每一項是否有人接、何時再看、完成後要通知誰，讓紀錄能支援行動，而不只是保存過去。

交接後如何確認接收

交接不是把紀錄送出去就結束，還要確認接手人已看懂並願意承接。可以在團隊既有案件紀錄中保留交接時間、接收人、目前狀態，以及對方的確認；確認內容至少要能辨識「已收到、理解當前待辦、知道下一個回報點」。若接手人只回「收到」，但未確認負責範圍或期限，原處理人應補問一次，例如「請確認由你查訂單狀態，並於約定時間前回報；若需補件請先留言」。遇到跨班交接，可同時標示客戶是否正在等待、下一次對客回覆由誰發出，避免內部已接手但客戶長時間沒有消息。若在預定時間仍未取得確認，依團隊既有值班或升級流程提醒當班負責人；不要默默假設訊息已讀就代表有人負責。

接收人發現摘要、證據或期待有缺口時，應直接指出缺少的欄位，原處理人補充後再確認，讓不完整資訊不要沿著流程繼續傳遞。確認時不必長篇重複整份紀錄，但要能對上案件識別與第一個待辦，減少把相似案件接錯的可能。若接收人表示資料不足，把補充內容放回同一筆紀錄並更新版本或時間，避免不同訊息串各自保留一套事實。值班表、工單或其他實際欄位，選一個作為責任狀態的主要依據，並讓團隊知道在哪裡查。確認後，把負責人與待辦更新到大家查得到的位置，並記下確認時間；案件真正解決時，再另行記錄對客結果與客戶是否收到回覆。如此能清楚區分「紀錄已送出」「責任已接收」和「問題已解決」三個狀態。若團隊目前沒有固定回覆格式，可先約定一則簡短確認句與未回應時的提醒對象，再用幾次交接觀察是否還有人需要重問關鍵資訊。

可以先把六段欄位放進團隊現有的交接模板，挑一筆不含敏感資訊的假設案件演練，確認新接手者能否直接接續，再刪去不適用的欄位。演練時請接手人只讀紀錄後說出問題、已做處理和第一個待辦；若答案不同，就補明來源、責任人或回覆點。想了解 ReplyBot，請前往 ReplyBot。