配送與退貨查詢需要的，不只是回覆得快。顧客可能先問門市，再在 WhatsApp 補充資料；客服查詢物流後，也可能要交由另一班同事繼續處理。只要責任與下一步沒有寫清楚，下一位同事就得重新問一次，顧客也不知道應等誰回覆。
這份流程供香港零售及網店團隊按自身營運方式調整。它不設定所有商戶通用的退貨期限，也不承諾任何軟件會自動核准退款。先選一類查詢，例如配送進度，再把現有政策、訂單查核方式及值班安排整理成可執行的紀錄。
建議每宗個案保留同一個內部參考編號，並寫下查詢類型、負責人、已核實事實、尚待確認事項、下一步與下一次更新時間。參考編號用於團隊追蹤，不必包含顧客的敏感資料。
下表是營運範本，並非法律或退款規則。商戶應填入自己實際使用的訂單系統、配送查詢方法及批准權限。分流的目的，是讓同事知道哪些資料可以直接確認，哪些決定必須交給指定人員。
即使顧客在同一段對話同時提出配送及退款要求，也應拆成兩個待辦事項，保留同一個案的關聯。不要把物流正在調查寫成退款已獲批准；兩項狀態必須各自清楚。
| 個案 | 先核實甚麼 | 交由誰處理 | 回覆前的限制 |
|---|---|---|---|
| 配送進度 | 訂單狀態及最新物流紀錄 | 客服負責人；必要時向配送部門查詢 | 未確認到貨時間前，不承諾指定時段 |
| 已顯示送達但顧客未收到 | 核對配送紀錄與顧客提供的必要資料 | 配送聯絡人及客服負責人 | 調查未完成，不推斷顧客或配送人員責任 |
| 退貨或換貨 | 商品、訂單、適用政策及顧客訴求 | 指定售後或門市人員 | 由有權限的人員確認資格與安排 |
| 退款例外或投訴 | 先前承諾、已核實事實與仍待確認部分 | 主管或獲授權的審批人員 | 未獲批准，不保證退款或補償 |
共享對話歷史不等於完成交接。接手的同事仍需要知道上一位同事做了甚麼，以及哪些內容已經告訴顧客。內部紀錄應使用具體動詞，例如『已向配送部門查詢』或『等待主管確認退貨安排』。
以下為虛構示例：顧客表示訂單未收到，系統顯示已送達。客服已查閱訂單，但尚未收到配送部門的確認。交接時應寫『顧客表示未收到；系統顯示已送達；等待配送查核』，而不是『配送遺失』。
如果需要改變已告知顧客的下一次更新時間，由負責人主動說明。這個時間是團隊能執行的跟進安排，不能在未確認資源的情況下寫成保證的服務水平。
| 交接欄位 | 示例內容 | 接手時核對 |
|---|---|---|
| 個案與負責人 | 個案 R-TEST-01；售後值班同事 | 是否有人明確接手 |
| 已核實事實 | 已核對訂單；物流頁顯示已送達 | 是否有來源及查核時間 |
| 尚待確認 | 配送部門尚未回覆 | 等待對象與查詢方式是否清楚 |
| 下一步及顧客更新 | 查核配送；在已約定時間更新顧客 | 承諾是否可執行；有沒有備援人員 |
| 批准及結案 | 按商戶權限確認安排；保留結果摘要 | 是否把調查結果與退款批准分開 |
顧客需要的是清楚的下一步。不要把內部系統狀態直接貼給顧客，也不要讓 AI 根據不完整資料判斷退貨或退款資格。先由人員確認事實與政策，再用顧客容易理解的語言說明。
以下為虛構回覆示例：『我們已收到你的配送查詢，正在核對最新紀錄。負責同事會在已約定的時間向你更新；如有需要補充的資料，我們會再通知你。』正式使用前，把『已約定的時間』改成團隊實際能達成的安排。
WhatsApp Business Platform 的 24 小時客服時段會隨每則顧客訊息開啟或重新計算。時段內可不使用訊息範本回覆，時段外則須使用獲批准的訊息範本。於客服時段內採用自動回覆，必須同時提供及時、清楚及直接的人工升級途徑。請依照目前的 WhatsApp 商業政策設定流程。
先用測試訂單及虛構資料演練，不需要一開始把所有售後流程搬入新工具。選擇可以完整追蹤的查詢類型，讓門市、客服與主管一起確認接手與批准權限。
imBee 的全渠道收件箱產品頁展示對話分派、內部協作及保留對話脈絡的交接方式。評估時，請要求示範你們的實際工作流程，並確認相關功能、權限與整合是否包含在適用方案。訂單查核與退款批准不應在未驗證整合前假設已自動完成。
若你仍在選擇工具，可先閱讀 WhatsApp App 與 API 團隊流程比較；若計劃讓 AI 協助常見問題，另看 FAQ 測試及人工交接指南。這兩篇文章處理工具選擇與 AI 驗收，本篇則聚焦售後個案如何由團隊接手。
訊息數量多，不代表售後服務做得好。每週可以抽查已結案與仍等待的個案，看看負責人是否清楚、是否有重複詢問、哪個環節等待最久，以及對外承諾是否有紀錄。
需要計算處理時間時，先統一開始與結束的定義，並把等待配送回覆與客服實際處理時間分開。顧客滿意度、退款結果及營業額也必須有各自的資料來源，不能由已結案的對話數推算。
保留一份例外改善清單：問題、受影響的流程、負責人、修訂內容、再次測試結果。只有在政策版本、分派方式與同事訓練都確認後，才擴大試行。
參考資料核對於 2026 年 10 月 14 日。本文由 imBee Editorial Team 編製，提供營運方法及虛構示例。
下一步可查看 imBee 零售方案與全渠道收件箱，帶同你們的配送或退貨流程預約示範，確認適用範圍及需要的整合。
不應如此假設。退款資格與批准權限由商戶決定；任何系統整合或自動化都應先驗證。
不是。它是交接及分流範本，應填入商戶自己的政策、權限與實際配送流程。
AI 可以在已核實資料的範圍內協助整理或草擬回覆。涉及未確認責任、退款或補償的決定，應交由獲授權人員處理。
負責人、已核實事實、尚待確認事項、下一步與下一次顧客更新時間；不要只寫跟進中。
不一定。先確認是否屬於同一宗未完成的查詢，再按團隊的個案管理方式處理。
先列出完成查核必需的資料；不要在聊天中要求完整付款卡或敏感身分號碼。其他資料使用與保留安排亦應按商戶政策確認。
選一類可完整追蹤的配送查詢，再測試正常、例外、換班與主管批准的情況。以實際測試紀錄決定是否擴大。
