退換貨系統：從客戶申請到驗貨、退款與換貨出庫
客戶退回兩件貨，倉庫只收到一件，另一件要換尺碼。把申請、實收、貨品去向及款項分開記錄，客服、倉務與財務才知道下一步由誰處理。
一間同時有網店和門市的服裝店，客戶在網上買了兩件上衣，其中一件想退款，另一件想換大一碼。客服在訊息中答應處理，門市接收包裹，倉庫安排換貨，財務再退款。若各人只看到自己的訊息，最容易漏掉的是：到底收到哪件、退了多少錢、換貨還有沒有庫存。
退換貨系統可以把這段售後工作串起來。Shopify 已有客戶自助申請及內部處理退換貨的功能；Microsoft Dynamics 365 亦有退貨授權、到倉檢查及貨品處置流程。以下以可以按公司做法設計的功能說明：重點是每件退貨的去向，以及客戶下一步要做甚麼。
Shopify — Self-serve returns and cancellations · Microsoft Dynamics 365 — Sales returns
客戶選貨品，客服看待處理清單
客戶登入訂單頁，或完成電郵驗證後，看到已購買的款式、尺碼、數量及可申請的項目。選擇退幾件、原因、退款或換貨，必要時附照片；提交後獲得退換貨編號及交回方法。只輸入訂單號碼不應就能查到別人的地址或購買紀錄。
客服的清單可按「待補資料」「待批准」「等候寄回」篩選，打開一筆就能對照原訂單、以前的退換貨及客戶上載內容。超出公司退貨期限或數量時，交由有權限的同事判斷並留下理由；重複提交同一件貨則連回原申請，避免另開一張退款單。
到貨畫面記實收數量，再決定能否入庫
門市或倉務同事掃退換貨編號，看到預期收到的每一行商品，再填實收數量、尺碼或序號、包裝狀況和檢查照片。申請兩件只收到一件，先確認那一件，另一件保留「未收到」；包裹沒有編號或貨品不符，放入待核對清單，客服可在同一筆記錄跟客戶確認。
驗貨結果可分為可再售、待整理、待進一步檢查或不可再售，並指定存放位置。收到貨與增加可售庫存應是兩個動作；有污漬的衣服未處理好，不能因為申請獲批就重新上架。Microsoft 的退貨流程亦把到倉、檢查及處置分開，支援數量分拆。
換貨有自己的出庫，退款有自己的結果
換尺碼時，畫面要顯示可供應的款式、庫存位置、是否已預留及預留到何時。若公司選擇收到退貨後才預留，就在客戶申請時清楚說明；缺貨時讓客服提出其他選擇，再記錄客戶同意。Shopify 現行文件說明換貨庫存到處理退貨時才預留，不能把提出申請當成已留貨。
款項畫面逐行列出原有折扣後金額、換貨差額及按公司政策適用的費用。財務確認後，保存支付平台的退款參考、成功或失敗結果；失敗仍是待處理，不能發「已退款」通知。換貨則連到獨立的出庫及追蹤號碼，客服不用從聊天紀錄猜是否寄出。
客戶看到進度，內部看到尚欠哪一步
客戶的進度頁可顯示申請已收、交回指示、實收貨品、退款處理中及換貨已寄出，附上需要補交的資料。公司內部的畫面另外顯示檢查結果、付款失敗原因及負責人；這些內容不必原封不動給客戶看。門市只需收件及核對，不一定要有退款權限。
一個退換貨編號可以同時有「一件已退款、一件等候寄回」。工作清單按尚欠的操作排列，記下誰在何時改過數量、批准例外或發出通知。按款式及退貨原因整理資料，亦可幫商品同事查尺碼描述或包裝問題；客戶上載的相片只供有需要的同事存取。
接網店、門市及倉庫時，要核對更新落在哪裏
Shopify 社群曾有商戶反映退換貨已更新 Shopify，卻未反映到 Lightspeed／Vend。這是個別公開問題，不代表所有接駁都有同樣缺陷，但足以提醒：一邊顯示成功，不等於另一邊的庫存已正確。接駁畫面應顯示目標系統、商品對照、庫存位置、最後結果及可重試項目。
地區及倉庫設定也要逐項試。Shopify 文件列出的內建退貨標籤建立功能要求主要地點及客戶地址都在美國，香港流程需另核對承運商或上載標籤安排。ShipStation 文件則說明其回補會落到原出貨的 Shopify 地點。若退貨送到另一個檢查倉，需先記錄實際收件位置，再按公司流程轉移；重試只補失敗步驟，不能再退一次款或再加一次庫存。
Shopify Community — Return and exchange stock updates in Lightspeed/Vend · Shopify — Creating returns and exchanges · ShipStation — Restocking returned items with Shopify
服裝、電子產品與批發，檢查欄位可以不同
服裝可記尺碼、吊牌及穿着痕跡；電子產品可記序號、配件是否齊全及檢測結果；批發則可能按箱、件及批次分拆退回數量，並產生貸項通知單。這些欄位和處置方式可以按商品類別設定，毋須每次由客服在備註中重打。若涉及維修，再連到維修記錄，退貨申請仍保留原有脈絡。
ReturnGO 的商戶評價提到自助申請、多語言、相片及工作流程設定，也有人表示需要協助設定。這些意見支持需求有實際使用場景，並不證明每間公司都需要重寫一套系統。已有工具能處理的部分可保留，訂製功能則集中於未接上的收件、驗貨或款項交接。
付款前看 Demo，試一張有退款也有換貨的申請
ProApp 提供付款前 Demo。討論這類系統時，可以先用匿名商品及公司常見的退換貨規則，安排一段由客戶、客服、倉務到財務的示範流程。先把需要呈現的畫面和例外情況講清楚，再確認開發範圍。
- 客戶選兩件貨：一件退款、一件換尺碼；客服批准後，確認客戶看到的交回指示。
- 倉庫先收一件，記錄污漬並放入待整理位置；核對另一件仍未收到，可售庫存沒有提早增加。
- 再收第二件，試換貨缺碼、補差價及客戶改選；確認出庫有對應款式和追蹤號碼。
- 模擬退款或庫存接駁失敗，再重試；財務核對退款參考，客服檢查進度通知，確認沒有重複款項或入庫。
先接好一種商品、一個收件點
準備一份匿名訂單、一張常見退貨單、現行退換貨規則、收件點及各人的操作權限。第一段流程可以只處理一種商品，完整走過申請、批准、實收、檢查、退款或換貨，再加入多門市、批次及維修分支。客服能查到貨，倉庫知道放哪裏，財務知道哪一筆仍未成功，客戶知道要等還是要補資料，這段工作才算接好。
