优惠券系统细节剖析（二）：优惠券后台创建流程设计

当我们搞清楚优惠券分类那些事之后，系统后台的优惠券创建流程应该怎么设计，来保证后续面对奇形怪状的业务需求时如何让产品迭代更加有效率。enjoy~

前言

优惠券在平台中是一个神奇的东西，一个东西本来卖100元，运营人员鸡贼地在后台把价格改为120元，然后再发一张20元优惠券出来。从理论上以及现实上来看，此时假设同一个用户面临以上两种情况并且无其它影响因素的存在，获得优惠券后成单概率会更高。

从人性角度来看，我认为优惠券系统体现出来的便是人心本性的综合表现——

（1）贪婪又节俭

薅羊毛一时爽，是人都想占点便宜，比如近两年的银联6.20活动补贴，消费者们为了早上9点享受超市满100减去38的优惠活动，大妈大爷们甘愿8点就选好商品在结账处排队等候，只因每日的优惠名额是全国限量。

在一线城市的类似活动中，你才能见识到国人的收入消费情况并不如你想象中那么光鲜。消费者在促销活动中占着了便宜，在自认为智商爆棚的自我优越感中沉浸。然而他们哪有商家精明，成功的商人并不是慈善家，他们只是更懂得如何让消费者甘愿掏钱出来还开开心心地回家，甚至是感谢商家给的福利。

（2）大方又懒惰

与节俭又矛盾的是，人们在消费时又是大方的，他们懒得去考量比价关于摆在面前的优惠是否是真的优惠，自认为贵的就是好的。本人曾在张大妈平台发过一个爆价链接，给近期准备买kindle的电商部女同事，她竟然觉得无比复杂并直言看不懂，而本身从事电商运营工作的人都已经看不懂下面这段话，那更可以说明广大人民群众是懒得去思考。

人是好面子的，于是人们鸡贼地为自己懒惰找了一个巧妙的借口“我其实很大方，喜欢就买买买，不在乎价格”。

优惠券系统细节剖析（二）：优惠券后台创建流程设计-2.jpg

图为某导购网站关于优惠流程的介绍

正因促销手段在人性面前具有如此强悍的针对性，优惠券系统如今早已不是电商平台特有。互联网平台中，上到虚拟商品如知识付费、下到线下服务如共享单车，凡是涉及到支付场景的平台基本都会存在对应的优惠券系统。

上一篇处女作我简单地分享了自己对于优惠券系统的分类认识，这次就接着之前的话题，想聊一聊当我们搞清楚优惠券分类那些事之后，系统后台的优惠券创建流程应该怎么设计，来保证后续面对奇形怪状的业务需求时如何让产品迭代更加有效率。

关于优惠券系统的设计

设计优惠券系统时，不要大而全地整理需求想着一步到位，当然更不要上来打开axure就是干，这个在做任何产品需求时都是通用的。

我认为最合适的节奏应该是把需求理解得基本通透后，再横向对比市场上对应产品的优劣，最后才是根据业务需求以及目前的平台实际基础，把最基本最必要最不可或缺的流程做出来（是否必要流程的检验标准就是，这个流程如果不做，整个产品还能不能完整跑下去，如果流程依旧能跑下去那么它就是非必要），之后才开始考虑锦上添花那些（比如广告分发、数据统计等）。

这就好像我们要给一座山修路，我们自然是先爬到山顶从上往下看，然后回过头再下山一步一步把梯子搭起来，优先解决人们安全上到山顶的需求，之后才是关注路上植被风景等问题的规划。当然，技术资源多到用不完的大公司们就当我没说。

优惠券系统首先要理解的便是琳琅满目的各类优惠券到底是怎样一回事，而之前的文章已经介绍过，感兴趣的朋友也可以点击【优惠券系统细节剖析（一）：关于优惠券分类及对应设计思路】看看，那这次就以自己现在负责平台的优惠券需求为例来讲讲。

本人当时设计的添加创建优惠券流程如下，具体分析介绍详见下文：

优惠券系统细节剖析（二）：优惠券后台创建流程设计-3.jpg

1. 优惠券基本信息

优惠券系统细节剖析（二）：优惠券后台创建流程设计-4.jpg

优惠券名称

优惠券领取页面配图配色

总发行量

优惠券有效期

2. 领取

可领取用户

每人限领

3. 使用门槛

使用门槛

面额

需要补充的是，后续若打算推出可平行的另外一些促销功能，如满减、会员价等，则需要提前考虑好促销系统的功能优先级，若碰上一个商品可同时使用多重优惠手段时，则每个级别只能挑一个优惠手段，并按照优先级先后进行依次计算。

以京东为例，50元的商品若参加满199-100活动，且当你手头有一张适用的99-50优惠券，假设你购买4件，则此时第一优先促销手段为“满199减100”（50*4=200>199，可减100），其次才是验证第二优先促销手段“优惠券”（满减后为100元，大于99元，可用券优惠50元），然而从2018年底开始笔者发现京东开始调整优惠系统逻辑，开始实施平行优惠，也就是刚才的案例中已经可以直接使用199-50元的优惠券了（商品价格同时满足不同优惠手段均可符合优惠资格）。

反面案例如淘宝近几年来的双11活动，预热支付定金+定金享受翻倍+品牌、跨店铺等多档优惠券+零点直降+满减津贴等乱七八的促销手段为典型案例，别说消费者了连商家都很难吃透规则。

4. 适用范围

优惠券系统细节剖析（二）：优惠券后台创建流程设计-8.jpg

首先需要注意在商品性质上的明确，比如虚拟商品类（无需发货）或者充值类商品，同样来说是需要与技术人员直接明确是否允许参与优惠券系统规则，考虑到该类商品的利润点较为固定，通常都会从系统层面直接设计让该类商品不参与优惠以避免后续可能出现的运营失误。

关于适用商品的选择，流程上是需要让运营人员一个一个进行勾选，但是考虑到商品sku过多的话，一张全品类的优惠券设置就足以让运营人员骂娘，所以按照目前我的设计是让运营人员可直接勾选一个大范围（比如全部商品或者某一个类目下的商品），然后再从中去剔除某一小部分不适用于优惠券的商品。

我知道有人看到这里肯定会质问某一些运营场景下的设置也是相当的反人类后台操作，但正如前文所言，这个后台设置流程是我根据我们团队当前的实际情况下所做出来的决策，并且也是得到运营部门的认可才会有这样的一个结果。做产品没有办法照搬照抄，别人的案例你只能作为思路上的参考学习，但真正实施起来请还是以自己团队的实际情况为准。

总结

老板或者业务部门只会说一句“我要优惠券功能”，但是优惠券所涉及范围较广，上到顶层分类设计以及后续拓展，下到优惠流程所涉及到的售后结算等诸多流程，另外还需要考虑如何去辅助财务和运营设置优惠券时相对更准确地进行决策。

今天介绍了创建优惠券时所需要注意的最基本的点，那么后续打算再更新一篇，聊聊优惠券所牵扯到的其他产品线（如数据统计、结算售后等）的相关流程功能应该如何设计调整，使得整个促销流程更加顺畅兼容。

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

题图来自Unsplash，基于CC0协议