剁手双十一:聊聊电商中的预售环节
本文以电商预售功能为切入点,结合双十一情景下的电商平台的预售功能设计为切入点,希望能让你有所裨益。
今年的双十一,主流电商平台(淘宝、京东等)纷纷提早启动双十一活动,在10月份开启各种预售活动,通过预售提前锁定用户购买力。淘宝提供定金立减的分阶段付款预售,京东提供定金翻倍、定金抵现、尾款立减、件数阶梯等预售形式。
细心的用户可能已经发现,双十一的“预售”并不是我们传统意义上为了解决“库存积压”而提前预售的形式,现在的“预售”更多是一种促销活动,提前锁定用户,让用户感知提前下单可以享受优惠。
本篇文章从预售的行业现状分析开始,通过不同场景介绍预售的背景和目标。接着系统性的讲解预售的核心逻辑,并对核心逻辑从价格体系、库存逻辑、订单等核心模块分析。
主体目录:
一、预售行业现状分析
经过对各大电商平台和到家业务进行分析发现,淘宝/天猫、京东、苏宁易购、考拉海购提供预售活动的支持,盒马提供商品级别的预售(不是活动级别的预售)。
1. 京东
京东的预售活动形式比较多,包括定金翻倍、定金抵现、尾款立减、件数阶梯等形式。在入口方面,首页提供强曝光、预售活动专场活动页。
2. 淘宝
淘宝的预售活动(分阶段定金预售),同时提供首页强曝光、预售活动专场活动页。
- 淘宝预售活动提供针对SKU级别的商品配置,即SPU下可以挑选参与预售的SKU,如下图例子。
- 预售活动商品(SKU)在预售期间不能按照非预售商品售卖。不过商家可以通过新建商品的方式参加预售,同时将对应的商品作为非预售商品正常售卖。
3. 苏宁易购
提供多种形式的定金预售功能,包括定金翻倍、定金抵现、尾款立减等。
- 苏宁易购预售活动提供针对SKU级别的商品配置,即SPU下可以挑选参与预售的SKU,如下图例子。
- 苏宁易购通过首页给预售活动提供强曝光。
4. 考拉海购
提供分阶段付款的定金预售功能,但是考拉并没有对预售活动进行强曝光,入口比较隐蔽,需要通过搜索“预售”才能找到预售商品。
考拉相对京东和淘宝在预售活动上的产品功能支持力度明显较弱,商家为了突出预售商品的优惠力度,在商品头图上大做文章,将定金和优惠等信息强突出在头图上。
5. 盒马
提供的预售产品能力更像是商品级别的预售,和其他电商平台有一定区别。
- 盒马没有专门为预售提供强曝光入口,仅可以通过搜索或者分类查询到预售商品。
- 盒马提供的预售更偏商品级别,也就是针对商品进行配置预售信息,比如发货时间。
- 盒马的预售不存在分阶段付款,直接付全款。
- 盒马的预售可以和非预售商品合并结算,拆包裹选择不同的履约时间,根据包括拆分为不同的订单。
6. 拼多多
没有查到预售相关信息。
按照拼多多官方说法,“预售”套路太多,对用户来说太烧脑。拼多多砸钱让用户直接享用优惠补贴,所以并不需要“预售”。
二、名词定义
前面通过预售的行业整体情况进行介绍,大家对于预售应该有一定认识。在深入分析之前,我们有必要回到起点,先明确“预售”的定义,到底什么叫做预售。
首先来看百科词条“预售”:
预售,英文是Presale,是指在产品还没正式进入市场前进行的销售行为。
从字面理解,预售的商品还未上市就提前销售,也就是还没有现货就提前让用户预订,用户提前付款获取的是商品的发货承诺。
结合主流电商平台开展的“预售活动”延伸理解,电商平台搞的“预售”和传统意义的预售已经不一样:
电商平台做的“预售活动”商品并不是没有上市,在常规时间已经在正常售卖,只是没有以“预售”的形式出现。
另外,“预售活动”的商品范围及其广泛,基本上电商平台上核心品类都有涉及(从品类覆盖反推就可以发现,不太可能出现大批量品类商品未上市就开始售卖)。
我们现在看到的电商平台“预售活动”从本质上看就是一次促销活动,通过预交定金优惠力度更大的说法提前锁定用户,避免用户被其他购买渠道拉走。
基于上述分析,我们可以试着将“预售”的定义再次延伸,电商平台做的“预售活动”也是一种“预售”,是将有一定优惠力度的商品提前让用户用定金的形式进行交易,也就是说用户通过定金提前锁定活动商品。
三、预售场景和目标
结合“预售”定义,我们来了解下预售的典型场景:
(1)不适合积压库存的商品:
- ① 单价高,提前囤货需要的资金量较大,比如高端化妆品;
- ② 易损坏商品,提前囤货可能带来较大货损率,比如生鲜;
- ③ 仓储和物流复杂,比如家具。
(2)新品上市(比如新书、手机等电子设备),通过预售起到预热作用。(当然通过预约抢购也是一种常见的新品的营销玩法)
四、预售主要形态
按照预售的付款阶段可以划分为两大类型:全款预售和定金预售。
- 前面介绍的盒马目前提供的预售功能就是全款预售,不提供分阶段付款。
- 主流电商平台提供的预售能力都是定金预售。
定金预售按照促销规则衍生出多种形式,目前常见的是:定金翻倍、定金抵现、尾款立减、件数阶梯等。
五、预售主体流程
1. 预售主体流程
可以提炼为如下5个关键步骤,其中第一步更多是商家自身内部行为,和预售工具关联度不大。
定金预售和全款预售在付款阶段上有较大区别,所以拆分进行说明。
2. 定金预售关键流程
3. 全款预售关键流程
六、预售核心逻辑
预售功能和普通商品交易类似,会涉及如下4个核心模块:商品、促销活动、订单(交易)、配送。
1. 商品
在商品模块,涉及预售选品的层级粒度(按照SPU配置,还是按照SKU配置),目前主流电商平台都支持SKU层级的配置,即商家可以按照SKU进行挑选进行预售的商品。
预售商品一般不支持预售和非预售同时售卖,即如果某一个SKU在预售中,则该SKU不能按照普通商品售卖,在平台内并不会有进入该SKU按照普通售卖的入口。(但是有些商家是有同时售卖的诉求的,一般他们可以选择复制SKU来参与预售)
商品部分最为关键的是价格和库存,后面会展开说明。
2. 促销活动
如果预售作为一种促销活动,则按照促销工具通用配置进行抽象可以归类为4大类:活动基本信息配置、活动选品范围配置、活动的促销规则配置、活动的适用范围。
3. 订单/交易
预售活动商品一般不能加购,需要直接购买;同时预售订单可能涉及父子订单的处理;预售商品在预售期一般不支持售后。后面再展开说明。
4. 配送
主要是配送时间的配置。
七、预售商品体系
商品体系需要重点说明参与预售的SPU和SKU的关系,以及库存和价格关系。(库存和价格单独说明)
1. 主流电商平台的预售活动选品都可以支持到SKU粒度的配置,即商家可以挑选SPU中的一个或者多个SKU参与预售,该SPU下其他商品正常售卖。
如下图所示,淘宝和苏宁易购都支持预售商品和非预售商品的混合展示,用户可以切换规格,如果是预售商品,则需要走定金预售;如果是非预售商品,则可以加购或者直接购买。
八、预售价格体系
定金预售和全款预售在价格体系上有所区分。
1. 定金预售
价格/金额涉及商品原价、活动价、定金、优惠金额、尾款。
前面介绍的定金预售形式有多种(如下图),关键点在于定金和尾款的设计。市面上的多种定金预售形式,虽然形态上看着有差别,但是本质上还是会落在尾款的优惠力度上。
2. 全款预售
全款预售相对定金预售会简单很多,和秒杀的价格体系很类似,包括商品原价、活动价,用户直接按照活动价全款付款即可完成预售交易。
九、预售库存逻辑
定金预售和全款预售在活动库存冻结和扣减上有一定区别,其他逻辑基本一致。定金预售的库存逻辑在实现上有两种形态:
- 一种是活动库存不用预占真实库存,也就是预售期间,预售商品可能并没有真实库存(预售商品常见场景),也有可能已有真实库存;
- 另外一种是活动库存预占真实库存,在配置预售活动时需要冻结真实库存,确保预售活动的库存是有保障的。
1. 定金预售:不预占真实库存
如下图,通过示例大致演示进销存的逻辑。重点还是在于不同的节点上需要关注不同的库存数据。
2. 定金预售:预占真实库存
3. 全款预售
十、预售订单/售后逻辑
1. 预售加购的处理
主流电商平台提供的预售活动商品不能加购,需要直接购买;盒马提供的商品级预售可以加购,和其他商品同时下单做合并结算拆包裹拆订单。
2. 预售订单
(1)定金预售
引入预售功能,订单就需要新增一种订单类型(预售订单)。由于需要分阶段付款,所以一般需要生成父子订单,父订单用于跟踪预售商品的标准状态,子订单(定金订单和尾款订单)用于跟踪预售商品定金和尾款的支付状态,尾款需要根据预售类型在预售结束后计算用户需要支付的尾款金额。
尾款金额的计算逻辑可以参照上述预售商品价格体系的说明。
预售订单在落单时,需要明确配送时间,然后根据配送时效抛单履约。
(1)全款预售
和常规订单类似,订单状态并不会发生改变,只是在履约时间和抛单时间上的处理需要根据业务做调整。
3. 售后
预售商品在预售期一般不支持退款,预售期结束,商户发货后,可以按照业务情况处理是否走售后流程。
十一、预售数据指标体系
前面都是从业务逻辑和产品功能对预售进行说明,还有十分重要的一个环节就是产品功能的数据指标体系,只要配备完整的数据指标体系,才能有效判断产品功能的完备性,业务在落地产品功能上是否顺畅,是否符合活动预期。
如下表格从交易维度、流量维度、商品维度简单罗列了一些常见的数据指标,在业务前期,关注的更多是交易额、订单量、客单价、流量到交易的转化漏斗。精细化运营需要的指标维度会更细,可以根据业务目标进行拆解。
总结
预售功能看似简单,但是“麻雀虽小,五脏六腑俱全”,这个功能可以将电商整体流程进行串联。
随着电商业务的不断变化,“预售”可能会衍生出更多的玩法,到时此文分析的预售形式可能不再是主流。但是通过对整体逻辑的分析,可以帮助大家更好理解新的形态。
说到底,我们还是要回归底层逻辑,看清底层逻辑,不管业态如何变化,只需要顺藤摸瓜即可。
本文由 @七月专栏 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于 CC0 协议
预售这块 是不是要绑定到商品层面上啊。就一个商品对应一个预售才对,预售这种活动 不大适合 选一个范围的商品。因为需要设计到定金之类的信息,而这一类信息 应该是与sku关联的
预售这块分析的可以,订单这块简直胡说八道,子单的拆单逻辑就不会去按预售去拆单,然后付款和和尾款逻辑按正常逻辑,付款的时候可能还没生成订单,怎么会有子单,怎么可能由子单控制;尾款支付时订单生成后了,这个时候走订单履约逻辑,也不可能由子单控制
制者不了解订单就说不了解,别误导人
想请教一下预售订单部分。
文章里面提到需要新增一种订单类型(预售订单),生成父子订单,父订单用于跟踪预售商品的标准状态,子订单(定金订单和尾款订单)用于跟踪预售商品定金和尾款的支付状态。
想求教一下,这样会不会对正常订单系统改动过大?核心订单系统多增加一套订单,后续维护成本比较高?
如果是新增加一种单据负责预付尾款业务,尾款支付成功的时候再生成正常的普通订单呢?
再简单点,预售和尾款订单做成2个独立订单
学习了,方便交个朋友吗?
😳 随时讨论交流。
加载页ue极差
写的很清晰,学习了