今天给大家分享一下电商后台退款逻辑的泳道图与状态操作框架，虽然这并非最先进的业务处理逻辑，但还是希望可以给初入电商后台的产品经理一些启发。以下流程还可继续进行优化。

在电商平台中，订单、退货、退款等相关业务流程，是初入电商后台的产品最难攻克的环节，流程功能基本靠口口相传，师傅传徒弟的形式在这里表现的淋漓尽致。当然不乏有一些大牛刚刚出世就颠覆了现有的逻辑。

电商退款流程中有一项业务为“仅退款”，顾名思义，退钱不退货。

仅退款环节中，用户只需要在前台发起仅退款流程申请，触发仅退款审核流程后，此时前后台开始进行审核线路流转。

在仅退款的泳道图中，角色方面规划了三方协商流程，用户先行与供应商进行协商，协商内容主要是退款申请与退款金额两方面，供应商也可进行拒绝的操作。用户与供应商之间的协商发起与拒绝次数不做限定。

为了保证用户与供应商各方的权益，避免哪一方出现无聊的行为，此时平台角色其实是作为一种最高判决机构的形式存在的，流程中用户与供应商均可以发起平台介入争议判决的流程。

平台行驶的判决权利是至高无上的，一旦平台认为争议之中过错方应承担相应责任时，即可改变当前流程所需的流转方向，对用户与供应商之间都可进行退款关闭与退款判决的决定。

退款关闭后，当前订单将再也无法由任何入口触发退款发起的环节。

仅退款泳道图：

电商退款流程中另一项业务为“退货退款”，顾名思义，一手交钱一手交货。

退货退款环节中，用户只需要在前台发起退货退款流程申请，触发审核流程后，此时前后台开始进行审核线路流转。

退货退款与仅退款流的角色、角色职能基本相同，唯一不同的在于流程上较仅退款多了用户发货与供应商收货的流程

审核流程中，供应商在收货环节中增加了一次拒绝用户申请的机会，平台介入机会也从仅退款的1次，增加到了2次。

这源于退货退款流程中包含两种元素：退货退款的申请流程与执行流程。

退货退款泳道图：

从销售角度来看，当前流程是分为售中与售后退款两种环节；两种环节中，再次细分为未发货、已发货退款形式，仅退款与退货退款是退款的两种形式。以及具体操作所对应状态，请参考下图：

退货退款状态框架：

作者：王荣，微信号公众号：PM_magic，9年互联网后台产品设计经验，主导电商后台核心业务搭建，流程、逻辑设计，多系统设计经验。

本文由 @王荣 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CCO协议