Complex order process of combing Summary

To introduce the next item

Electricity supplier in the industry, is a women's clothing import business platform, combined with the virtual fitting technology, and the line fitting service for users with a need to go out you can enjoy visiting the store to try on service. After the first purchase platform for user members in the membership period may like to join in on the platform clothes fitting box can be sent to the user, without paying any fees when a box full five users get the box, try these clothes, then decide whether to buy, then do not buy clothes and then return into the box platform, round-trip shipping.

 

The article generated background, this article is doing the reconstruction order management module generated when, like the first version of all systems are established in line with the temporary version of the APP now and then more and more demand, non-stop the system added to the original function, not one day has finally found a plus, because the old system scalability is too weak, can not afford weird function, began to think of ways to sort out a module a module, things started reconstruction but this time the reconstruction has been a huge workload, any functions are already running online, can not cut a time-consuming giant long, so I think the sooner the reconstruction things were better, do first version is planned very clearly when fewer features, the more time there is no problem left over from history, the better thing to do reconstruction. So I borrowed part of the reconstruction of orders stalls to summary orders management-related issues.

 

 

Reconstruction of necessity

1, a single current state of the original single-split different product forms have been unable to cover all types of trading order processing.

2, the order will be split into different types, different types are defined background state, to facilitate the different business units targeted to process orders.

3, order split the scalability enhancements, along with the diversification of business forms, can be optimized on the different types of orders and their status, such as "7 days no reason" "sale" type of order problems demand may be involved.

 

Reconstruction step

1, the original order is split into different types of orders

2, respectively, different types of carding process and the order of the respective states

3, a conventional analog power supplier each node the control information is critical, according to the service and transplanted graft particularity

 

First come under the sort of conventional electricity supplier status Circulation:

1, to be paid: The user selected under a single commodity, but the payment of state. The next step to predict user behavior may be paid, so the next one and lock stock, but because the user does not pay, we do not know whether users will buy, so the warehouse is only temporary for the user to stay the goods, but it will not be deducted when a user after the payment, the goods will really become a user of the goods. However, because users may order the payment but has not yet been occupied by the goods can not be sold to other users, resulting in a loss, so there will be the effectiveness of the payment order for the user to retain only a short time, depending on how long this period of time different platforms have different considerations, such as take-away platform due to higher timeliness, may retain only a 15-minute orders; clothing for the electricity supplier for the timeliness requirement is very high, it is usually given 24 hours of lock time, after 24 hours payments do not automatically canceled orders.

2, to be shipped: user payment of goods unshipped state. After the payment, deduct inventory, warehouse stocking.

3, pending receipt: warehouse merchandise wrapped and handed the hands of the courier brother, orders began to update the logistics information.

4, to be evaluated: the user to confirm receipt, the seller money call, the user can evaluate orders.

5, after-sales: Users pay, regardless of the goods has not issued, the user can return the money, then apply for a refund or return all as an after state, create the appropriate after-sales ticket, there will be corresponding with service personnel into.

 

It is noteworthy that the refund and return the user behavior in each order status, first of all, not under orders payment status, the user can cancel the order directly, the final state of the order is "Canceled", will not transfer to subsequent orders state; after payment, the state has not shipped, the user can directly apply for a refund back, intercepting a library warehouse success can be directly refund orders final state is "canceled" or "closed"; in the hair after the goods, the user can cancel the order and then go direct sale process, create a single return, pushing to the warehouse, warehouse storage processing according to the audit and do a single return the goods to return, and give the user to replace the new goods.

 

These are the sort order status of conventional electricity supplier, let's look at the order of our platform, which can directly copy process, which process has its own characteristics.

 

First, our box is a way to go (platform -> Users -> Platform) is a normal process, because the service we provide is to allow the user to select five of clothes, packed into a box, then send home pilot wear, a good test before deciding whether to buy, then put the clothes do not like to return to, and round-trip shipping is free. After some research and statistics, the probability of end-users buy all the clothes 5 is very small, remain mostly shipped in parts 2 and 3 of the user, that is to say, the return of behavior is a normal behavior, the probability of occurrence of return up to ninety percent, a box back and forth or may not be involved in the transaction, and the transaction orders may not be associated with the box (such as purchase a membership service or other value-added services, etc.) so I am going to separate the box orders and trading orders, mainly detailed article He said box orders. We order the forward flow box as shown below:

 

First, to be shipping status

In general electricity supplier, the user enters the page after the election goods "confirm order", the purpose is to allow users to check whether the selected SKU wrong, and the process of giving the user a final decision, because his next step is to pay to cautious as well. When the user confirms the order to produce a single transaction, and lock the inventory, the user after a period of time to pay inventory deductions, unpaid overtime to cancel the order or inventory release the lock.

 

与一般电商相同的是,订单创建后,要占用实际的库存,所以看起来确认订单同时锁库存的操作是相同的。但是,订单创建后用户不需要支付任何费用(因为本质是试穿,到货才可能产生交易),不生成支付单,这是相比于一般电商不同的地方,就是我们在这一步没有“从支付单创建到支付/不支付”的过程,也就是锁定库存的过程,因此,我们可以不做锁定库存的操作。但是这会遇到的问题是,用户在选货到创建订单那一步,可能会发生选到的SKU被别人选走导致缺货的情况,这样就要返回重新选择,再重新生成新的订单,体验不太友好。所以在没有支付订单的情况下,我们是否需要在生成原始订单前、在选款结束到订单最终确认前做库存锁定操作?锁的话锁定多久?会不会让别的想要这件SKU的用户想选的时候可用库存已经没了,而犹豫半天的用户最终又没要,为这部分用户锁定库存造成了资源的浪费?考虑到我们初期的库存很浅,每个SKU最多5件,用户有很大的概率会在确认订单时,刚选的SKU被另一个用户秒下单而缺货,发生次数多了用户一定会觉得我们做的是假电商(骗我进来看看又不让我买那种)。对于已经进入确认订单步骤的用户来说,我们会先检验库存,保证了他们决定下单的SKU一定有货,对于还未进入确认订单步骤的用户来说,没货了尽早告诉他们,让他们心里有数,不会进到确认订单的步骤,节约时间成本,也不会有太大的负面情绪。所以我们决定还是为用户锁定库存,在选好SKU后进入确认订单的页面同时,我们就为用户锁定了库存。如果用户最终确认了订单后,订单创建,库存扣减;用户如果在确认订单的步骤中放弃了,订单创建失败,锁定库存释放。

 

订单创建后,推送至仓库ERP系统,仓库确认,并将订单拣货通知下发至WMS,由相应的拣货人员拣货、包装、称重等一系列流程后,最终出库,交给快递小哥手中,订单状态变为“已发货”。

 

二、已取消状态

在商品发货前可以取消订单。订单创建后创建相应的发货单,并推送至仓库WMS,可能已直接发货,状态未及时更新,在一般电商中,如果直接给用户退款,而仓库已经直接发货,有可能造成货款两失,所以应该先暂停订单出库,在仓库调度中查询订单是否推送至仓库,若尚未推送,则停止推送;若已经推送,则应该到WMS拦截发货,暂停出库流程;若拦截失败,则应该拒绝“取消订单”申请,因为订单已经实际出库了。在我们电商的待发货状态取消订单,由于用户尚未支付,取消订单也不会发生货款两失的情况,所以只要是在商品没有实际出库的情况下,我们都是可以直接暂停的,此时库存会相应的加回来。

 

以上是订单出库之前的状态,接下来会涉及到的是订单在路上和反向的过程。

 

三、已发货状态

订单在快递小哥手中时会显示这个状态,并且根据发货物流单号获取物流的动态信息。一般的电商中,这个状态下用户可以确认收货,若在物流状态更新为“已签收”后的一段时间内,比如9天未确认收货,订单会自动确认收货。我们平台的订单不会给用户主动确认收货,因为对于用户来说,他们只是叫了几件衣服到家试穿,购买行为是后置的,如果用户迟迟未购买也未寄回,会造成资源大大的浪费,而且服装容易过季,超过半个月再返架,返架前还需要运送、审核、清洗等一系列流程,此时的服装不一定在售了,所以我们会给用户一个比较短的时间试穿,并且这个时间以物流信息“已签收”为准,但是由于我们接了第三方物流查询接口,获取的物流动态做不到实时更新,而且非常有可能是快递小哥送到了但是用户没时间取货,那如果直接按照物流“已签收”状态开始倒计时,用户也不太能接受,所以我们定的时间是“从物流更新为“已签收”的次日凌晨0点开始的72小时”为用户可以试穿的时间,超过这个时间若未将衣服买下或退回,则订单逾期,要有相应的记录,给我们做用户分层和风控中心做参考信息,因此,逾期的订单只要一旦逾期了,就会一直跟着这笔订单,未必对用户可见,一方面对那些真的有特殊原因不小心逾期了(比如说,工作日家里没人,只能预约到周末,但是到了周末就超时了),此时如果用户看到自己的逾期不良记录可能会产生消极的情绪;另一方面对于那些恶意买家,给他看到逾期也不会改变什么,所以逾期的记录只要内部工作人员可见即可。

 

从本质上来说,一般电商的“确认收货”基本等于我们的“购买”,因为同样是确认把钱款付给卖家,一般电商是支付平台把钱打给卖家,我们是实际收到用户的款项。

 

四、已付款状态

如上所说,我们的购买行为是后置的,用户只有自己实际拿到货时才决定是否购买,所以此时交易订单创建同时不需要锁定库存,这是跟一般电商不太一样的地方。我们原来是不想做“交易订单”这件事的,因为当时希望的是用户尽快地进入付款的流程,多一步操作搞不好就不买了,这是老板提出的论调,我很理解老板的担心,但这一步存在一定有它的理由:一般电商需要这一步除了要锁定库存外,还要锁定商品价格、优惠信息,这两个信息时效性很高,即便我们这步不用锁库存,但也要锁定价格、优惠信息,很有可能用户下单寄出时是这个价格,到手后要付款了是一个价,实际支付的时候又是另一个价,支付系统也不知道收哪个,而且我们有些优惠信息时效性更高,可能1分钟后不真的付款,不创建交易单来锁定的话,万一由于网络原因支付失败了,返回再重新进入交易流程,优惠信息没了,岂不是很不开心,后台开发人员在系统设计时也会创建交易订单,只是是否对用户可见,而且,一般电商都有创建交易单的操作,用户也已经被市场教育得很认可了,没有必要再做改变。

 

接下来,就进入了订单的反向的流程。如前文提到的,这样区分是向仓库方面靠拢,仓库的各方面业务都比较完善,比如反向流程可能不仅仅是退货,后续还会有换货,所有的套路都很完善,所以就捡成熟的方案用起来。下图是反向订单流程:

 

 

 

五、待寄回

在我们的平台中,用户付好款后(或一件都看不上的),可以直接在APP中预约快递,只需要填写上门取件地址和时间,就会有快递小哥上门取件,取件后,用户可以继续叫盒子,保证用户一次只能叫一个盒子,但是再会员有效期内可以叫多次。在预约快递,到快递小哥实际揽件的状态为“待寄回”状态。从这里开始,订单开始走反向流程,即一般电商中的退换货/售后流程。

 

用户将不需要买的商品勾选好后,预约快递,选择取件时间和地址,退货单创建,同时创建物流单。退货单创建同时推送至仓库ERP系统,仓库操作员根据退货单号、物流单号、应退商品等信息进行验货、清洗以及入库操作,平台根据ERP对商品的审核状态将订单置为“已完成”。

 

在退货单创建前,也就是成功预约快递之前,都是可以购买商品的,并且可以分多次购买,因为发现女生的购物习惯很不确定,5件衣服中经常会有个一两件衣服想买但是又不太舍得买,但是放了几天后想想还是买下吧,有点像淘宝退货,申请退货后还是支持用户取消申请的。此时一个盒子订单就可能与多个交易相关联,这也是把盒子订单和交易订单分开的原因,业务的可扩展性增强。

 

六、寄回中

快递小哥取件后,到快递被仓库签收的过程为“寄回中”。

 

七、待审核/异常/已完成

仓库签收退回货品,到验货完成之前,订单状态为“待审核”。商品从用户手中退回的时候不一定全为完好无损的,可能是奇形怪状的,有的可能沾有口红印子,有的起球严重。完好无损的货品是经过清洗、熨烫以及再次包装的操作后可以直接入库变为可销售库存;奇形怪状的货品经过审核后确定无法还原后,不能入库变为可销售状态,只能进入次品仓。当然相信大部分用户都是正常用户,退回的商品基本都是良品,少数用户会退回次品,也很少有平台会跟消费者扯皮,通常都是自认倒霉,只是完善的电商平台会有自己的风控系统,某个用户退回的次品过多,协商未果,就认为这个用户信用不好,或是拉黑等等,他们以后的购物也会受到影响。当然不管是良品还是次品,我们都需要得到一个统计的结果,退货单中每一件商品都是良品时,订单自动完成;有次品出现时,订单会先到“异常”状态,由客服去协商了解情况后,手动将订单完成,并填写备注。

 

订单的各个状态间的流转就是以上了,总的来说自己摸索着做还是有些难度,但是工作了这两年现在才算是有了点步入专业的感觉,不是说做出来的系统有多么专业,而是说在摸chao索xi的过程中做到了仔细思考,为什么别人这么设计,这一步为什么不能直接移植过来?要做出哪些改变?这样设计是最优解决方案吗?是否还有更完善的方案等等?这才是产品经理应该做到的工作吧。希望以后多做出这些总结,然后跟大家一起成bao长fu!

 

Guess you like

Origin www.cnblogs.com/sidesky/p/11373375.html