首頁博客指南配送异常管理：如何在客户投诉前处理配送失败及延误

配送异常管理：如何在客户投诉前处理配送失败及延误

17TRACK

配送例外管理是指識別需要介入處理的貨件、指派人員解決問題，並在客戶需要查詢前向他們更新情況。對電子商務團隊而言，最有效的方法是同時監察承運商例外情況及未能按承諾送達的貨件，按緊急程度排列個案優先次序，並為每件尚未解決的貨件指定負責人、下一步行動及客戶更新期限。

配送例外管理：如何處理配送失敗及延誤

單靠追蹤提示並不能解決配送失敗。當你的團隊確定發生了甚麼、誰可以改變結果，以及客戶需要知道甚麼時，實際的營運工作才開始。本指南說明如何建立相關流程，避免將每個追蹤空白都視為包裹遺失，或承諾你無法控制的配送日期。

區分承運商例外情況與面向客戶的延誤

承運商例外情況是指追蹤事件顯示某些因素中斷了預期的貨件流程。面向客戶的延誤則是指貨件未能在你向客戶承諾的預期時間內送達。兩者可能同時出現，但並不能互相替代。

包裹可能收到例外事件，但仍能在承諾的時限內送達。另一個包裹可能錯過該時限，卻沒有顯示明確的例外事件。因此，只監察標記為「例外」的事件，會令部分問題無法被發現。

根據以下三類訊號建立你的例外隊列：

  • 明確問題：配送嘗試不成功、地址問題、與海關相關的扣留，或其他需要處理的事件。
  • 承諾風險：向客戶顯示的配送時段已經過去，或最新資訊令該時段變得不確定。
  • 意外停滯：在適合該服務及路線的檢查間隔內沒有出現新的追蹤事件。

沒有活動是需要調查的理由，並不代表貨件一定遺失。國際運輸、承運商交接及掃描之間的間隔，都可能令追蹤資料暫時沒有更新。除標準化狀態外，亦應保留承運商的原始事件文字，讓客戶支援人員不會失去有用的背景資料。

為每件需要處理的貨件建立一份工作記錄

分散的承運商頁面及支援工單會令責任歸屬變得困難。使用共用隊列，將貨件、訂單及客戶對話連繫起來。這可以先由結構化試算表開始；流程比軟件更重要。

每個個案應包括：

  • 訂單編號、追蹤編號、承運商及配送服務。
  • 在結帳時或訂單確認中向客戶傳達的配送承諾。
  • 最新追蹤事件、事件時間，以及你的系統收到該事件的時間。
  • 例外類別，以及需要檢查的原因。
  • 指定的個案負責人，以及預期下一步採取行動的人員或機構。
  • 下一步行動、行動期限及下一次客戶更新期限。
  • 承運商個案參考編號、相關客戶回覆，以及任何更換貨件或退款決定。

將訂單記錄與貨件記錄分開。一張包含多個包裹的訂單，可能只有其中一件包裹受影響。更換貨件亦需要擁有自己的追蹤記錄，並與原始個案連結，避免新貨件意外掩蓋尚未解決的問題。

按避免損害的機會排列優先次序

最緊急的個案不一定是最早出現的個案。等待正確單位號碼的貨件仍可能可以挽救，而較早出現的天氣延誤可能沒有即時介入的機會。應優先處理那些透過行動可以避免配送失敗、退回或錯過客戶期限的情況。

情況首項營運行動客戶溝通
地址或進入問題確認缺少的資料，並查看承運商允許的更正程序。要求提供所需的具體資料；不要承諾一定可以修改。
配送嘗試失敗或收到取件通知查看下一步及任何列明的取件或回覆期限。解釋已核實的重新配送或取件指示。
與海關相關的扣留確認涉及文件、付款或審查中的哪一項，以及誰需要回覆。只說明已確認的要求，並提供經核實的聯絡途徑。
未能在配送時段內送達，但原因不明檢查近期運送進度，並在適當時要求澄清。承認未能履行配送承諾，並設定下一次更新時間。
退回寄件人事件確認是否仍可介入處理，並準備商戶解決方案。解釋已確認的狀態及可採取的下一步。

將這些內容用作內部分類處理規則，而不是普遍適用的承運商政策。重新配送選項、地址更改權限、取件期限及調查程序，會因服務及目的地而異。在向客戶提供指示前，請查看適用的承運商指引。

執行可重複的解決流程

1. 確認實際已知的資料

比較訂單記錄、承運商追蹤頁面及任何客戶報告。確認事件是否屬於正確的包裹，以及其時間戳記是否採用不同時區。如果追蹤平台將事件簡化為概括類別，請先查看承運商的原始訊息，再決定發生了甚麼。

在個案備註中分開記錄已確認的事實與假設。「承運商記錄了一次配送不成功的嘗試」與「客戶不在家」並不相同。後者可能無法由該事件證實。

2. 同時指派個案負責人及行動負責人

個案負責人須負責推進問題及更新客戶。下一步行動可能由其他人負責：收件人、倉庫、承運商、代理商或運輸賬戶持有人。

例如，支援團隊可以負責地址相關個案，而客戶確認單位號碼，履行團隊則要求更正。不要因為下一步需要由另一方執行，就轉移整體責任。

3. 採取最小但有用的行動

只要求可能改變結果的資料。對於地址問題，在要求客戶重新提供所有資料前，先將其提交的地址與配送標籤比較。對於海關問題，先確認實際要求，再要求提供文件。對於取件通知，核實地點及指示，而不是發送一則籠統的「請聯絡承運商」訊息。

除非已有適當及完善的流程，否則不要透過一般支援訊息要求支付卡資料、身份證明文件或其他敏感資料。如確實需要敏感資料，應引導客戶使用經核實的渠道。

4. 使用可供處理的證據資料包進行升級

向承運商提出查詢時，應包括追蹤編號、貨件詳情、相關事件記錄、具體問題，以及你要求採取的行動。保留查詢參考編號及回覆。未將對話連結起來，便透過多個渠道重複提出同一問題，可能只會造成重複工作，而不會加快解決速度。

確認誰獲授權提出查詢或索償。商戶、履行服務提供者及持有承運商賬戶的一方，可能並非同一個機構。

5. 在離開個案前設定下一個檢查點

每個開放個案都需要安排檢查時間。應根據有意義的事件設定檢查點，例如承運商回覆、客戶回覆、取件期限或配送承諾。如果沒有可用的事件，便設定內部檢查時間，並告知客戶下次何時會收到你的更新。

「我們正在調查」這類訊息並不完整，除非有人負責檢查調查是否取得進展。

在資料會影響客戶決定時通知客戶

主動溝通在配送承諾有變、需要客戶採取行動，或已到了約定的更新時間時最有用。每個原始追蹤事件都發送訊息，可能造成噪音，令重要通知更容易被忽略。

每則例外訊息都應回答四個問題：哪些資料已確認？你正在做甚麼？客戶是否需要採取行動？下一次何時會收到你的消息？

例子：沒有已確認配送日期的延誤

你的訂單未能在我們提供的配送時段內送達。最新追蹤資料未有確認新的配送日期。我們已向承運商要求更新，而你目前無需採取任何行動。無論我們是否仍在等待確認，我們都會在[日期及時間]前再次聯絡你。

例子：需要確認地址的配送問題

承運商報告你的貨件存在地址問題。請透過[安全支援渠道]確認[所缺少的具體資料]。我們會確認承運商是否可以更新貨件資料。目前尚未確認可以更正資料或再次配送。我們會在[日期及時間]前更新你。

發送前請替換所有佔位符。避免將預計送達時間表述為保證、責怪客戶，或承諾尚未獲批准的退款或更換貨件。如果承運商反覆修改預計時間，應解釋其中的不確定性，而不是每次都將新的預計時間當作確定資料呈現。

決定何時更換貨件、退款或繼續調查

將客戶解決方案與承運商追討流程分開。當商戶需要決定向客戶提供甚麼時，承運商查詢可能仍未完成。該決定應考慮適用的消費者法例、你已公布的承諾、貨件情況及客戶需要。

在批准更換貨件或退款前，請檢查：

  • 原包裹是否仍可能送達，以及如何處理重複配送。
  • 是否有可供更換的庫存，以及新貨件是否實際上能在客戶期限前送達。
  • 客戶是否已透過另一段支援對話獲得其他補救方案。
  • 地址、進入或文件問題是否也會影響更換貨件。
  • 任何獨立承運商索償所需保留的證據。

不要制定一個普遍適用的等候期限，並將其表述為承運商規則。內部升級門檻很有用，但不應凌駕於法律責任或已核實的特定服務要求之上。

使用追蹤技術支援責任歸屬，而不是取代責任歸屬

對於使用多家承運商的商戶，集中式追蹤可以減少逐一檢查貨件的需要。17TRACK 是此流程中相關的追蹤資源。正在評估電子商務實施方案的商戶，可以查看17TRACK Shopify 應用程式頁面；計劃進行自訂整合的團隊，可以查看官方 Tracking API 文件。

將追蹤可見度、客戶訊息及營運解決方案視為不同要求。在採用某個方案前，先測試它能否提供你的流程所需的事件詳情、訂單背景、通知控制及系統連接。直接確認特定方案的功能，不要假設追蹤工具也會處理承運商查詢或商戶補救方案。

有用的驗收測試包括：沒有例外事件但錯過配送承諾、多個包裹在同一張訂單內、延遲出現的掃描記錄，以及與尚未解決的原貨件連結的更換貨件。確認每種情況都能產生正確的個案及訊息，而且不會重複。對於提供補償或要求提供敏感文件等重要決定，應保留人工審批。

衡量流程是否真正解決問題

先從團隊可以一致定義的指標開始：

  • 發現時間：由符合條件的事件或錯過配送承諾，到建立個案所需的時間。
  • 行動時間：由建立個案，到首次有實際意義的介入所需的時間。
  • 更新可靠性：承諾的客戶更新是否按時發送。
  • 主動聯絡：客戶是否在提出配送相關查詢前已獲通知。
  • 解決結果：配送、取件、退回、更換貨件、退款或其他已記錄的結果。
  • 重複原因：按路線、服務、倉庫或地址驗證流程分類的重複問題。

定義每個計時何時開始。如果混淆事件時間與接收時間，延遲的追蹤資料流可能會令團隊看起來反應緩慢。同時要區分行政結案與客戶問題已解決。發送電郵後關閉工單，並不代表配送問題已經結束。

與能夠改變問題的團隊一起檢討重複出現的原因。標籤錯誤屬於履行流程改善；配送預計時間不清晰屬於承諾設定；漏發跟進則屬於支援營運。目標是減少可避免的失誤，而不只是縮小隊列。

常見問題

配送例外是否代表包裹遺失？

不是。這表示運送過程出現中斷或問題，但結果取決於底層事件。在將貨件描述為遺失前，請查看承運商的詳細狀態及任何需要採取的行動。

商戶應等候多久才聯絡客戶？

當需要採取行動、配送承諾有所改變，或到了約定的更新時間時，便應聯絡客戶。相比固定的等候時間，與客戶承諾及解決問題機會相關的觸發條件更有用。

客戶是否應自行聯絡承運商？

有時由收件人採取行動是恰當的，例如確認可用的取件或重新配送選項。提供經核實的指示，並繼續負責商戶的支援個案。不要假設客戶可以要求更改所有貨件資料，或提交寄件人索償。

配送例外管理可以完全自動化嗎？

在支援系統允許的情況下，偵測、分流、提醒及部分訊息可以自動化。含糊的事件、重複失敗、敏感要求及補償決定，仍然需要清晰規則及適當的人員監督。

何時應關閉例外個案？

當貨件結果及客戶補救方案已記錄、所需溝通已完成，而且該個案沒有任何未解決的任務時，便可關閉個案。如果客戶問題已經解決，仍在進行的承運商索償應另行追蹤。

資料來源

Loading