電子商務中的客戶自助服務：訂單追蹤、退貨以及何時升級處理
電子商務中的客戶自助服務，應讓購物者查閱配送進度、了解退貨資格，以及完成日常申請，而無需等待客服人員。它亦應識別出追蹤資訊、政策規則或自動化流程無法解決問題的情況。對營運及客戶體驗團隊而言，目標並不是消除人工支援，而是準確處理直接的要求，並將例外情況轉交給能夠採取行動的人員。
實用的售後體驗應在每個步驟回答三個問題：正在發生甚麼事？客戶下一步可以做甚麼？如果這樣仍未能解決，誰負責處理問題？應圍繞這些問題建立訂單追蹤及退貨流程，而不是圍繞聊天機械人或幫助中心的功能建立。
決定客戶可以安全自行解決的事項
當資訊可靠、下一步行動清晰，而結果不需要酌情判斷時，自助服務最為有效。查詢追蹤編號，與判斷遺失包裹是否符合補發資格，是兩回事。展示退貨政策，與處理客戶聲稱商品有缺陷的爭議，也是兩回事。
以下界線應視為營運模式，而非普遍適用的政策。請根據你的履行流程、已公布的條款及適用的消費者要求作出調整。
| 客戶需要 | 適合的自助服務行動 | 需要升級處理的原因 |
|---|---|---|
| 查閱訂單 | 顯示履行狀態及貨件詳情 | 訂單記錄互相矛盾，或核實後仍找不到訂單 |
| 追蹤貨件 | 顯示承運商最新事件及其時間戳記 | 配送預期未能達成，或需要調查狀態 |
| 申請標準退貨 | 檢查資格並解釋退貨流程 | 退貨資格存在爭議，或例外情況需要判斷 |
| 查閱退款 | 顯示實際退款階段及下一個檢查點 | 已超過已告知的檢查點，或記錄不一致 |
讓訂單追蹤解釋情況，而不只是顯示狀態
訂單確認、運單標籤及配送掃描代表不同事件。你的追蹤體驗應保留這些差異。單憑「已建立標籤」事件，不應被呈現為承運商已實際接收包裹的證明。
顯示訂單參考編號、相關商品、貨件識別碼、最新事件及事件時間戳記。區分承運商事件發生的時間，以及你的系統上次檢查更新的時間。對於拆分訂單，應指出哪些商品屬於每件貨件，避免其中一件已送達的包裹令整張訂單看起來已完成。
將追蹤事件轉化為有用的下一步
- 已建立標籤：解釋運送資訊已存在，但實際交接可能尚未確認。若錯過發貨承諾，應轉交履行團隊處理。
- 運送途中：顯示最近一次報告的運送進度。如顯示配送預計時間，應指出這是預計時間而非保證。
- 配送例外：當來源提供具體問題時，應加以解釋。不要將每個例外都變成籠統的等待指示。
- 已送達：顯示已報告的配送資訊，但為無法找到包裹的客戶提供獨立處理途徑。
- 近期沒有更新：說明最後一個事件發生的時間，以及甚麼情況會觸發檢查。追蹤出現空檔本身並不能證明包裹遺失。
避免對所有貨件採用「三日後聯絡我們」這類統一規則。檢查門檻應反映運送服務、目的地、發貨承諾、配送預計時間，以及任何相關的承運商調查要求。本地特快包裹和國際經濟貨運不應自動採用相同的升級邏輯。
將「已送達但未收到」視為獨立問題處理
已送達掃描並不能解決客戶報告包裹遺失的問題。提供簡短檢查清單：確認配送地址、查看已報告的安全放置位置，並在適當情況下詢問家庭成員或大廈接待處。之後提供清晰的支援途徑。
不要迫使客戶無限次重複這份檢查清單。轉交支援時應包括貨件識別碼、配送事件、相關配送詳情，以及已完成的檢查。這樣團隊便可根據適用政策評估下一步，而不是把掃描結果視為最終答案。
圍繞資格、指示及可見度建立退貨流程
退貨入口網站應幫助客戶了解自己是否可以繼續，以及之後會發生甚麼事。只收集申請而沒有解釋後續每一步的表格，只能算是不完整的自助服務。
在提交前讓退貨資格易於理解
說明適用的退貨期限、起算事件、商品狀況要求、相關排除項目及可用的解決方案。在客戶作出承諾前，解釋任何適用的退貨運費或扣減。不要暗示所有市場或商品類別都適用同一退貨政策。
區分改變主意退貨，與商品損壞、有缺陷、錯誤或遺失的報告。這些情況可能需要不同處理方式，也可能涉及有別於商店自願退貨政策的權利。當客戶報告需要檢查的問題時，入口網站拒絕不應成為最終決定。
讓退貨流程清晰明確
- 安全識別購買記錄。要求足夠資料以找出訂單，同時避免未經授權的使用者取得訂單資料。
- 選擇商品及原因。支援以商品為單位的申請，而不是假設整張訂單都要退回。
- 解釋建議的解決方案。區分退款、換貨及商店積分，並包括適用的任何條件。
- 提供正確指示。解釋包裝、退貨目的地或交件方式，以及任何所需授權。告知客戶在取得適用指示前不要寄出商品。
- 提交後顯示進度。區分申請獲批、退貨運送、倉庫收貨、適用時的檢查，以及退款處理。
不要僅因退貨已獲授權或已收到，就標示為「已退款」。批准、開始退款及客戶收到款項是不同事件。如果你的系統無法觀察最終付款結果，應傳達它能核實的階段，並解釋何時應由支援團隊調查。
設定能識別負責人的升級觸發條件
除非列明負責團隊及下一步行動，否則升級規則並不完整。「聯絡支援」只是一道入口，不是解決流程。在內部，每個例外情況都需要負責人、所需證據，以及營運實際能夠履行的回覆承諾。
- 貨件未按預期交接：轉交履行或倉庫營運團隊，以核實發貨、庫存及貨件記錄。
- 錯過配送承諾或追蹤資料不一致：轉交能夠檢查貨件並在適當情況下協調承運商查詢的支援或物流負責人。
- 已送達包裹遺失：轉交受過訓練的支援人員檢查，包括任何適用的調查或解決流程。
- 客戶報告商品問題但退貨遭拒：轉交受過政策訓練的人員，而不是重複自動拒絕。
- 已收到退貨但退款停滯：根據實際瓶頸轉交，例如倉庫對賬或付款營運團隊。
- 懷疑帳戶被入侵或付款遭濫用：透過安全驗證流程轉交，避免在一般對話中暴露敏感資料。
即使沒有偵測到技術錯誤，當客戶無法使用自動化流程時，也應提供人工途徑。無障礙障礙、無法存取訂單及特殊情況，都可能令有效要求無法符合標準表格。
在轉交時傳遞完整背景
有用的轉交資料包括已核實的訂單參考編號、受影響商品、貨件或退貨識別碼、最新相關狀態、政策結果、客戶選擇的原因，以及已嘗試的行動。只包括案件所需的資料，並適當限制存取權限。
告知客戶下一步會發生甚麼事：哪個團隊會檢查問題、客戶將如何收到回覆，以及如已制定，預期回覆時間是多少。在負責團隊授權前，不要承諾退款、補發或承運商結果。
按工作流程而非功能數量選擇工具
訂單查詢、承運商追蹤、退貨及例外處理彼此相關，但並不可互相取代。追蹤頁面提供貨件可見度；它本身不能確立退貨資格或授權賠償。退貨申請介面仍需要可靠的政策規則及營運跟進。
如要實際開始，17TRACK 的追蹤頁面適用於自助服務中的包裹可見度部分。評估商戶工作流程的團隊可以查看 17TRACK Shopify 上架頁面，而退貨團隊可以了解 17RETURNS。如要自訂實施，請先參閱 Tracking API 文件，再制定整合要求。這些資源針對評估的不同部分，不應被視為單一配置能處理此處所述所有工作流程的證明。
根據你的商店、運送服務、政策及支援流程測試實際設定。核實商品與貨件的對應、狀態更新時效、客戶驗證、例外轉交、退貨規則及退款狀態的準確性。直接確認整合範圍及商業條款，不要假設某個產品類別便保證具備特定功能。
衡量解決率，而不是沉默程度
聯絡次數減少可能代表客戶找到了答案，但也可能代表他們無法取得幫助。評估自助服務時，應一併考慮重複聯絡、未解決的例外、客戶回饋及升級案件的質素。
- 任務完成：客戶能否達到預期結果，例如找出相關貨件或提交符合資格的退貨？
- 重複聯絡：同一客戶是否需要就同一問題再次求助？定義衡量時間窗，並以一致方式配對案件。
- 例外負責權：升級案件是否到達能夠採取行動的團隊，還是被反覆轉交？
- 資訊準確性：追蹤、退貨及退款訊息是否與底層營運記錄一致？
- 客戶付出：購物者是否需要重新輸入資料、重複解釋，或使用難以存取的流程？
在推出前，測試拆分貨件、遺漏掃描、逾期配送、部分退貨、有爭議的資格決定，以及等待檢查的退款。成功的測試應以完成任務或清晰且可行動的轉交作結。先從範圍較窄而可靠的流程開始，只有在其例外情況已有負責人後才擴展。
常見問題
客戶應先聯絡商店還是承運商？
承運商可能能夠解釋配送事件或可用的配送選項。商店應繼續作為客戶就購買、履行問題及補救要求聯絡的可及渠道。當所需調查或決定屬於商戶責任時，不要讓客戶在商店與承運商之間來回奔波。
聊天機械人可以管理整個售後體驗嗎？
它可以為受支援的任務提供介面，但仍需要準確記錄、明確權限及升級途徑。它不應捏造配送日期、推斷退款已獲批准，或推翻需要人工檢查的政策例外。
每個退貨申請都應自動批准嗎？
不應。當申請明確符合已核實規則，且沒有適用的檢查條件時，自動批准最為合適。資格不明確、有爭議的商品狀況或已報告的產品問題，可能需要不同工作流程。應解釋檢查步驟，而不是將其呈現為無法解釋的拒絕。
沒有可用預計時間時，追蹤頁面應顯示甚麼？
顯示最近一次已核實事件及其時間戳記，並以清晰文字解釋目前沒有可靠的預計時間。包括下一個檢查條件及聯絡途徑。誠實地說明資訊空缺，比作出沒有根據的配送承諾更有用。
小型電子商務團隊應從哪裏開始？
先提供易於使用的訂單查詢、容易理解的貨件更新、清晰的退貨政策及明顯的支援途徑。只有在為例外情況分配負責人後，才為重複性任務加入自動化。具備可靠跟進的簡單流程，優於留下棘手案件未解決的大型入口網站。
資料來源
工具評估部分引用的官方產品資源如下。以上工作流程界線、升級模式及測試清單是編輯部的營運建議，並非對產品功能作出的保證性聲明。
