为什么会出现优惠券？
优惠券是一种使用频率最高的，用于营销类场景的工具。它有几个比较突出的特点：
① 灵活易用，使用门槛低，规则简单，核算方便。
② 可针对不同人群发不同券的方式，实现精细化运营，使利益最大化。
③ 可承载多种多样的营销玩法，最终全部以优惠券的形式落地，比如金币-》券，积分-》券，XXX 值-》券等。
④ 可快速实现以价格减免的方式完成交易，相比在定价上的调整，使用券则更简单。
定价和优惠券都可以实现对价格上的调整，这里可以举一个简单的例子说明一下：
假设，你是一个卖面包的，你制作了一款面包，成本价是 5 元。现在，你手上有一批客户，在这些客户中你知道有一些客户他们对价格不太敏感，他们可以接受以 20 元的单价来购买，而还有一些客户则不行，他们会觉得 20 元有点贵，但如果是 15 元就没问题。所以，问题来了，无论你是卖 20 元还是卖 15 元，都无法使利益得到最大化。
此时，如果是按照定价的方式，你可能会想到，可以设置两套价格，如果是价格不敏感客户来购买，看到的就是 20 元，如果是价格敏感客户来购买，看到的就是 15 元，这样就能使得利益最大化了。
这就是所谓的价格"歧视"，而且受到"歧视"的反而是愿意花钱的人。
不过，他必然要面对一个问题：如何让不同的人看到不同的价格，并且这些被划分出来的人群，可能还需要有效的隔离开来（不能露馅了！）
实际上，这永远是一个无法掩饰的问题，开门做生意，只要你敢搞价格"歧视"，就一定会被发现。
所以，面对这样一个问题，优惠券就派上用场了，面包依然以 20 元的单价售卖，只不过你会给那些价格敏感的客户每人发一张 5 元的优惠券而已。
从心理层面来看，优惠券是不存在价格"歧视"上的问题的，如果有人要觉得为什么别人有券，而我没有，那商家可以有很多种理由来解释。甚至也可以做到人人都有券，但券值完全可以是"随机的"，有些人"运气好"随到的优惠券金额比较大，有些人"运气差"随到的优惠金额比较小。
简单介绍了有关优惠券的应用场景之后，接下来就来看看在优惠券的系统设计上，主要要考虑哪些？
优惠券的基础属性
首先，当然是有关券的核心属性的定义，以下是罗列出来的一些常用属性：
券基本信息
| 属性 | 类型 | 描述 |
|---|---|---|
| 券名称 | 字符 | |
| 券归属 | 枚举 | 常见的有：商户券、平台券、客户券、三方券。商户券：一般都是商户自己在运营过程中所用的，费用由商户自己承担。客户券：针对某一类客群专用。三方券：一般是由外部其他渠道投放的 |
| 券面额 | 数值 | |
| 券库存 | 数值 | |
| 券类型 | 枚举 | 常见的有：满减、折扣、无门槛。满减：一般是指用户实付满一定金额可用。 |
| 券品类 | 枚举 | 常见的有：商品券、会员券之类的。可根据各自平台所经营的业务范围进行区分 |
| 使用说明 | 字符 | 可用于记录券规则的一些描述等 |
使用限制
| 属性 | 类型 | 描述 |
|---|---|---|
| 可抵扣费用范围 | 枚举 | 根据自己实际业务场景可针对用户在一次消费过程所产生的费用类型，进行区分使用 |
| 抵扣上限 | 数值 | 可针对满减或折扣类的优惠，设置一个最高抵扣的阈值 |
| 券的有效期 | 枚举 | 一般可分为：相对时间与绝对时间。相对时间：指的是从券领取时开始计算，多长时间内可用。绝对时间：直接指定某个时间段，与领取时间无关 |
| 使用范围 | 枚举 | 这个使用范围可限制的类别可以有很多种。可用于指定某类具体商品甚至是某个具体商品使用，也可用于指定渠道上使用 |
| 领取限制 | 枚举 | 可限制领取的终端、领取的用户身份、领取的时间等等 |
| 领取次数 | 数值 | 1 人/ m 天/n 次 |
券的'制、发、用、查'四大要素
优惠券主要是围绕"制""发""用""查"这 4 种场景来设计，接下来让我们逐一进行分析。
制
首先是"制"，包括制什么？怎么制？费用怎么承担？流程是否需要控制等等。
制券通常指的是某一类券批次，比如为了配合某种营销活动，准备了 1 万张无门槛券，具体属性可以参考前面的介绍。
制券的权限通常都是由业务运营人员来控制，偶有业务场景会被授权直接通过 OpenAPI 来制券（开放接口一定要做好防护考虑）。
制券是比较敏感的行为，所以一定要对制券所产生的费用做好核对，比如 1 万张 5 元无门槛券，理论上最高营销费用就是 5 万元，10 万张 10 元无门槛券，则费用就是 100 万元。因此，为了防止运营上的操作失误，通常也是建议可根据金额、承担方、操作人等信息设置一定的流程约束。
另外，关于费用大概有两种形式，一种是"实用实销"，一种是"预付费"。它们都有一些各自存在的业务场景，同时也都有一些利弊，具体如下图所示：
应该说绝大多数场景都是 "实用实销"，准备了一些预算，但真正用掉多少，还要看实际的营销情况。不过在缺少有效运营手段的早期，这种方式很容易造成全网无差别发放的现象。
"预付费"模式有点类似于授信，应用场景比较少，虽然可约束发券的行为，但带来的问题也不少，尤其是在没实际产生营销费用的时候就要先支付，这个局限性是比较大的。
发
制券过后，接下来就是发券。"券"一定要通过某种载体发放出去，比如：营销活动、权益兑换、任务奖励等等。要把"券"设计成相对独立的业务模块，它不依赖于具体的使用方，仅仅是当做一种资源被提供出去。
面临的问题
券的发放方式可分为"定向发券"与"统一领券"两种，"定向发券"是用户被动接受的行为，而"统一领取"是用户主动领取的行为。两种方式本质上没有区别，但在技术实现上却有不同的侧重点需要注意。
行为规范
发券是一个比较敏感的行为，因为它是能够直接触达到用户的，发错了即给公司带来了损失，也给用户造成了不好的影响。
因此"发券"时应当注意规范发券行为（数量、面额、范围等），减少垃圾券对用户的骚扰，如果每天都给你发 满 5000 减 10 元这样的垃圾券，谁受得了！
用
用券最主要的业务就是券的查询以及券的核销，大多数业务场景中都是用户先选券，再消费，比如商品购买、点外卖等；也有一些场景是先消费，再选券，这种一般发生在消费行为是一段持续的过程，比如打车、充电等，因为会根据服务的持续时间来计费，因此一般都是先消费，后选券的方式。
因此，当用户存在多张券时，就需要根据规则来找到满足当前行为的优惠券，并且通常是要帮用户默认选中到"最优"优惠券，这个过程可能会查券中最消耗资源的地方，要结合实际业务情况提前做好相关设计。
确认了要使用的券之后，最后就是核销的过程了，这个过程相对比较简单，通常就是修改一下券的状态，注意重复核销就可以了。至于与之关联的可能还需要生成使用记录或触发某种其他的事件等场景，这个可以考虑直接消息推送即可。
三个特别场景
券锁定
当订单有券参与结算，且又处于待支付状态时，就会出现锁券这样的场景，可以考虑加个类似"使用中"这样的中间状态来解决。
券退回
这个场景多数见于含券支付的订单取消时产生，通常就是一张券从"已核销"到"未使用"的状态。当然，为了降低状态回退所带来的麻烦，也可以考虑直接重新发一张补偿券即可。
券作废
正常情况下券作废主要是因为过了使用有效期还未使用自动作废，这个只需一个后台任务兜底扫描即可，当然如果数量比较多也可以考虑"懒处理"的方式，即在用户查的券的列表时，如果发现某张券已经过了有效期，此时再更新也是可以实现同样的效果的。（这里就需要注意一下，在选券时，要按照时间来筛选，不要按照状态）
除了正常到期之外，运营有时候也需要能在后台手动作废某些券，比如，由于运营失误，发错券了，或券本身是跟着某种权益活动附带的，用户取消了权益，自然也需要作废因权益而产生的其他利益。
计
最后是关于券的统计，这部分主要是为了满足运营上的诉求，比如通过统计券的领取情况、券的使用情况、用券结算的订单情况等，可以反应出相关营销活动对于吸引用户的力度如何，是否起到了拉取、促活、留存等营销目的。
另一方面，在风险管理上也需要关注券的使用情况，比如是否会有用户领取到了明显超正常数量的优惠券，是否有优惠券被使用了超正常数量的次数等等。
所以，为了满足上述的需求，通常我们会在有关于券的各个关键事件中，以消息推送的方式来通知相关业务方，这样即不影响正常的业务流程，也能满足后方对数据使用上的需要。