产品设计:优惠券系统

19 评论 33343 浏览 520 收藏 13 分钟

编辑导语:优惠券的本质是以让利的方式,吸引更多用户去购买商品,是非常重要的一个促销手段。本文作者结合自己的业务经历,整理出了优惠券系统的搭建过程,希望能给你带来帮助。

最近刚完成平台的优惠券系统,产品设计过程中也看了很多竞品和文章,现在结合自己的业务经历,把优惠券系统搭建的过程通过文字整理出来,也方便自己复盘整个过程。

优惠券的本质是商家以让利的方式降低消费门槛,吸引更多用户去购买商品,提高订单量、客单价,同时满足拉新、促活,提升复购率等用途。

我司是一个IT教育电商平台,作为一个To C的业务,优惠券是非常重要的促销手段,为了满足业务需要,我负责搭建了优惠券系统。

一、优惠券流程

优惠券系统的流程比较简单:首先运营在后台创建优惠券模板,在实际使用场景中选择以哪种方式进行投放,如果需要跟营销活动相关联(一般是H5活动页形式展示),则需要创建一个活动,将优惠券与该活动关联;否则直接通过模板配置的方式发放优惠券,如运营手动发放,系统自动发放等。

接着用户领取优惠券,根据优惠规则下单支付,这里涉及到前台页面显示(商品详情页、购物车等)、后台多种优惠方式互斥计算。

最后是数据统计,方便运营人员对优惠券的投放状态、使用情况做统计。

业务流程图

所以,优惠券系统可以划分为四个功能模块:创建优惠券、优惠券发放、优惠券使用、数据记录和统计。

优惠券系统功能结构图

二、创建优惠券

创建优惠券是优惠券系统的第一步,是业务的基础,产品设计时要尽可能考虑到多种业务场景,避免上一个版本运营就提一些新需求。创建优惠券主要有以下几部分组成:基本信息、优惠类型、适用范围、发放规则。

1. 基本信息

基本信息包含优惠券名称、生成数量、每人限领数量、与其他优惠是否能叠加使用、发放时间、使用有效期。

使用有效期可以分为两类:

  1. 固定天数:设定一个固定数,比如:30天,表示从领取之日起30天内有效
  2. 固定时间段:设置开始和到期时间,该时间段内优惠券有效

2. 优惠券类型

优惠券类型要根据公司实际情况去设计,主要立减券、满减券、折扣券。

  • 立减券:即无门槛使用,直接设置优惠券面额即可,需要注意的是,优惠券面额要大于商品金额才能使用,具体规则跟分销有关,比如要大于商品1元才能使用。主要针对有购买意向,但嫌没有优惠的用户拉首单使用的。
  • 满减劵:需设置使用门槛,优惠券面额和使用门槛的规则也是可以思考的,如我负责的业务,商品使用优惠券后是平台和讲师共同承担成本,那就需要运营设计好成本,比如使用门槛要大于等于优惠券面额的三倍。主要在活动促销中发放,让那些原本可以接受高价的用户继续高价购买。
  • 折扣券:使用后商品可打折,需要考虑已有折扣优先级,是否叠加使用。

3. 适用范围

适用优惠券的商品类型、用户类型,两者可满足不同运营指标。

  • 以商品维度:可以分为全场通用、店铺通用、指定分类、指定商品。平台和商家各自创建优惠券,方便大小型营销活动使用。
  • 以用户维度:可通过用户标签来制定,常见的如注册用户、会员用户、复购用户,便于运营灵活操作。

4. 发放规则

优惠券发放形式主要为系统发放和主动发放,具体的在下面介绍,在创建优惠券时可以设置,如发放形式、发放条件、是否开放领取。

由以上介绍可以创建出一个最简单的优惠券,具体的字段根据实际业务场景设计,原型实例:

原型示例

三、优惠券发放

在设计发放规则时,产品要熟悉优惠券的特性和用途,了解业务场景,才能梳理好路径和规则,发放形式一般分为系统发放主动领取:

1)系统发放

可以通过发放场景来划分。

  • 系统:制定相应的规则,用户触发规则后,系统自动发放券。如用户注册后发券、消费后发券,这可以代码写死,或者在创建券时新增一个字段做设置。还如优惠券和活动关联,用户完成某项任务时,系统自动发放。
  • 人工:当有奖励或者赔偿用户时,可由运营人员手动发放,发放时可设置单个发放或批量发放。

2)主动领取

一般是在店铺主页、商品详情页、促销活动页中展示,用户需要领取才能到账,形式可以是在详情页无成本领取,也可以是将优惠券与活动相关联,如抽奖活动、签到活动等,利用大额优惠券吸引用户活跃,通过任务和优惠券促进用户转化,并且这类优惠券的感知和触达率会更高。

需要考虑的是,系统发放的优惠券,要通过不同形式的消息提醒来告诉用户——“你做什么可以获得优惠券”“你已经有优惠券了,快去使用吧”,提醒手段有两种:

  1. 主动触达:比如推push(站内信、app消息通知)、发短信、公众号推送。推push需要用户必须进入网站或者app,push打开率也并不高,发短信触达率是高,但是打开率不高,同时发短信也要成本啊,还有可能被拉黑和投诉,公众号则是需要获客成本,总的来说各有各的优缺点,大型活动时是全走一遍。
  2. 被动触达:同push一样,需要用户进入网站或app,比如每天首次进入app有弹窗提示、触发规则后在原有页面中加相应提醒。这种方式的优点在于触达率高,在用户在有需要的时候就能发现送券了,有利于转化。

四、优惠券使用

优惠券使用涉及到前后台,前台主要是下单流程的展示、后台主要是订单系统。

1. 前台

1)商品详情页、购物车

如果商品有可使用的优惠券,可以显示优惠券张数,用券后的价格(一般显示最低金额),前置了优惠,让用户从进入详情页就知道自己有优惠可用。

2)结算页

系统默认使用面额最大的优惠券,若金额相同,则先使用先过期的。需要列出用户拥有的所有优惠券,用户可自由选择可适用的券,不能用的券置灰不可选,靠后展示。

2. 后台

1)价格计算

使用之前,需要根据优惠券创建时的规则来判断,商品是否能使用?是否能与其他优惠叠加使用?由此来算出商品的最终价格,这是使用中最复杂的阶段,尤其是平台本身有很多优惠形式时,各种优惠的优先级,是否互斥,具体规则要穷尽出来。

像我负责的业务,优惠形式有折扣、满减、积分抵扣,折扣形式有七八个,折扣之间可叠加或不叠加,优惠券的优先级,能跟哪些叠加和互斥,计算起来都是比较复杂的。涉及到钱的地方,都需要认真再认真啊!

2)分摊

这里的分摊有两种,一个是多个商品同时使用优惠券时,优惠券抵扣的金额要根据商品价格比例平摊;另一个是结合业务,优惠券的成本由谁来承担,是平台还是商家,还是共同承担,如果是共同承担,各自的比例是多少。

3)退还

用户下单时使用优惠券,下单后未付款超时、未支付取消,支持退还优惠券。而已付款退货涉及到价格计算和分摊,较为复杂,一般是不支持退还的。

五、数据记录和统计

数据主要是为了观察优惠券的发放、领取、使用情况,便于后期根据数据情况复盘运营动作,一般有以下几个统计维度:

  • 发放率:该批次已发放优惠券数量/该批次优惠券总数量*100%
  • 使用率:已使用优惠券数量/已发放优惠券数量*100%
  • 用券订单量:使用该批优惠券的订单数量
  • 用券总金额:使用该批次优惠券的订单总金额

已领取、已使用的优惠券还要记录领取用户的相关字段,如uid、手机号、订单号、下单时间、购买商品id、订单金额等,原型实例:

原型示例

六、总结

优惠券系统的功能点不算复杂,难点在于要结合业务考虑的尽可能全面,完整考虑好创建-投放-使用-统计

的闭环。因为优惠券会用于非常多的业务场景,所以需要在后台优惠券系统搭建时,将其与业务解耦,否则会导致后期拓展性不强。

基础要打好,产品是迭代出来的,在夯实的基础上再去优化才能让产品跟满足业务需要。我自己在做的时候就有些特殊的需求,如优惠券类型可以定制化(可购买)、优惠券创建后自动生成一个领取链接等,规划时要有舍有得,像优惠券这个大系统的需求,可以分多期来做。
本文由 @阿常常 原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 24年看到也不算晚,好,感谢!

    来自北京 回复
  2. 您好,请问下,优惠券在设计的时候需要考虑和微信、支付宝的打通吗?不用考虑对接吗?

    来自浙江 回复
    1. 不用的吧,微信支付宝只是提供支付接口,你把最终要支付的金额传过去就行了

      来自浙江 回复
  3. 请问关联活动是怎么关联的呢?不太理解活动与优惠券之前的串联关系

    来自广东 回复
    1. 通过活动ID和优惠券ID关联吧,先创建一个活动,然后创建优惠券。其实细节挺多的这里,这部分确实没讲太明白,这里大部分逻辑还是在后端。

      来自浙江 回复
  4. 不谋而合哈,感谢楼主总结出来!
    请教下,最近正好在研究优惠券功能的业务贡献,想知道能证明产品做这个优惠券功能是有价值的,应该考核哪些业务指标,使用率、用券订单量、用券总金额,也不足以证明,就很困惑

    来自北京 回复
  5. 催更,哈哈哈

    来自广东 回复
  6. 优惠券类型可以定制化是怎么做的呢?

    来自福建 回复
    1. 根据业务来定的 比如我们运营需要优惠券作为一个商品让用户购买 并且额度自己可定 与通用的优惠券有区别

      来自上海 回复
  7. 为什么发放规则不放在发放模块呢
    优惠券创建只创建基本信息,发放模块关联优惠券(多张),指定发放条件这样设计呢?

    来自上海 回复
    1. 我的理解看是否有必要解耦吧 当前发放规则只有几个字段 单独筛出来操作还更复杂了 你想做发放模块 是为了满足关联多张优惠券吗?

      来自上海 回复
    2. 我理解是不是基本信息可以作为模板存在,不用每次都重复创建优惠券

      来自北京 回复
    3. 赞同👍

      来自上海 回复
  8. 在上海么?请问

    来自上海 回复
    1. 目前在上海

      来自江苏 回复
  9. 精彩的分享,谢谢

    来自广东 回复
    1. (*^▽^*)

      来自湖北 回复
  10. 谢谢阿常常分享的前车之鉴,最近正好在设计优惠券系统到处找可参考的地方。

    来自上海 回复
    1. 哈哈 我也是这么过来的 所以也想分享出来~

      来自湖北 回复