如何设计电商订单系统?
在电商体系中,商品中心、订单中心、库存系统为最重要的三大核心系统,订单系统(OMS系统)连接用户和商家之间最重要的交易信息系统,本次阐述一下电商订单系统的产品设计。
一、订单系统的作用
1.1 对用户来说
用户在下单后实时查看订单发货状态,物流信息状态和最后交易纠纷的售后流程等。
1.2 对商家来说
商家管理订单状态,实时发货,处理售后纠纷处理等,更好更快的满足用户需求,提升处理效率等。
1.3 对平台来说
在平台运营上,监管订单,处理平台介入异常订单信息,处理需求和供给两端的纠纷,提供业务支撑,实现业务闭环,提升用户价值,完善用户体验等。
二、订单系统的特点
2.1 业务类型不同,订单规则不同
订单系统搭建需要考虑实际业务情况,分商品实物订单,虚拟订单等不同业务其订单系统的设计区别都是很大,如:实物商品售卖,付费课程售卖和服务餐饮业务其电商设计都是根据实际业务划分。
2.2 流程复杂,分正向逆向流程
前端用户下单时正常时的正向流程为从商品下单,发货,收货到最后的订单交易成功;发生售后异常时的逆向流程:用户申请退货,到退款结算一系列售后流程;其规则又有很大的不同。
2.3 信息交互复杂,逻辑性强
从订单下单产生的订单经过大约20个不同子系统的一系列信息的流转,前端展现简单的页面展现,可能后端会经过大量的系统信息校验和流转。
三、怎么设计一个订单系统
从用户下单总体流程为:用户下单选择下单方式(购物车,直接下单)——订单下单——订单拆单——生成订单查看订单状态——交易成功或申请售后逆向流程等等;商家后台系统更改订单状态,对接发货,物流,售后和最终的数据统计等。
3.1 下单方式:购物车的设计(篇幅有限,有机会续写)
- 基本逻辑:购物车入口逻辑,购物车商品库存逻辑(锁定扣减逻辑),购物车的商品分开展示逻辑;
- 价格计算器:优惠类型划分,优惠计算逻辑及展示;
- 离线购物车:登录加购逻辑,未登录加购逻辑;
- 立即购买:立即购买流程;
- 异常处理:失效商品逻辑及展示,优惠失败逻辑及展示;
- 其他逻辑:凑单逻辑,商品推荐逻辑,对接的系统信息流转逻辑。
3.2 订单下单:订单信息展示
- 用户信息:用户账号,用户等级;
- 订单基础信息:父订单,子订单,订单编号,订单状态,订单时间;
- 收货信息:收货地址,收货人姓名,联系电话,邮箱;
- 商品信息:SKU信息,规格,商品数量,价格,商品图片,商家,商品链接;
- 优惠信息:优惠券,促销活动,虚拟币抵扣金额;
- 支付信息:支付方式,支付单号,支付状态,支付时间,商品总金额,实付金额,运费,虚拟币抵扣金额,促销优惠金额,优惠券优惠金额,总优惠金额;
- 物流信息:物流公司,物流状态,物流单号;
- 其他信息:发票信息,下单平台,分销渠道。
3.3 订单下单:订单拆单
下单时拆订单:父订单拆子订单
- 平台的不同店铺商家需拆单:因为涉及到商品归属权不同,其财务结算,发货情况不同所以需要拆单;
- 仓库不同,需要拆单:一物多仓的情况下,可能按照地域时效选择仓库发货物流信息不同需要拆单。
支付后拆发货单:子订单拆多个包裹
- 品类特殊包装要求需要拆单:如易碎品需要特殊包装,超大物品需要单独包装,有些不同品类的商品不能放在一起;
- 物流因素,超过物流运输限制需要拆单,如超过规定物流公司重量需要拆单;
- 商品价值:海淘商品消费限额,贵重物品商品价格高需要单独发货,需要拆单。
3.4 订单下单:订单的计算
- 订单实付金额=商品总金额+运费-商品优惠总金额
- 商品优惠总金额=优惠券+促销活动+积分抵扣+会员抵扣
3.5 生成订单:订单状态
不同业务类型商品订单状态不同,实物商品订单和虚拟商品订单状态都有所不同,订单状态最重要的是各个时间节点的数据流转,这里介绍下实物商品订单的订单流转状态:
待付款:用户提交订单,尚未付款,等待用户支付,由于待付款状态会锁定库存,所以一般会设置超时自动取消;
待发货:用户付款之后,等待商家发货;
待收货:商家已发货,等待用户收货;
交易成功:用户确认收货后,订单已完成交易;
已取消:付款之前取消订单,超时未付款或用户自动取消订单都会产生这种订单状态;
售后中:用户在付款后发货前申请退款,或商家发货后用户申请退换货状态,需要注意的是售后状态也有单独的订单流转状态:待审核,待退货入库,待退款,待换货入库,换货出库中,售后成功;
交易失败:当售后完成后的订单状态,”已取消“的订单状态可以合并到“交易关闭”中。
3.6 订单的售后:订单逆向流程
订单的逆向流程可以是用户主动发起或者客服发起,需要注意的是不同节点申请退换货,系统的处理方式不同,逆向流程复杂,还涉及到优惠分摊返还的逻辑,这里不详细介绍,以下为各个时间节点的订单售后流转情况:
待付款取消订单:用户提交订单后,主动取消订单或超时未支付时候,订单状态为“已取消”;
待发货取消订单:用户支付订单后,到“待发货”状态时,用户申请取消订单需要判断数据到哪个环节了,订单未到调度中心和就在调度中心未下发到仓库管理系统或从调度中心到了仓库管理系统(WMS系统)但拦截下来了,则可以取消成功;否则取消失败,订单继续发货;
待收货/交易成功取消订单:收到货物后,当SKU全退时,原订单变成“交易关闭”;当发生订单部分退货,退款时候,原订单保持不变,维持“待收货”或“交易成功”状态,同时生成部分售后订单,剩余的订单还可以进行售后。
3.7 订单的数据统计
订单交易维度:
统计周期内订单销售额(GMV)【最重要】
订单量:统计周期内订单量
客单价:统计周期内,已支付的订单平均金额
下单用户数支付用户数,订单金额分布,地域分布等等
商品分析维度:
被下单的商品数:统计周期内,被下单数>0的上架商品总和
被支付的商品数:统计周期内,被支付订单数>0的上架商品总和
被访商品数:统计周期内,被访问uv数>0的上架商品总和
商品收藏次数,商品销售统计,加购件数等等。
订单来源维度:
统计每个订单的来源:如H5,公众号,APP,小程序,pc端;
记录每个订单的产生过程,包括在创建之前的商品浏览,加入购物车,提交订单等关键路径的数据分析;
追踪订单来源:包括来源的网站,关键词,来源网站等等。
四、总结
订单系统与各个系统之间信息交互复杂,要求逻辑思维能力较强,对于产品设计来说,逻辑比具体的原型页面更为重要,需要考虑每个节点具体的前置后置条件,流程设计是否足够容易理解、易用。
每个系统产品设计时候都要根据实际业务情况分阶段完成,按照用最小化成本设计产品,实现业务需求,例如实物商品订单系统中订单状态栏待付款,逆向流程中退换货中换货状态等等开始也可以先不用设计,后期根据业务实际情况在进行设计。
订单系统具体的界面复杂,不同业务模式下其设计特点很大差异,多参考不同业务类型下的订单系统,门槛低的如淘宝,有赞,拼多多等等电商前后台订单系统搭建。
篇幅有限,欢迎大家交流社交语音产品,电商前后台产品的产品设计,VX:1332616842;共同交流学习,谢谢!
本文由 @十甫君 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
?
WX少一位…
讲的比较全面,干货满满 谢谢大佬!
请问大佬~ 有关于子订单的问题,用户在同一店铺下单,因为是批发购买量大一个物流包裹发不完,需要多个物流包裹,这样就需要将这个订单拆为多个子订单,那么这样的话发货的物流编号对应的应该是子订单号。但是如果不需要进行拆单的情况下,物流单号就直接对应订单编号吗,还是说一个订单编号必须要有一个子订单号,物流信息只对应子订单号?
多个包裹也应该是同一物流单号吧,为什么要拆单呢,如果如果真的出现了多个物流单号的情况,展示一个应该也是没有问题的吧,两个报过一定是同步发出的啊。
兄弟,可以参照有赞的做法,我个人觉得不错的,就是一个订单对应多个子订单,发货物流是按照子订单来走,这样的话,你的问题即可解决了
两个方案:
1.订单绑定物流号,按照商品维度绑定,前端用户展示时 根据物流号进行绑定,例如3个商品(一个SKU多数量同理),分别拆成2个(A组)和1个(B组),上传物流号时传入A组商品的物流号1,B组传物流号2,前端做逻辑处理展示,具体方案有很多,可以是点击订单查看物流,出现2个物流单里面再展示商品,也可以是A组绑在一组,点击查看物流展示该组的物流轨迹
2.销售订单是给C端用户使用,商家侧应将其转化为包裹单,原理跟上面商品分组类似,只是设计方案不同罢了,目前主流是包裹单形式。
问一下大佬你们的订单涉及到商家发货么,电子面单如何做~
请问大佬,如果是同一自营仓库同一时间出单的是不是就没必要拆分订单了呢?
肯定需要拆啊,只有拆了才能让整个流程清晰可见,仓储管理哪儿才是清晰明了
这个也要视具体情况而定。比如超大件要拆单。比如床品和桌椅板凳。这个就是楼上提到的多个包裹问题。
再比如,包含生鲜食品和非生鲜食品,因为涉及到的退换货规则可能是不一样的。
需要的,上文不是说了拆单的原因之一:物流因素,超过物流运输限制需要拆单,如超过规定物流公司重量需要拆单,比如一些跨境电商,要求单个包裹重量是不能超过规定的