通过订单及售后流程的不同分析思路,看产品与研发思维的区别

本文作者将重点以图示的方式,更清晰地展示产品与研发思维的区别点。一起来瞧瞧~

电商产品设计中,订单状态及售后退款状态的流转是非常重要的一块儿内容。笔者在参与梳理和设计此流程时,自以为考虑得已经相当全面,到了技术那里依然会被称为“不全面”的方案。梳理的这些流程对于测试、运营、仓储、客服等人员来说确有很大帮助,但对于真正的研发人员并没有帮上什么忙。

然后技术人员当面给笔者演示了他的思路,顿时感觉拨云见日,仿佛来到了另一个世界!下面,笔者将重点以图示的方式,更清晰地展示产品与研发思维的区别点。

产品思维下的订单及售后流程设计

正常订单状态的业务流程图

可见正常订单的状态流转还算清晰简单,订单状态前端展示只有四种: 待付款、待发货、待收货、交易完成。 用户在付款成功后的任一阶段均可退款,但所走的退款流程却不尽相同。接下来将为你一一展示。

特别注意:笔者所在商城出于业务特殊性考虑,退款及退货流程与订单流程完全分开,互不影响。且退款流程综合用户需求和业务需求考虑,设置了一定门槛。

待发货退款业务流程图

待发货状态下,商品还未出库,一旦开启退款流程,立刻冻结订单,取消出库,以免增加成本。直至退款流程结束为止,若退款失败且申请次数使用完,则售后工单解冻,订单状态会继续正常流转,转换为待收货状态。

待收货,未确认收货时退款业务流程图

待收货状态下就涉及到物流了,属于退货退款流程,每一步都会影响进销存的变化。用户在申请退款时,可选择退款类型并提交相应信息,尤其是退货的物流信息,需要物流单号,以便仓储确认收到退货后,进行退款操作。

另外在此期间用户任意时刻点击“确认收货”,订单状态都会正常流转。因为有了上述提交物流信息的要求,即使未真实收到货,就确认了收货,对退货退款的流程也不会造成影响。

已确认收货,交易完成时退款业务流程图

交易完成是指用户已经确认收货,订单所有流程皆已走完。此时退货退款和待收货基本一致,只不过前端展示会有所区别。

好了,以上是笔者作为一名产品汪,做的流程梳理。接下来,要为大家展示程序猿同学教我的流程图。

研发思维下订单及售后流程设计

研发同学以更加严谨的方式,说明了上述流程的不全面之处,且利用了列联表的方式,将所有后台状态机需要的流转结果罗列出来,形成了下面的表格。

请注意,纵向是退款成功或失败后,订单和售后单返回什么样的结果。横向则是订单状态,以及不同订单状态下将订单与售后单拆分开来考虑。

这么一列举,16种结果一目了然。瞬间感觉自己的思路太局限而且弱爆了。当然这是后端状态机需要考虑的部分,我们平时只看到前端展示的内容,很少有机会理解后台的处理方式。

订单栏的部分是指部分退款,全部则指全部退款,仔细看退款成功或失败后二者返回的订单状态是不同的。而这点才是作为产品的笔者所遗漏的。

这件事使笔者很后悔当年大学期间没有好好学习统计学的知识。统计学里在算概率的时候经常会用到二联表-卡方检验、列联表这些工具。虽然不知道研发同学懂不懂统计学,但他的思路确实启发了我。我们考虑很多问题的时候,看似全面,实则不然,应尽可能地多角度分析,才能查漏补缺。

这还让我想起了数学里有关“排列组合”的知识,可以算作另一个角度,帮助我们思考其他问题时想得更全面些。

排列即和顺序有关,组合不牵涉到顺序的问题

举个例子,一个班级里有10名学生:① 每两人互通一封信,共通了多少封信? ② 每两人互握了一次手,共握了多少次手?

分析:① 由于每人互通一封信,甲给乙的信与乙给甲的信,是不同的两封信。所以与顺序有关是排列问题; ② 由于每两人互握一次手,甲与乙握手,乙与甲握手,是同一次握手。与顺序无关,所以是组合问题。

所以二者的计算方法自然不同,使用加法原理还是乘法原理,均要看实际情况而定。本题就不做计算了,感兴趣的话大家可以自行解答。此处也是为大家提供一个思路而已。

当然现实中我们可能很少遇到比较复杂的情况。这些方法或许不仅在产品设计,在数据分析时也能起些作用吧。更高深的统计学相关知识,笔者是真的知之甚少啦。相信社区里牛人很多,期待与你们多多交流!

文 @土豆先生

关键字:产品经理, 退款

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部