订单系统设计

电商所有模块中,订单系统作为最为核心的模块,决定了整个流程能不能顺畅的执行,起着承上启下的作用。相信很多PM都不陌生,到了一家电商公司,总会觉得公司现有的流程有不少问题,因为问题来自四面八方,一下子摸不着到底是哪里出了问题,PM就跟补丁师傅一样,遇到一个补一个。其实很多日常开发和测试提得需求都是表面需求,而这些表面上呈现出的各种问题,都是源自于流程上的不完整或者流程上某个环节上的缺失导致的。订单系统作为一个承上启下的模块,流程上出了问题,它肯定脱不了干系。

订单系统分为用户端和商家端,今天我们从商家端简单分析一下订单系统该如何设计和完善,才能不断适应公司的业务发展,减少因为流程导致的不必要的返工和“补丁”。为什么说订单系统是承上启下的作用,上游是什么,下游又是什么?这里我们先把问题放在这,后面讲到再作解释。

订单系统

设计订单系统需要考虑几个模块,只有所有模块都考虑清晰了,才能保证订单系统的稳定性和可扩展性。

订单字段

订单系统设计

其实呈现在界面上的订单信息,都是由各种订单字段组合而成。订单字段齐全从某个程度上代表着订单流程的完整。

订单字段包括几个部分,其中金额信息因为特殊性,独立出来讲,实质上金额信息属于商品信息。

商品信息:商品信息属于订单系统的上游端,所有订单都是从商品演进而来,从商品到订单,订单系统必须搜集相关的商品信息,包括店铺信息,商品id,商品规格,商品数量,商品价格。获取到的商品信息将在订单详情页内展示,形成订单信息后供仓库方便拣货,包装。

用户信息:用户信息包括购买用户的ID,收货人,收货地址,联系方式。有些平台的用户成长体系是基于用户对平台的活跃度来计算的,例如京东,它有会员等级及积分卡等类似的成长标识,此时获取到的用户信息除了普通的信息字段外,还需要获取该用户的等级,该次购买后所获得的积分,以及该用户所在等级能在该订单上扣除的优惠等信息,具体怎么操作取决于公司的业务方向。

金额信息:因为金额信息的特殊性,所以独立出来讲,理论上金额信息应归属商品信息。金额信息的特殊性在于其不止一种金额,其涉及到商品金额,优惠金额,支付金额。而优惠金额中涉及到的信息较复杂,像有自营和第三方入驻的电商平台,都会有商家优惠和跨店优惠,而这些优惠又分不同类型,例如现金扣减,消费券扣减,积分获取,礼品卡扣减,或者以上几种的组合使用。想要涉及好这一块内容,需要根据目前自己公司的业务情况,列出所支持的优惠类型,再枚举出各种组合下的优惠类型,才能保证流程的完整性。

时间信息:记录各个卡点下的时间,一是记录,二也是方便售后验证和客户分析。订单时间是根据订单状态改变而改变的,比如我们常见的用户,下单未付款:即展示订单创建时间,下单时间;待发货状态:展示订单创建时间,下单时间,支付时间;待收货状态:展示订单创建时间,下单时间,支付时间,发货时间;交易完成状态:展示订单创建时间,下单时间,下单时间,支付时间,发货时间,完成时间;待退款状态:展示退款订单创建时间,申请退款时间;交易关闭-用户取消:展示订单创建时间,下单时间,用户取消时间;交易关闭-仅退款:订单创建时间,下单时间,支付时间,退款申请时间,退款成功时间;交易关闭-退货退款(包含部分仅退款):订单创建时间,下单时间,支付时间,交易完成时间,退款申请时间,退款时间;时间信息看起来不重要,其实是订单系统一个重要的组成部分,原因大家可以思考一下。

订单信息:订单信息在订单系统最为核心,订单信息最重要的又是订单状态。很多公司都有订单状态机的说法,那到底什么是订单状态机,我个人的理解是在订单中,通过各种购物情景,触发订单状态,将订单的流转可视化,是订单状态机的一种具体呈现形式,而它实质就是在描述订单状态的转换。电商购物中,订单状态分别有以下几种:【待付款】【待发货】【待收货】【待评价】【交易完成】【用户取消】【仅退款】【退货退款】。而我们一般会将后三种统一放在订单售后独立呈现,去方便平时商家操作的便捷性。

订单系统设计

订单系统的完整性离不开几个部分,上面讲订单字段,各种字段信息组成了一个订单详情页。如果将字段信息比喻成订单系统的血液,那订单状态的切换就好比订单系统灵活的神经,没有订单状态之间的切换,就构成不了庞大的订单系统,也满足不了很多网购时各种情况。

订单流程

订单流程是指从订单产生到完成整个流转的过程,其中包括正想流程和逆向流程。正向流程就是一个正常的网购步骤:订单生成-->支付订单-->卖家发货-->确认收货-->交易成功。而逆向流程则是各种退款流程。

正向流程

订单系统设计

订单正向流程

整个订单设计的流程其实是非常多的,接下来我们将从比较具体的描述一下各个环节下的实际情况:

订单生成:用户下单后,系统需要生成订单,此时需要先获取下单中涉及的商品信息,然后获取该商品所涉及到的优惠信息,如果商品不参与优惠信息,则无此环节,接着获取该账户的会员权益(这里其实需要注意的是,优惠信息与会员权益是有区别的,就好比商品满减是优惠信息,新人立减是会员权益。一个是针对商品,另一个是针对账户)。库存扣减是指可销售库存数量-1,严格来讲库存扣减目前分为两种,一种是下单减库存,另一种是付款减库存;个人觉得中小创业者也许竞争者不比淘宝中的卖家,在电商这个存量市场,需要精细化的运营才能存活下来,如此说保证用户体验才是根本,所以我这里的观点是生成订单扣减库存,这种做法会避免用户支付成功商家却没货的情况。然后计算运费,订单生成成功。

支付订单:用户支付完订单后,需要获取订单的支付信息,包括支付流水号,支付时间等。支付完订单接着就是等商家发货,但在发货过程中,往往还有一种情况存在,很正常却也比较复杂,就是订单拆单。订单拆单分两种,一种是用户挑选的商品来自于不同渠道(自营与商家,商家与商家),此时就需要拆分订单,并分开结算,这里还涉及父子订单的说法,这里不再赘述。另一种是在SKU层面上拆分订单。不同仓库,不同运输要求的SKU,包裹重量体积限制等因素都需要将订单拆分。比如商品A只在甲仓库有,商品B又只在乙仓库有,此时会将商品A与商品B拆分成两个订单。或者有些企业的做法是将商品A/B调拨到另外一个仓库统一发货,也方便了用户。订单拆单看起来简单,其实里面涉及到底层的系统支持,如你需要对每一个仓库的货品进行相对准确的盘点,且做到实时同步(涉及到仓库精细化管理);对商品进行准确分类与摆放;对商品信息记录准确无误等;这其中哪一模块都是一个浩大的工程,PM一般进入一家公司都会在原有(半成品)的基础上进行优化,大家不妨多思考一下底层业务,只有在底层做好精细化管理,才能支持线上丰富的用户需求。

商家发货:商家发货过程也有一个标准化的流程。上面也有讲到,订单拆分时会涉及到仓库间调拨,然后仓库会对商品进行打单,拣货,包装,交接快递配送。这套标准化流程如果优化好,也是一个大工程,这里不再赘述,建议大家看看库存与仓库管理方面的书籍,详细了解。

确认收货:商家发货后,就是等快递配送了,订单系统需要接入一些常用快递企业的接口,方便用户与商家在站内查询快递信息。

交易成功:收到货后,不是一个服务的结束,相反是一个服务的开始。订单系统需要在快递被签收后提醒用户对商品做评价,这里要注意,确认收到货不代表交易成功,交易成功是指在收到货X天的状态,此时订单不在售后的支持时间范围内。到此,一个订单的正向流程就算走完了。

目前我也没有研究过,不过我的经验告诉我订单系统对售后订单的处理并不比正产订单少,身为电商PM,我们的工作就是去优化这些流程,提高用户粘性。本身售后订单的出现,在某种程度上已经伤害到了用户,如果流程还一团糟的话,我们根本没有机会等到用户的复购。

逆向流程

订单系统设计

订单逆向流程

一个电商的基本逆向流程如上图所示,订单的逆向流程复杂就在于它几乎允许在正向流程的任何环节出现,有人会问,用户未收到货为什么还能退款,其实我们换为思考,也很容易理解,假想你是用户,买了一双鞋子,付了款发了货,正在美滋滋的等待收快递,然后刚好路过一家鞋店看到刚买的同款鞋子大促销,于是你就拿起手机点击退款,买下了这双促销的鞋子。这种场景其实是很普通也很正常的用户日常,所以我们的订单系统就必须得支持用户各种丰富的场景需求,也十分考验PM的业务渗透能力,好在电商的先行者淘宝已经做了很多基础建设和用户教育,我们直接可以拿来套用,不过还是要根据各个公司的业务情况进行修改。

取消订单:用户提交订单时,在跳转至支付前直接退出,此时用户原则上属于取消订单,因为还未付款,则比较简单,只需要将原本提交订单时扣减的库存补回即可。

支付失败:用户进行支付时退出,或者取消支付,我们将其列为支付失败状态,此时处理同上,将扣减的库存补回可销售库存即可。

付款后退款:用户支付成功后,商家还未发货,支持用户申请退款,此时如果仓库与客服是分离的,则需要先检查仓库是否已经发货,若已发货则应与客户沟通是否可以收到货后再进行退款,如果仓库还未发货,则可直接同意用户退款。或者企业接入菜鸟物流,实行截件功能,不过这种操作还不成熟,成本会比较大,不适合中小创业型公司。

缺货退款:用户支付成功后,商家发货时发现仓库缺货(如果提交订单扣减库存,则会减少缺货情况,为什么是减少而不是避免?因为仓库管理商品时没办法做到100%精准,所以信息有时候会不准确,导致线上的可销售库存显示有库存而仓库已经售空的状态),则需要与用户协商是否退款,这个流程订单系统可以做到流程化,自动化,连接消息中心和仓库管理系统去实现,难点在于消息的实时性。我就遇到过在淘宝买过一件上衣,一天过去了,商家跟我说没货了,我当时杀人的心都有了。

待收货退款:这个问题目前还没有特别完美的解决方法,商家发了货之后,用户还未收到货,此时货在路上。我曾经在一些交流群里提出过这个问题,大家的看法都不一样,大体上分为两种做法。一种是用户收到货后重新寄回;另一种是用户直接拒收包裹,包裹直接退回原地址;我个人倾向于第一种,第一种比较灵活,因为用户未收到货就退款的原因一般与商品质量关系不大,所以如果允许用户直接拒收退回,相当于商家需要承担回退运费,而本身可能与商家并无太大关系。另外一个原因就是,有些商家发货地址与退货地址不在同个地方,不支持直接退回。尽管如此,在到处强调用户体验的今天,增加用户的售后成本也是在消耗用户对平台的耐心,大家不妨去思考一下,有没有更好的解决方法。

用户拒收:同上

退货退款:用户收到货后,想要申请售后,则此时需要提供让用户输入售后原因,包括上传凭证的功能,如果与商家协商无果,还需要增加平台客服的入口,方便用户进行申诉。而协商结果/申诉成功后直接触发自动退款机制,退款后触发消息通知,同时触发交易关闭状态,整个售后过程才算结束。

我上面有好几处都提到与消息中心的对接,消息的触发等,其实这也算是订单系统设计的一部分内容,称之为订单推送,当订单状态机发生变化时,需要将对应的变化情况告知给相关人员以便了解当前订单的情况,这也是订单推送的作用。

订单推送

订单推送的触发依赖于状态机的改变,涉及到的信息包括:

· 推送对象(用户,商家,仓库)

· 推送方式(站内消息,push,短信,微信)

· 推送节点(状态机)

本文主讲订单系统的核心模块设计逻辑,订单推送的具体设计就不再此处赘述。

结言:

一个订单系统的设计绝非这么简单,它需要一批又一批的人去维护,去优化,根据公司的业务情况做出改变和兼容。

相关推荐