优惠券平台有哪些(优惠券系统细节剖析(一):关于优惠券分类及对应设计思路)

本系列文章将列举一些新人经常忽略的细节,并尝试对细节进行深入分析。今天主要想说说优惠券的分类以及相应的设计思路。



优惠券平台

为什么要写这个系列?

我是一个3年的产品经理,自从调到产品岗后就很少写文章了,所以我发现我的文笔一天比一天差。进入30岁队列后,我开始思考后续的职业规划和发展,于是决定重拾写作风格。

之所以选择“优惠券”作为自己的创业,只是因为最近在设计电商优惠券系统,但是两年前刚调到产品岗的时候,就被分配了整理优惠券需求的任务。后来领导因为“优惠券也是钱,这个钱谁来承担”之类的问题搁置了这个需求。

现在因为业务需要,重新整理了一下需求,对优惠券有了一些新的想法和看法。虽然平台里已经有很多大神通过经验分享了优惠券系统的相关需求,但其实当我真正投入到整理和思考的时候,会发现还有很多细节和坑等着你去掉。

时隔两年,我回头看自己产品小白的需求文档,发现自己真的掉进了几个坑。相信很多新产品也会遇到这样的问题。所以我这次会分享一些优惠券系统的知识,最能帮助到别人。如果实在不行,我就把它作为我的写作练习素材。如有错误或不同意见,也欢迎在评论区讨论。

关于一些很少被提及却容易被忽略的细节。

平台里关于优惠券制度的文章,大部分都是从整体层面讲大流程,也有针对某一部分介绍的,真正起到指导作用。但是在实际需求排序的过程中,很难找到一些必须解决的细节的相关信息。

所以,我就不重复优惠券的整体介绍了。可以自己搜索浏览。这一系列文章将列出并抛出一些新人经常忽略的细节,并试图深入分析这些细节。今天主要想说说优惠券的分类和相应的设计思路。

优惠券业务场景分类汇总

关于优惠券的种类,我们经常可以听到万能券、品类券、品牌券、活动券、单券券、现金券、满减券,在不同的分类纬度可以分为几类。但是各种品类组合后,刚接触优惠券系统的新人会比较迷茫。如果不充分考虑优惠券系统的设计和规划,未来如果需要增加优惠券类型,可能会导致重复开发和资源浪费。

因此,了解优惠券类型的逻辑差异,找出当前商业形态下需要优先开发什么样的优惠券,为后续的产品设计留有余地,会让后续的迭代过程更加顺畅。

目前常见的分类维度如下:

1。收集阈值

领取门槛主要是指用户在浏览优惠券领取入口时,能否作为当前用户成功领取优惠券。共有四种常见阈值:

  • 普通优惠券:最常见的形式,只要是个人都可以用(特殊情况除外,比如电商平台常见黑名单号,不一定可以用);
  • 新人券:只有新注册的用户才能获得;
  • 首券:只有未在商城下单成功并生成订单记录的用户才能领取;
  • 指定用户券:不同的电商产品体系通常会有不同的设计,比如JD.COM的vip用户券,店主专属券,都是这种类型。
  • 2。收集方法

    领取方式主要是指优惠券如何成功到达用户的优惠券账户,成为用户持有的“可用优惠券”。

    有两种常见的收集方式:

  • 手动采集:用户手动点击特定界面进行采集;
  • 被动收款:系统会自动向用户账户发放优惠券,通常会与推送、短信通知等运营手段一起实现。
  • 3.可用商品的范围

    可用商品范围主要是指用户收到的优惠券可以用于哪些商品。通常规定商品种类只用于实物商品,否则会有一定风险造成之前的拼多多优惠券羊毛事件(优惠券可以用于虚拟充值商品),然后规定适用的商品目录。

    共有4种常见商品可供选择:

  • 单品券:只能用于指定的单品;
  • 指定产品优惠券:可用于多个指定产品;
  • 类别券:可用于指定一级类别或二级类别下的若干商品,部分特殊商品除外;
  • 全券:可用于平台内所有商品,部分特价商品除外。
  • 4.使用阈值

    首先,要区分接收阈值和使用阈值。前者是“怎样才能得到”,后者是“得到后怎样才能使用”。使用阈值是指在用户可以使用可用产品范围内的产品之前需要满足的特定条件。

    有两种常用阈值:

  • 满券减额:订单中符合使用范围的商品需要多少元才能减券对应面额的金额;
  • 减券:也可以叫现金券或无门槛券,即只要商品在使用范围内就可以直接使用。
  • 5.有效期

    有效期是指优惠券在时间维度上的使用限制,即优惠券领取后在什么时间条件下可以使用。

    有两种常见的有效期:

  • 普通优惠券:通常情况下,优惠券会从一个时间节点使用到另一个时间节点,指定的优惠券只能在时间范围内使用;
  • 限时券:规定领取后一定时间内可以使用,如“领取后7天内可用”。
  • 几种不同优惠券类型的设计思路

    1.看似很多种场景,底层逻辑却是“4W1H”

    以上分类总结只列出了常见的优惠券场景。事实上,不同的平台在具体的业务场景下,在上述五个维度上有各自的延伸。但从系统逻辑来看,大部分优惠券业务场景的底层逻辑都逃不过“4W1H”。

    如下图所示,所有优惠券其实都是五维度的顺序组合。



    从收款阈值的角度来看:这个维度中的设置比较灵活,只需要在用户触发“收款”动作时判断是否应该按条件付费即可。比如新人券,通常会根据“新人”的定义做出相应的制度设计。比如“24小时内注册”规定“用户的收款时间减去用户的注册时间小于等于24小时,才可以成功收款”。对于第一张优惠券,是在采集时判断用户的订单数据是否为0,0可以采集,否则不能采集。

    从采集方式来看:主要可以根据运营场景的需要来设计。需要注意的是,被动收款通常会由用户在完成某个平台规定的特定条件或流程后获得,如注册、成功支付下单、参与抽奖游戏等。

    从产品范围来看:单品、指定品、品类、整品优惠券都是平台中所有产品在创建优惠券时需要定义的子集,该子集中的产品都可以使用优惠券。最后,剩下的问题只是这个子集有多大。



    从使用门槛来看,满券和减券的使用条件是,可用券的商品总价至少要X元才能减Y元。只有在减券的使用场景下,当X等于0时,减券的使用门槛为“无门槛”。

    从有效期的角度来看,限时券和普通券都需要在创建券时指定券的可用时间范围从A时刻到B时刻,唯一不同的是普通券的A时刻和B时刻都是指定的时间节点。而限时券的时间点A是未知的时间节点“领券时间”,时间点B是“领券时间+券可用时长”。

    2.任何一种优惠券都是以上五个维度的排列组合。

    以最常见的电商常规优惠券场景为例,比如大家熟知的JD.COM“全品类优惠券105减5”就是以下五个维度不同方案设置的结果。



    再比如Luckin coffee的新人优惠券,可用于大师咖啡/零拿铁,7天内有效。是以下的方案设置。



    所以,当优惠券的五个维度理解清楚后,市面上95%的优惠券都可以应用到scheme模型中。

    3.优惠券背景设计理念

    面对业务部门随时提出的各种优惠券场景需求,如果产品经理能够在规划优惠券系统的初期,就将上述五个维度划分为五个子模块功能进行设计,甚至前瞻性地告诉技术人员预留接口类型,相信可以大大节省后续的迭代开发资源。

    比如后续商家提出了“新券”的需求。这时候我们只需要在“接收门槛”子模块中进行扩展设计,增加“只有新人才能接收”的产品需求,同时最大程度避免干扰其他四个子模块的影响。关于这一块的内容,为下一篇做准备,再结合优惠券系统需求文档的分享单独展开。

    结束语

    第一次在原大纲列出后,才知道写出来会是个大坑。目前写了这么多篇幅只是为了说明设计思路,所以决定调整成几篇文章来写。后面我会介绍以上五个子模块的功能设计。况且优惠券涉及的售后流程和结算流程都不是小坑,有机会我会拿出来详谈。

    如有表述不清或有错误观点,请及时指出,我也会研究并尽快做出调整和修改,以免误导他人。感谢您的耐心等待。

    本文由@梁原创发布,人人都是产品经理。未经许可,禁止转载。

    图片来自Unsplash,基于CC0协议。

    您可以还会对下面的文章感兴趣

    使用微信扫描二维码后

    点击右上角发送给好友