在电商和O2O领域，促销是运营人员的一个主要的让利行为，同时促销活动期间的购买量也较之普通商品更高。所以促销系统的稳定和功能的多样化对于业务方的同学来说就是至关重要，不同的阶段，对于促销的要求也是不同的。今天我们就来解读下促销系统的“进化”之路。

促销系统的“本体”

从百度百科上可以搜索到，促销的定义是这样的。

促销实质上是一种沟通活动，即营销者（信息提供者或发送者）发出作为刺激消费的各种信息，把信息传递到一个或更多的目标对象（即信息接受者，如听众、观众、读者、消费者或用户等），以影响其态度和行为。

根据定义我们利用5W2H的方法拆解，促销的元素主要有几个部分：

• 商品信息（What）
• 促销规则（How,Why）
• 定向用户（Who）
• 发放渠道（Where）
• 活动计划（When）
• 投入成本（How Much）

这里面和促销系统紧密相关的主要是商品信息、促销规则和定向用户，发放渠道、活动计划、投入成本因为涉及到较多系统和角色的参与，这里不做展开说明,下文说的主要是商品信息、促销规则和定向用户。

促销系统核心功能

根据上述分析，促销系统的核心诉求主要是解决将商品按照一定的方式和玩法售卖并告知用户，刺激用户加大消费力度的管理系统。将模块拆分，主要分为三部分：

• 促销活动：活动投放的设置管理，负责提供活动方式和商品内容
• 促销规则：促销规则的设置管理，负责提供促销玩法
• 优惠券：负责优惠券管理，提供一种相对独立的促销形式

从大的维度来看，优惠券也属于促销的一种方式，在促销规则也和优惠劵的使用有一定关联。这里我们把优惠券也归类到促销系统中。在实际功能设计时优惠券也可以独立于促销系统之外单独处理。

促销活动

促销活动的基本属性管理，主要功能包括

• 商品选择：参加促销的商品，分为活动商品和赠品两种。
• 促销类型：何种促销方式
• 规则选择：具体促销规则的参数
• 投放时间选择
• 投放区域选择（020必选项）
• 打标签：商品数据打促销标识，前端显示促销标签

促销规则

促销规则是促销系统核心中的核心，也就是俗称的VIP中P。一个促销系统的好坏取决于促销规则设计的是否合理，促销规则间接也依赖于其他相关系统的制约。

促销规则有几个维度的划分：平台、商品种数、促销方式

从平台分为：“自营促销”和“POP平台促销”

从促销类型分为：“单品促销”、“集合促销”和“店铺级促销”

• 单品促销：以单个商品为维度进行的促销叫单品促销，例：限时抢。
• 集合促销：通过商品集合来满足促销规则进行的促销叫集合促销，例：满额减。
• 店铺级促销：以商家店铺为维度进行的促销叫店铺级促销，例：店铺级满额折。

从促销方式分为：

• 直减类：限时抢、直减、多买多折、VIP专享价、手机专享价等
• 送赠品类：满赠
• 换购类：加价购，凑单
• 满额类：满额减、满额折等
• 返券类：满额返券
• 组合优惠类：套餐
• 预订类：团购

这里优惠券考虑形式和其他促销规则有共同的地方就不单独列出来了。另外，在规则制定时要考虑购买时活动间的共享与互斥。原则上所有的商品同一时间不可以参加两项活动，按照一定的优先级完成用户的优惠享用（例如单品>组合>品类>整单（或店铺），满减优先级大于代金券，优惠金额多的规则优先等）。但有两种情况可以例外：

1. 价格类直减和满额累促销可以共享，可以使用优惠后的价格来计算满足金额。
2. 优惠券和部分促销类型可以共享。具体的情况要看业务实际过程中毛利的情况和考虑来决定。

优惠券

优惠券是以劵的方式实行促销优惠。优惠券管理需要设置生效时间，使用次数，发放方式优惠券优惠形式

优惠券的也有几个维度的划分：品类、平台、促销类型

• 品类：按照类目品类区分
• 平台：分为自营和店铺、全场
• 促销类型：满减、直减

关于优惠券提几个需要注意的事项：

1. 优惠劵的“使用”定义，一般情况会在生成订单后去绑定优惠券使用。在退单时退回优惠券

2.优惠券回退情况分为部分退和整单退。部分退时只退回分摊在商品上的金额，当不满足优惠券使用门槛时考虑到用户体验一般不会重新计算订单金额还是允许用户继续使用。

3.分摊金额除不尽时一般会有一个商品比其他的多分摊少量金额，取小数两位即可。四舍五入还是直接舍去需要同后端报表等金额规则一致。

促销的关系图谱

促销系统作为电商、O2O的核心系统，和各个系统之间关联甚密。这里我们列举了一些主要和促销有关系的模块和系统体系。在有些公司可能部分模块不属于同一体系下，这里为了方便归类认知我放在了一起（比如订单结算）。

可以看到订单、商品是和促销关联最紧密的，用户端则通过API获取到促销的信息。几乎前端大多数主流程页面都需要和促销系统做联动。

接下来，我们就模拟下一个公司发展逐步完善促销功能的“进化”过程。

促销进化之路

初次尝试

电商或020搭建之初能够支持的促销形式比较单一，一般会选择直减类型的限量购，比如特价商品。这时促销系统需要支持：

1.商品

• 促销商品的选择
• 促销价格的设置

2.库存

• 是否锁定促销库存还是和普通价格的商品共享库存（促销系统、库存系统/商品系统）
• 库存管理是在库存系统还是在商品系统

3.活动

• 促销活动的投放设置
• 适用群体设置：新用户、老用户，初期可不做限制
• 促销规则关联
• 促销展现形式的处理

4.促销规则

• 支持商品直减促销价
• 支持限量购，超出部分恢复原价

上述功能实现了初步促销系统的雏形，在实际实现过程中考虑到一些客观因素会有一些折中的情况。

• 活动设置时只支持全场概念，初期可不区分过多区域。O2O可以考虑只支持单店模式，不支持全场模式。
• 商品系统如果不完善，可以考虑部分信息放在促销系统设置（比如价格）。管理多个商品的时候初期可以考虑用excel上传的方式解决。
• 业务上考虑避免SKU毛利过低，直减促销形式搭配限量购组合（如特价商品限售一份），规则设计时要考虑是否将两种规则融合成一种规则，避免后期扩展时交叉逻辑特别多。
• 适用用户前期可只区分新老用户两种，如果工期较紧可以不做区分，后期补足。
• 促销规则方面电商系统一般会将每种促销功能单独定制，O2O逻辑相对简单也可以考虑做一个通用的规则库来选择。

局部升级

初步尝鲜后业务同学尝到了甜头，希望进一步扩大可以操作的促销玩法提高订单的SKU数。满额类促销的需求随之到来。相对于之前做的直减和限量购属于单品级促销来说，满减属于集合促销，逻辑上更为复杂。为了满足本次的需求，功能上需要升级2.0版本：

1.活动

• 活动上增加规则优先级制定：共享、互斥的逻辑
• 考虑毛利和业务场景等因素，集合促销需要关注可选商品的适用范围：品类、平台等

2.促销规则

• 增加满减规则

3.订单

• 集合级促销订单优惠金额需要分摊到品
• 退单时考虑按品分摊金额进行退款。

4.用户端

• 在购物车、结算页增加集合促销享受提示，独立于商品之外。

优惠券的出现

平台进入了高速发展的时期，为了能够进一步提高拉新的效果。业务这次提出了优惠券（也叫红包）的诉求。同时配合优惠券的站内推广和提高复购率的考量，增加满返促销的形式。

1.优惠券

• 增加优惠券:满减劵、直减劵
• 添加生成规则：门槛、区域、优惠券金额，适用品类、平台
• 添加发放规则：放发渠道（直投用户账户、兑换码、微信红包）、领取规则

2.促销规则

• 增加满返促销规则，返优惠券

3.订单

• 增加优惠券金额分摊
• 退单时退还优惠券使用

4.用户端

• 支持分享功能，提供微信红包分享

5.商家

• 考虑平台券和自营劵的区分
• 支持店铺设置发券

由于优惠券的引入和商家概念的增加，促销系统变的复杂起来。在这个过程中需要关注几个点：

• 优惠券的范围要考虑全场券和商家、自营劵的互斥使用，优惠券和部分促销活动的互斥使用（比如满减和优惠券的满减等）
• 优惠券的退单时部分退和整单退优惠券金额如何处理的问题。原则上部分退后即使不满足门槛也不会取消未退商品的满减金额。
• 红包的发放要考虑领取数量限制，门槛的设置也要考虑到风控的因素，避免出现减完金额变成0这种情况的出现。

从让利到赠送

过了一段“平静”的时间，业务同学又有了新的想法：满赠需求。不过现在的促销系统结构上已经比较完善，哪里没有加哪里，so easy。

1. 促销规则：增加满赠促销方式
2. 商品：增加赠品属性，促销活动可以选择赠品类型商品
3. 库存：增加赠品库存管理
4. 订单：退单时退还赠品
5. 用户端：显示赠品提示

需要注意当赠品赠完时，满赠活动应该线下，此时享受满赠的商品是否还继续售卖。

路漫漫兮长久远

促销系统在我们的合理搭建下“茁壮成长”，合理的结构决定了未来的扩张也是相对容易便捷。随着业务的蓬勃发展，促销的形式会越来越多。而后续的调整主要在几个方面：

• 促销规则：不断完善促销规则，考虑好规则间关系和优先级。
• 订单：涉及金额调整的促销模式需要考虑金额的分摊和退还。
• 用户端：通过合理的标识展示给用户。

当然完整的电商、020体系还会涉及很多很多系统，财务、CRM等等，这里就不一一累述了。

结语

促销的本质是刺激用户消费，促销系统的目标是通过各种用户可理解的方式实现提高用户购买意愿的功能。上文仅仅只是简述了促销的冰山一角，作为初入此门的同学可以作为入门知识了解熟悉。

相关阅读

解构电商、O2O：订单系统，平台的“生命中轴线”

解构电商、020：查阅商品的“档案柜”

解构电商、020：探秘搜索系统的“简历”

解构电商、020用户端“背后”的逻辑

解构用户消费心理：卓越的服务体验始于「心」

作者：高晖，微信号公众号@产品老高，10余年IT经验，互联网老兵。

本文由 @高晖 原创发布于人人都是产品经理。未经许可，禁止转载。