天猫高级产品经理分享:电商平台的订单设计流程(案例带附件模版)

一、主流电商产品的订单状态

淘宝的订单状态主要有待付款、待发货、待收货、待评价、已关闭、以及退款中。

京东的订单状态主要有待付款、待收货、已完成、已取消等。

有赞的订单状态主要有待付款、待接单、待发货、待收货等。

二、最常见的订单状态

根据以上平台以及大家平常的网购经验,不难理解电商平台都会包含以下5种状态。

  1. 待付款:代表买家下单了但是还没有付款。
  2. 待发货(同待接单):代表买家付款了卖家还没有发货。
  3. 已发货(同待收货):代表卖家已经发货并寄出商品了。
  4. 已完成(同待评价):代表买家已经确认收到货了。
  5. 已关闭(同已取消):代表订单过期了买家也没付款、或者卖家关闭了订单。

三、主流订单状态变化

知道了订单状态还不够,PM还需要了解这些订单状态如何变化,以及相应的触发条件。

3.1 从无到待付款

触发条件:下单

当用户生成了订单,产生第一个订单状态“待付款”,该状态为开始状态,即每个订单的第一个状态都会是该状态。

3.2 从待付款到待发货

触发条件:付款

当买家付款成功了,订单状态从待付款变成待发货。

根据实际业务可以细分触发条件,所谓付款成功是根据付款结果回调来判断的,那么可以详细的列出每种付款渠道:比如余额/支付宝/微信/额度等。

3.3 从待发货到已发货

触发条件:发货

当卖家发货了并在系统上输入相关信息后,订单状态从待发货变成已发货。

根据实际业务可以细分触发条件,所谓发货成功有可能包含无需物流和需要物流两种情况,分别对应虚拟商品和实物商品。

3.4 从已发货到已完成

触发条件:确认收货

当买家收到商品并在系统上确认收货后,订单状态从已发货变成已完成。

根据实际业务可以细分触发条件,所谓确认收货有可能包含买家点击了“确认收货”按钮,或者超过指定时间后系统自动确认收货,另外部分B2C自营物流商城会根据物流签收状态来自动确认收货,比如京东自营商品。

3.5 从待付款到已关闭

触发条件:关闭订单

当用户超时不付款,订单就会自动从待付款变成已关闭。当然某些电商平台也允许卖家手动关闭订单,或者买家手动关闭订单。

四、其他订单状态变化

除了上述常见的订单状态变化外,还有一些支线需要考虑。尤其是部分发货和退款。

4.1 从待发货到部分发货

触发条件:选择部分商品发货

当卖家选择了订单中部分商品进行发货,此时订单状态有个子状态叫做部分发货,当卖家把剩余的商品都发货成功,此时订单状态才变成已发货。

4.2 从待发货到退款中

触发条件:选择某个商品退款

当买家在待发货的时候,选择了订单中某个SKU进行退款,此时订单进入子状态:退款中。

4.3 从已发货到退款中

触发条件:选择某个商品退货/退款

当买家在已发货的时候,选择了订单中某个SKU进行退货/退款,此时订单进入子状态:退款中。

有了商品之后才有可能产生交易。所以先讲了《B2C自营商城的商品设计方案》,这篇讲解我们的订单模块怎么设计。

一、订单是什么

订单的本意是指你购买商品之后生成的单据凭证,只是在电商中,它是虚拟的。

主流的下单方式

整个电商体系中常见的下单方式有2种,购物车下单直接下单

淘宝称之为购物车结算和立即购买,正常情况下你可以任选一种去购物。但是在秒杀之类的特殊场景中,只支持直接下单。

京东也称之为购物车结算和立即购买,不同的是,正常情况下你必须通过购物车去结算,秒杀情况下你可以选择立即购买和购物车结算。

订单的类型

由于不同的下单方式,其实导致订单的类型有2种。

简单来说购物车结算的订单肯定包含了基于sku不同的多个子订单,而每个子订单包含n件同一sku。而立即购买的订单是包含n件同一sku。

然后淘宝的PM因为后续增加了购物车结算这一下单方式,而不得不想出一套规则,那就是父订单和子订单。当然还有很多其他原因。

此次购物,整体称之为交易,生成了一个父订单号。如果它是购物车结算,那么有N个子订单。如果他是立即购买,那么只有1个子订单。

从技术角度来定义,那就是trade称为父订单,order称为子订单,或者说trade是一笔交易单,子订单是每笔交易中的商品明细单,trade与order可以是一对多的关系,trade是由使用购物车生成。

当一笔交易只有一个子订单,那么tid=oid,这个时候主要看trade结构体里面的内容,当一笔交易有多笔子订单(类似于购物车购买方式),那么tid=oid,这个时候主要看order结构体里面的内容。

二、订单的逻辑拆分

根据以上的规则,订单逻辑上面应该按照这样的方式来拆分。

基于这样的设计方式,才可以去支持退款退货,以及设计活动、优惠券等营销功能。

三、订单的金额拆分

进而得到订单的金额是如何拆分的,其中营销得来的优惠拆分到每一个子订单,以及每一个sku的实际支付单价。

四、订单状态机

订单的状态是一个很复杂的事情,决定着用户,商家的每一个操作。

不含退款退货

如果你们的商城比较特殊,无需提供退款退货功能,那么订单状态机比较简单。

包含退款退货

那么比较复杂,相当于多了一层状态机。具体可以查看我的另外一篇文章《如何绘画状态机来描述业务变化》。

五、总结

订单模块的架构设计,以上基本上把主要的内容讲了一遍。按照这样的方式去设计,至少可以兼顾大部分商城的订单需求。

以上内容可以点击我的订单模块原型来详细查看。

至于订单模块和商品模块,和营销模块的耦合,后续的文章会再讲讲。

主要讲讲服务端的架构设计以及商品呈现逻辑。可能对某些PM来说有点难理解,但是我认为这是设计商城系统的PM必须具备的架构能力,而且算是比较基础和底层的部分。

一、商品的基本概念

1.1、对用户而言

一般来说有产品、商品、赠品等概念。

1.2、对数据库而言

可能只有spu,sku两个概念,这是最底层的实体。

  • SPU(Standard Product Unit)是指标准化产品单元,是商品信息聚合的最小单位。比如iPhone6。
  • SKU(Stock Keeping Unit)是指库存量单位,即库存进出计量的基本单元。比如iPhone6国行白色16G。

1.3、对功能而言

至少有产品,标准化商品,下单商品3个概念。

  1. 下单商品。肯定是一个spu下的sku,对应着商品编码。
  2. 标准化产品。对应着spu,是几个sku的集合。
  3. 产品。显示在商城货架上,可能是一个spu,可能是不同spu的组合。

注意所谓的sku可能不是单个物理实体,比如美妆行业经常把2款化妆品用胶布绑在一起作为一个sku,存入仓库。

二、商品的存储

一般而言,B2自营商城选择租用第三方仓库并对接其系统,当规模很大的时候才会考虑自建仓库。

目前我们业务刚刚起步没多久,所以只有一个仓库,比较简单。

如果仓库有多个的时候,一般会根据“选择最近仓库-库存是否足够”的原则来处理配货发货,当然可能还涉及到合并包裹的问题。

三、商品的实体关系

以上讲了商品架构中需要涉及到的实体,而他们的属性和关系决定着数据库中商品表该如何设计。

可以参考这篇文章《如何用ER图绘制业务实体模型 》,了解关于实体关系模型的更多知识。

四、商品状态机

商品的上下架状态是用来区分商品是否展示给用户,以及是否可以成功下单。

赠品是一种特殊的spu,支持上架并支持用户购买,但是建议设为已下架并且是正确价格。

需要说明的是,售完下架和我下架的,是为了方便运营客服童鞋操作商城运营系统而设计的,采用了和淘宝卖家的商品状态机相似的做法。

可以参考这篇文章《如何绘画状态机来描述业务变化》来了解其原理。

五、商品的呈现

大部分电商的商品详情,呈现逻辑是相似的。

另外京东自营会根据收货地址和仓库的位置进行匹配、部分电商会在进入该页面的时候会选中sku并且自动跳过库存不足的。

我没有讲到类目、商品标签、商品关键属性、销售属性、其他属性,包括商品库存。

不是觉得不重要,而是我只讲了最基础最底层的设计,其他的都是根据业务在此基础上面演变而来。

六、总结

以上就是电商平台的常见订单状态,以及他们之间是如何变化的逻辑。希望通过拆分讲解的方式,让大家有个快速的入门。

提供源文件下载学习https://pan.baidu.com/s/1lOysRY59IOQN7Hhl7jrI3g

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/1631.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息