由于历史原因，官网并未做订单逆向流程，每天所有的退款都需要客服人员手动录入系统处理，不但效率低，还容易出错。因此这次做订单系统规划时（也考虑了逆向流程），主要从以下几点介绍：

1. 订单状态机

逆向流程节点及其状态确定，见图：

总结：订单状态的确定，我们当时规划的时候和研发同时开了三次会，最终确定；经过就不多说了。主要说下订单状态确定思路吧。

我们当时是先画了一个订单的主线流程图，然后在订单的主线流程图每个节点开始考虑都会存在哪些状态；最终前台确定了这六个状态，但后台的订单状态可远远不止这些；基本上要比前台的状态多了一倍还要多；当然会有这么多状态，也是因为交互的系统比较多导致；一般初期的电商系统这几个状态也够用。

2. 退款场景

从状态机中不难看出，退款发生的场景主要有以下几类

未付款时，取消订单；系统自动取消订单一般会根据自身公司实际情况来决定；我们当时是因为有占存的概念，因此暂定是30分钟 已付款待发货申请：因为公司的仓库都是自己的，可以控制；因此可以根据实际情况来做拦单，同时客服审核后可直接退款 已付款且已发货申请：这块一般公司会根据自己的规则决定是否先行退款还是是收到退货后再退，一般业务会根据实际情况处理售后。在此，既要考虑用户体验，又要考虑商品退货风险

3. 退款业务流程

其实，做后台系统，需求调研的时候，他们也说不出个一二三，除非经验比较深的，或许能提出一些信息点；很多时候是需要产品经理主动给出一条思路进行引导的；经过和相关部门的沟通，最终确定了业务流程，具体如图：

用户操作流程图：

总结：根据不同的订单状态，显示不同的退款类型入口。

一般对于退款申请，未发货的订单申请退款都可以整单申请退，逻辑上相对要简单一些；如果是退款退货，相对来说比较复杂

A. 无各种优惠的时候 ，选择某一商品申请退款，申请后按业务流程处理即可； B. 订单有优惠的时候，选择某一商品申请退款，则牵涉到退款金额的计算。

如：两件商品A（20元）、B（80元），订单共100元；提示满90包邮；现在用户申请退A商品，就牵涉到退款金额计算；是按比例退款，还是是按实际售价退；所有的金额计算要和相关业务部门沟通，根据实际情况来确定退款金额计算规则后执行。

4. 后台系统交互

经过和其他系统的产品经理沟通，最终的交互图也确定了下来。当然出具的这些流程图需要根据公司的实际情况来设计规划，提供的只是些可借鉴的图

5.原型图和PRD

根据上述的流程图大致清楚了列表及其功能点。也就可以逐步出具原型图和PRD了。

原型和页面不做过多介绍，其实都是按照上述的流程图确定页面和功能点后，按照实际需要来出具原型视图，毕竟对于业务来说，这些他们最直观了解产品的初衷。

客服退款审核列表

客服退款审核详情

财务退款详情

总结

1. 用户填写的退款申请，是需要区分是退款还是是退货的。

未发货的退款—可以直接进行系统退款的 而退货，是需要查询退货登记中是否已签收的 只有已经签收的财务才会去退款，当然，客服也可以根据实际情况来决定是否要提前给用户退款

2. 如果公司无多个系统，退款也就不会有多个系统复杂交互；做产品最终还是要根据公司实际情况考虑，而上面的流程，仅是我工作总结得一部分。

不洗勿喷，有不正确的地方，还请同行们指证。