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

前言

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

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

（1）贪婪又节俭

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

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

（2）大方又懒惰

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

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

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

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

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

关于优惠券系统的设计

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

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

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

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

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

1. 优惠券基本信息

• 优惠券名称：通常每一张优惠券都会有一个名称，部分平台为了方便运营人员管理会设置两个字段，一个是后台内部看的，另外一个是给C端用户看。
• 优惠券领取页面配图配色：考虑到优惠券在发放传播过程中对于平台或商品品牌推广的需求，可设计允许运营人员在一定程度以内的自定义操作性。以本人当初设计为例，如下图所示，上方头图可在后台上传放置固定大小尺寸的平面图，而为了保证页面视觉的统一性又不至于增加过多的开发需求，下方可在后台填写对应色值并在前端进行相应显示，当然往往这种设计是需要考虑默认通用图的样式的。

• 总发行量：优惠券通常数量设置有限，这个是需要运营人员经过一定的核算成本之后再定下来的，不是拍脑袋随便填。
• 优惠券有效期：如上一篇文章所属，有效期通常有两种，一种是“从A时间点到B时间点”，另一种是“自领取后X天内有效”。考虑到后者变动因素较大，风险不可控，如果是平台第一次推出优惠券系统则建议先设计前者，后续若有业务场景需求则再加个需求选项上去即可。需要注意一点的是，关于时间范围需求需明确具体时间点，并精细到秒，但每次让运营去填具体秒数估计又会骂街，所以通常需和程序员明确时间点A到B为“xxxx-xx-xx 00:00:00到yyyy-yy-yy 23:59:59”，其中xy由运营人员自行配置。

2. 领取

• 可领取用户：通常优惠券会限定哪一类用户才可领取，比如“仅新用户”可领取，同样的，系统初期先做一个“全体用户”可领取即可。这里建议最好把这个“可领取用户”字段也写到需求文档中，即便它当前只能必选“全体用户”一个选项，因为如此一来程序员也会明白你后续会在这个上面做新的选项出来，那目前他就可以在初期就为后续的拓展预留好接口和字段从而方便后续的迭代。
• 每人限领：指每个人最多能领取多少张同样的优惠券。这里需要明确判定单个用户的指标，绝大多数平台在下单时如果用的第三方授权登录通常必须绑定手机号才可顺利下单，那此时就存在一个问题，即微信授权登录用户（未绑定手机）是否能领取优惠券，如果能领取则需要考虑后续账号合并时的优惠券汇总处理，如果不能领取则需要设计领取时相应的引导绑定手机号流程。

3. 使用门槛

• 使用门槛：指用户形成订单时需要达到何种条件才能使用优惠券。无门槛的要万分慎重，因为这就是白花花的钱，如果平台有了一定知名度但是不设置风险预防机制（防止有心人恶意攻破后台机制或者利用运营人员失误操作而侵占平台利益）的话，就会很容易发生几个月前拼夕夕的黑客薅羊毛事件了。
• 面额：面额的话通常直接设置即可。笔者考虑到相关风险问题，决定无论从后台输入或者是系统规则中直接限定优惠券金额大小，另外针对无门槛优惠券进行更加严格的限制。

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

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

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

4. 适用范围

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

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

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

总结

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

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

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

题图来自Unsplash，基于CC0协议