退换货系统：从客户申请到验货、退款与换货出库
客户退回两件货，仓库只收到一件，另一件要换尺码。把申请、实收、货品去向及款项分开记录，客服、仓务与财务才知道下一步由谁处理。
一家同时有网店和门店的服装店，客户在网上买了两件上衣，其中一件想退款，另一件想换大一码。客服在消息中答应处理，门店接收包裹，仓库安排换货，财务再退款。若各人只看到自己的消息，最容易漏掉的是：到底收到哪件、退了多少钱、换货还有没有库存。
退换货系统可以把这段售后工作串起来。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。讨论这类系统时，可以先用匿名商品及公司常见的退换货规则，安排一段由客户、客服、仓务到财务的演示流程。先把需要呈现的画面和例外情况讲清楚，再确认开发范围。
- 客户选两件货：一件退款、一件换尺码；客服批准后，确认客户看到的交回指示。
- 仓库先收一件，记录污渍并放入待整理位置；核对另一件仍未收到，可售库存没有提早增加。
- 再收第二件，试换货缺码、补差价及客户改选；确认出库有对应款式和追踪号码。
- 模拟退款或库存接驳失败，再重试；财务核对退款参考，客服检查进度通知，确认没有重复款项或入库。
先接好一种商品、一个收件点
准备一份匿名订单、一张常见退货单、现行退换货规则、收件点及各人的操作权限。第一段流程可以只处理一种商品，完整走过申请、批准、实收、检查、退款或换货，再加入多门店、批次及维修分支。客服能查到货，仓库知道放哪里，财务知道哪一笔仍未成功，客户知道要等还是要补资料，这段工作才算接好。
