【干货】电商业务退货、退款泳道图与状态操作框架分享
今天给大家分享一下电商后台退款逻辑的泳道图与状态操作框架,虽然这并非最先进的业务处理逻辑,但还是希望可以给初入电商后台的产品经理一些启发。以下流程还可继续进行优化。
在电商平台中,订单、退货、退款等相关业务流程,是初入电商后台的产品最难攻克的环节,流程功能基本靠口口相传,师傅传徒弟的形式在这里表现的淋漓尽致。当然不乏有一些大牛刚刚出世就颠覆了现有的逻辑。
一、仅退款-业务
电商退款流程中有一项业务为“仅退款”,顾名思义,退钱不退货。
仅退款环节中,用户只需要在前台发起仅退款流程申请,触发仅退款审核流程后,此时前后台开始进行审核线路流转。
在仅退款的泳道图中,角色方面规划了三方协商流程,用户先行与供应商进行协商,协商内容主要是退款申请与退款金额两方面,供应商也可进行拒绝的操作。用户与供应商之间的协商发起与拒绝次数不做限定。
为了保证用户与供应商各方的权益,避免哪一方出现无聊的行为,此时平台角色其实是作为一种最高判决机构的形式存在的,流程中用户与供应商均可以发起平台介入争议判决的流程。
平台行驶的判决权利是至高无上的,一旦平台认为争议之中过错方应承担相应责任时,即可改变当前流程所需的流转方向,对用户与供应商之间都可进行退款关闭与退款判决的决定。
退款关闭后,当前订单将再也无法由任何入口触发退款发起的环节。
仅退款泳道图:
二、退货退款-业务
电商退款流程中另一项业务为“退货退款”,顾名思义,一手交钱一手交货。
退货退款环节中,用户只需要在前台发起退货退款流程申请,触发审核流程后,此时前后台开始进行审核线路流转。
退货退款与仅退款流的角色、角色职能基本相同,唯一不同的在于流程上较仅退款多了用户发货与供应商收货的流程
审核流程中,供应商在收货环节中增加了一次拒绝用户申请的机会,平台介入机会也从仅退款的1次,增加到了2次。
这源于退货退款流程中包含两种元素:退货退款的申请流程与执行流程。
退货退款泳道图:
三、售中退款、售后退款
- 售中退款可分为:未发货退款(仅退款),已发货退款(仅退款、退货退款)
- 售后退款可分为:已发货退款(仅退款、售后退款)
从销售角度来看,当前流程是分为售中与售后退款两种环节;两种环节中,再次细分为未发货、已发货退款形式,仅退款与退货退款是退款的两种形式。以及具体操作所对应状态,请参考下图:
退货退款状态框架:
作者:王荣,微信号公众号:PM_magic,9年互联网后台产品设计经验,主导电商后台核心业务搭建,流程、逻辑设计,多系统设计经验。
本文由 @王荣 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CCO协议
主干流程是有的,但描述过于粗狂,不够深入。
挺好
你好,为什么售后退款任何操作都不改变订单状态,难道不是退款成功后,订单状态变为交易关闭吗
同问,我也是很疑惑。
同问这个问题,我竟然还给自己强行解释了一波,哈哈~
一般来说,订单状态和售后单状态相互独立;因为会存在一个订单中存在多个商品,只退其中一部分或只存在一个商品有多个购买数量,只退其中一部分的情况;如果售后状态能影响订单状态,那多商品这种情况就需要做判断,反而搞复杂了
想明白了,谢谢作者的回复~
售后退款情况复杂,应客户与商家进行协商处理,如果货物破损严重,协商全部退款且不退货,订单没有必要关闭,不管全部退款或是部分退款,订单未产生相应退货,用户所购商品已到达用户手中,又怎能判断为订单关闭呢?
未发货退款时部分退款又怎么处理呢?
未发货订单,不存在“部分退款”场景
肯定会存在啊,比如我一个订单买了10个商品,都还没发货的时候,突然某一件不想要了,就退掉一件
强行按照商品梳理拆开某一个订单,更何况你不付款商家是不会发货的
退款单未处理完时,商家点发货时会提示:订单中部分商品买家已经申请退款,继续发货会关闭退款申请,是否要继续发货?如果商家仍然发货了,那退款单状态为退款关闭,订单变为待收货状态。
如果商家已经退款给买家了,退款单状态为退款成功。订单继续停留在待发货状态,商家发其他未退款的商品。发货后,订单为待收货状态。
赞!一点小问题:
平台拒绝申请–>退货关闭,用户确认收货–>退货关闭,这两种情况都是平台的判断结果是平台行为,那么“退货关闭”是不是放在平台泳道比较合理呢?
整体功能流程清晰,学习了,感谢分享!
流程图多个交叉也可以的?
待发货的订单申请退款,平台最终拒绝退款申请后,之后的流程如何处理?是继续走商家发货流程还是直接订单关闭?
走平台介入流程,需要人工处理了
正常来说,平台不会拒绝,因为没有发货退款很正常,拒绝会得罪用户。
但是平台如果真的拒绝了(比如定制类产品),那就是退款单关闭了,订单继续停留在待发货状态,商家发货,这样很可能得不偿失,用户会给差评啥的。
同时退款审批单是不是也应该有单独的状态:待审批、审批中、审批完成(包括同意/不同意)
因为可能不止一道审批;
希望能够解答一下 😉
所以退款单的状态一共就是有:待退款,退款中,退款完成,退款关闭四个状态
那如果涉及到退款审批的话,退款单的状态是不是应该变为:待退款 、待审批、退款中、退款完成、退款关闭五个状态呢?
很有含金量的干货
请问怎样理解【系统触发】?
系统所触发的内容,为退货退款中的正向流程,比如供应商超时未处理,那么为了用户体验着想,缩短供应商的审核周期,系统默认认为供应商同意退款操作(或者理解为供应商放弃使用权利)。
刚才看了作者之前的解释,才发现这里的“确认收货”与我的理解不同,是指客户只有在收到货物后再能发起退款、退货流程,我觉得这个环节应该发生在退款流程之前,而不是流程之中,这回造成歧义。
而且我觉得应该存在商家确认商品在于客户对款的流程。
用户有两种退货退款方式,第一个是售中退款,第二个是售后退款,第一种方式不需要进行确认收货就可以发起流程,确认收货只是作为用户在第一中情况中主动终止退货退款的一种形式。第二种方式是以确认收货后发起的退款方式。
运营商确认收货又退款失败,这货要怎么处理?
怎么处理?
有一点疑问,在“仅退款”、“退货退款”两个泳道图的“用户”泳道中,“填写申请退款金额、理由”直接与“确认收货”相连接,个人觉得这个“确认收货”应该出现在供应商泳道中,情景应该是在供应商收货确认后再给与用户退款,缺少相应环节。
这只是说明在用户填写协商退款金额时,如果进行确认收货操作,那么将终止这次的退款流程。
很基础,是干货
售中售后状态看懵了……,学习了
专业的
不错 学习到了
同问,确认收货-关闭退款这个流程是什么意思呢
在用户成功发起申请退货退款流程后,流程将进行退货退款流转,同时,在流程发起后,用户同样具备对当前订单进行收货的功能。一旦用户在当前流程中就行确认收货,也就意味着,用户已经对货物不存在争议了,也许这之间用户与供应商协商了些什么,这方面我们不去追究。
确认收货功能,是用户关闭退款申请的一种方式。
你好,我有几个问题,请教一下。
1、用户是在平台购买的,为什么申请退款要供应商审核呢?不是应该直接到平台吗?然后由平台和供应商沟通。
2、同意退款之后,钱退给平台还是退给供应商了?正常应该是平台
3、用户在平台购买,但是退款时却要供应商来审核,如果拒绝了,那用户体验会很差,然后再去找平台,平台再和供应商沟通,无形中多了一步用户和供应商之间的联系。(和1有点像的问题)
4、我理解的只有买的商品有问题,需要售后处理才会有供应商的人员介入。
我的理解是:用户退货退款,先告知供应商并进行协商,协商无果后再通知平台介入,可能跟现在的一些电商售后处理不一样了
你的理解完全正确,这取决于电商应用的是哪一种模式。
嗯,一般退货都得先经过供应商同意,因为要审核商品是否完好无缺,但是淘宝有极速退款,就是只要申请退款,钱立马到账
这个流程所归属的电商模式为供应商入住的店铺形式,所以用户是与供应商直接沟通,平台在一定程度下仅仅作为交易场所存在
嗯,明白了。自营和三方入驻的两种流程。那前端展现其实要对用户提醒的清楚。
两种形式在前端的展现是有绝对性区别的,而且在QA中也会有相应体现。用户业务通道环节中,也会有明确展示。这都是用户体验的功底。
流程扭转方面,后台是重中之重。
能否加你好友???
问个问题,为啥已经是退款流程了,还要有:确认收获》关闭退款的流程呢?
因为有可能用户和供应商达成了退款协议,达成了“不退货仅退款”的条件,所以这种时候,用户是可以点击“确认收货”的
清楚了,谢谢!