先分清申請與結果
顧客按下「申請退貨」，只表示提出要求；店方尚未收到貨品，也未決定退款金額。系統應把「已申請」、「審核中」、「已批准」、「運送中」、「已收貨」、「已檢查」及「已處理」分開記錄，並將退貨原因和數量連回原訂單。提交後即顯示「退貨完成」，會令顧客誤以為退款已發出，也令倉務人員誤判包裹已到。Shopify 的自助流程容許商戶批准或拒絕申請，顯示這幾步不能混為一談。即使店舖以電郵人手處理，也應讓顧客看見下一步，以及在寄出標籤前修正錯誤數量或聯絡職員的方法。
讓退貨資格規則可核對
先寫清店舖實際公布的退貨政策，再設定畫面：哪些已出貨貨品可申請、期限由哪次送達起計、哪些屬不可退貨品、退貨運費由誰支付，以及有否可能收取重新上架費。平台提供的期限選項不能當作香港所有交易通用的法定冷靜期。Shopify 的規則針對已履行訂單，可按個別貨品或全單最後送達日期起計，而新規則不會追溯改寫舊訂單。自建系統亦應保留顧客下單時適用的政策版本，讓審核有根據。對損壞、寄錯貨或送達日期有爭議的個案，應訂明人工覆核路徑，不應暗中改動資格標記。
讓顧客明白可做甚麼
訂單頁面應逐項列出所購款式、可退數量、期限計算基準和適用費用。若某項不能申請，說明真正生效的條件並提供聯絡方法；只把選項隱藏，容易引起爭議。表格只收集審核所需資料，例如原因、貨品狀況，以及聲稱損壞時可選擇附上的證據。普通退貨不宜一律強制上載照片，除非已公布的流程確有需要。初步退款金額須清楚標示為估算，因為驗貨、運費或換貨差額可能影響最終結果。確認頁應說明顧客現在能否寄件，還是要等待批准及指示，並提供個案編號；不要把提交申請寫成已啟動退款。
讓職員作出有紀錄的審核
職員處理佇列應在同一個案畫面顯示原訂單、履行及送達記錄、政策版本、之前的退款、申請貨品和顧客解釋。審核者可批准、具體說明原因後拒絕，或要求補充資料；決定者及時間須留紀錄，對客說明亦應保存。已退款項目再次申請，或申請數量超過實際送達數量，應阻止或交主管處理。批准後要產生準確的寄件指示、收件地點及適用標籤，而不只是把狀態轉綠。若提供換貨，須說明替換貨是否真正留起；Shopify 指出其換貨庫存要到處理退貨時才會保留，因此沒有另設預留機制便不應立即承諾特定款式一定有貨。
收貨及驗貨須對應原個案
收貨同事需要可掃描的個案編號、預期貨品及數量，並可標記「非預期包裹」或「內容不齊」。在決定重新上架、隔離或棄置之前，先記下到貨時間、實收貨品和狀況。一張訂單可能有多宗退貨，包裹也可能裝着與批准申請不同的款式，故不能只按訂單號收件。顧客狀態應先顯示「包裹已收到」，再於檢查後說明結果；若結果與估算有重大差異，要交代理由及回覆渠道。物流顯示送達，並不代表貨品已驗妥或可重新出售。內容不符的個案要讓審核及客服看見，不能悄悄轉成退款或換貨。
最後結算要逐項核實
驗貨後，按原本實付金額、批准退回的數量、適用運費或處理費，以及換貨項目計算最終差額。保留初步估算和最後計算，方便解釋差異。Shopify 文件把商戶退錢、顧客因換較貴貨品需補款，以及等值換貨分開處理；若只先處理混合申請的一部分，暫時差額亦可能與整宗完成後不同。自建流程要決定是否待全部項目解決才出款，或清楚解釋分段結算。退款操作應限授權職員執行，並保存支付服務商的參考號及狀態。通知顧客時只說已發起退款，不可在款項尚未到帳時聲稱已收妥。
用兩項貨品個案試行
假設一張示例訂單有一盞燈和一個備用燈罩：燈到貨時損壞，燈罩則是顧客不想要。顧客同時提出兩項申請，附上燈的照片，畫面分別顯示資格及暫估金額。職員先批准燈，燈罩仍須核實政策期限。包裹其後只載有燈，收貨員便記錄實收一件、檢查燈，並保留燈罩個案為未完成，不可把整單標成已退。若顧客後來改選新燈，團隊先核實庫存和差額，再承諾寄出。最後通知應逐項說明哪件已退款、哪件已換貨、哪件仍待處理。這只是流程示例，沒有假設任何店舖費用、政策或法定權利；它揭示同一張訂單可以同時存在不同狀態。
例外處理不可抹去紀錄
實際流程會遇到沒有個案號的包裹、物流顯示送達但倉庫未找到貨、退款後顧客改求換貨，以及貨品不適合再出售等情況。每種例外都要有負責人、原因分類及給顧客的更新，不可只顯示空泛的「請聯絡我們」。原申請、職員決定、驗貨及支付參考號要足以重建事件；修正錯誤時新增調整紀錄，不要覆蓋舊資料。照片和地址只供有工作需要的人員查看，並按店舖實際資料保留安排處理。平台若無法直接完成選定的換貨或費用處理，應明確使用人工流程，在另行收款或寄貨前向顧客交代。
上線前測完整旅程
上線測試至少包括合資格退貨、不合資格項目、分批送貨、包裹少了一件、換貨款式缺貨，以及支付服務商仍在處理退款。每次狀態轉換後，對照顧客頁、職員佇列、倉庫收件、支付紀錄和訂單歷史。用窄屏手機檢查中英文：拒絕原因、估算與實收金額的分別、下一步操作都要看得明白。更改政策設定後應重測，因為舊訂單可能沿用舊規則，新訂單則用新規則。指派人員定期核對未結案個案及退款；表格再美觀，無人處理仍然無用。成功的流程應能就每項貨品回答三件事：顧客要求甚麼、貨品實際怎樣移動、款項實際怎樣處理。
訂明實際處理時間
退貨頁面的時間承諾必須是店舖做得到的。申請期限、職員一般審核時間、批准後顧客須寄件的期限、倉庫驗貨時間，以及支付服務商最終處理退款所需時間，應分開說明。如果某段時間尚未有可靠資料，就說明下一次更新由甚麼事件觸發，並指派個案負責人，別隨意編造「幾天內完成」。每次轉換都要記錄時間，超過承諾審核點時提醒職員。包裹已送到的顧客，不應靠沉默猜測是被拒、仍在驗貨還是包裹遺失。旺季若令隊列延誤，直接更新受影響個案。可靠的服務承諾是看得見的下一步、清楚的負責團隊及查詢例外的方法，並由真實個案紀錄支持。
用個案資料找出等待位置
流程運作後，可量度個案分別在待審核、等待顧客寄件、等待倉庫收貨、待驗貨和待確認退款各狀態停留多久。按狀態及滯留時間點算，不要只報已退款宗數。「已收貨但未驗貨」個案持續增加，可能要改善倉庫處理；「已批准但未寄件」偏多，則可能是寄件指示不清或顧客改變主意。抽查被拒個案，把記錄的政策原因與顧客說明比較。這些只是建議的營運量度，並非聲稱本店已有任何成效數據；目的是找出哪個交接令顧客等不到答案，然後修好。另要點算尚未完成的款項流轉，避免貨品已處理便把整張訂單誤標成結案。
上線前核對
- 申請、收件、驗貨及結算是否分開顯示？
- 職員能否查回適用政策版本及原實付額？
- 每宗例外是否有負責人及對客更新？
