【电商设计】电商退货全流程设计（一）

订单退货，作为订单出库的逆向流程，其实还是蛮复杂的。他可以是单纯退款，或者退货退款，还有换货。本文章将从需求收集开始，展示一个退货需求的实现流程。

首先根据本公司的业务流程和需求收集，整理出业务流程图。

买家在订单发起退款，选择订单产品和数量，发起退款。如果此时订单还没有出库，不需要运营审核，直接传到仓库，拦截下架任务或者出库任务。如图

若已经在途中，目前考虑到在途召回不是很方便，我们会要求买家在收货后操作退款。

2. 运营审核

运营需要审核买家发起的退货的合理性。笔者公司平台的受众买家一般是分销商，中间商等大的客户，并非单人买家，所以从维护客户关系的角度，我们一般在确认收货日起三十天仍予以退货。若买家提交的申请有点问题，运营这边会进行打回，由买家修改后重新提交。

3. 仓库签收验货

运营审核通过买家的退货申请之后，买家需要上传寄回的运单号。由于当前公司还没有自营配送，暂且没有上门取件的功能需求。

仓库收到货后会进行签收验货操作。通过扫描运单号对相应的退货单进行签收，验货通过。若此时卖家还没有将运单号上传。则对于仓库来说这是一个没有来源的包裹。只有等到买家把退货运单号上传，退货流程才能继续走下去。

4. 财务打款

验收通过后，财务打款或者还款。

对于买家看到的状态的设计，我们按照流程的节点，做了以下状态的划分。

黄色的状态为买家看到的状态流转，一般是按买家的角度来表述。

然后我们把他单独拉出来

状态节点的划分，既要清楚明白，又不能太杂，没有对错，合适即可。

状态划分好之后，就是给出每个状态下的操作。我们知道买家可能的需求有修改申请，上传运单号，撤回申请等。那我们需要设计买家在什么状态下可进行这项操作。比如买家在什么状态下上传运单号，什么状态下可撤回申请等。以及一些异常流程的操作。

以上是前端的一个操作，对于后台运营端的操作逻辑，同样也是在流程的基础上插入状态节点

这是对于后台的一个对应的状态设计，同样也是把状态标记在了流程的节点上。然后单独看状态流转。

同样状态节点出来后考虑每个状态下的操作以及异常流程。

这样一来，整个框架就已经有了，接下来要做的就是画好每个页面和功能弹框即可。需要考虑的就是一些细节和体验的问题。具体不在赘述。

本文只单纯讨论了仅退款和退货退款的情况。只限于根据本公司的业务进行了设计。但退货流程大同小异，根据具体业务进行设计调整。至于换货，我们目前还没有这个需求。换货其实是在退货的基础上又加了一条仓库发货线，具体的有兴趣朋友可以一起讨论。