优惠券是的一个常见的营销工具，看起来简单但想把逻辑做好又十分辛苦。这个月第一次完整的做了一个优惠券需求（包括前台与后台）所以我打算做一次复盘。
PS：这次复盘的缺点在于前期竞品分析没有形成文档，所以图例较少。（下次一定）
本篇将从券的流程、券的成本、券的属性、券的状态、券与物的关系（业务解耦）、券与人的关系六个角度来分析。
一、券的流程
设计方案前，先要对业务有个大体的认识。
1、我们的业务基于什么需求要设计一个优惠券功能？
2、这个券是用在什么场景？
3、这个券涉及到哪些角色？
4、其他竞品（横向和纵向）的优惠券的使用流程是怎样的？他们的券都包含哪些内容？有哪些门槛和限制？
带着以上问题去进行前期调研发现。目前市面上的优惠券主要使用场景分为两种类型。分别是线上和线下。
线上：如京东、淘宝、拼多多。这种券的特点在于线上（自家的APP）领取，线上消费。
线上券又分为平台券和单店券。也就是说这张优惠券是全平台通用还是只限在一个店用？
线下：如各大超市、商店，这种券的特点在于线上（自家的APP，双微自媒体以及其他合作渠道）领取，线下消费。
如果是线上券的话，一个完整的流程通常是
流程开始
a、商家-在后台设置优惠券基本信息（领取时间、券的有效期和额度等）并发布。
b、用户-进入商铺
c、用户-领取优惠券（用户不知道有券怎么办？）
d、用户-选购商品
e、用户-付款并使用优惠券
f、商家-确认款项无误后发货
g、用户-商品完好，确认收货（此处略去物流角色）
流程结束
这些流程会有各种各样的问题：
1、在a流程要考虑券可以发给哪些人？假如有多张不同额度的券，是否要根据用户的权重发放不同的优惠券促进转化？
2、在c流程，用户不知道有券怎么办？如果他是直接进入商品页下单怎么办？（淘宝会在该店有券，但用户未领券时帮用户自动领券，但美团不会自动领券，或许可以思考下为什么。）
3、在g流程，如果用户退货，已经使用的优惠券怎么处理？
a~e流程都介绍了人的行为，那么这段期间系统做了什么呢？这也是产品经理需要考虑的事情
同样分析线下券流程
流程开始
a、商家-在后台设置优惠券基本信息（领取时间、券的有效期和额度等）并发布。
b、用户-进入活动页面
c、用户-领取优惠券
d、用户-在线下选购商品
e、用户-展示优惠券券码
f、商家-店员核销优惠券
g、用户-展示付款码
h、商家-收款（配置好扣减金额）
流程结束
线下券同样充满着各种问题：
在b流程，用户都能从哪些场景进入活动页面？ 是线下门店扫码？还是公众号扫码？ 如果是通过扫码进入优惠券页面，那可不可以在扫码的时候就完成领券这个动作？一定要进入页面再点击领取吗？
在d流程，优惠券是适用于所有商品吗？ 又或者是仅适用于生鲜产品？促销商品能使用优惠券吗？
总结完上述内容后，可以对优惠券有一个基本的认识。我们需要分析在这个过程中，有哪些触点可以让用户发现优惠券，使用优惠券。
前台页面其实没有太多可以讲的，无非就是考虑优惠券需要展示给用户哪些字段，比如名称、数量，按钮的状态，如何最大程度的传递给用户有效信息。
重头戏在后台，优惠券的重点在于边界与规则的把控。
二、券的成本
其实这方面我不是特别擅长，由于自己不是技术出身而且经验不足，所以很难估算准确的成本。但做完做个需求后，还是能了解一些分析的角度。
1、对业务来说，优惠券是一个独立的营销工具，还是配合某次活动的副产品？
2、对公司来说，优惠券是否具有长期价值（使用的频率是类似618那样的一年一次或者是一月一次？预计覆盖的商铺数量和优惠力度，优惠券能否真正促进转化，举个例子：保时捷5元优惠券）
3、对团队来说，与优惠券同期的还有哪些需求在排队，优惠券的需求优先级如何？
这个时候需要以当时的客观条件分析利弊。
如果是低频的优惠活动（平台级），完全可以做一个专门的活动页，而不对现有的结构进行改造，因为做一个新的小产品总比改造旧有的庞大系统要简单。
但如果是让各店铺自己配置优惠券（商铺级），那就有必要在原有的系统中加入一个优惠券模块了。（参考有赞）
加入更复杂的因素，假如做了一次平台级的活动，公司发现效果不错，想从低频活动做成高频活动，那这时候，就需要在旧系统中加入优惠券模块了（参考美团外卖会员）。
开发的人手也会成为影响因素，但大多只能是影响什么时候做，而不是做不做。
三、券的属性
属性分为基本属性和其他属性
A、基本属性指的是所有的券都共有且不与其他业务发生关系的属性
例如：券的名称、数量、类型、使用有效期、备注
1、券的名称（标题）：名称是让用户第一眼理解券的概念的元素，是除了券的造型、样式外最重要的元素。在移动端展示时，需要考虑可见性，确保屏幕能够展示完整的名称。所以需要设置名称的字数限制，或者通过技术手段让优惠券的名称始终保持在一定领域内（自适应）。
2、券的数量：数量包括总量、已领取数量、余量。已领取数量和余量通常不是人为控制的，商家通常只需要设置总量。其他两个字段可以让商铺了解初步的推广效果。
3、类型：券的类型多种多样，例如折扣券、立减券、代金券、随机金额券（红包）等
这些券类型将会影响券的使用规则。
1）折扣券：购买商品可以享受X折折扣，通常是在总价的基础上乘折扣。
2）立减券：立减券分为三种，单次满减、循环满减和阶梯满减。
a、单次满减：消费金额满100元后减30元，消费达到200元仍然减30，不会累加。
b、循环满减：消费金额满100元后减30元，消费满200元减60，满300元减90，依次累加
c、阶梯满减：消费金额满100元后减10元，满200元减30，满300元减80元。
3）代金券：通常使用无门槛，直接代替现金消费。
4）随机金额券：互联网营销常用手段，消费后随机减免一定金额（类似红包）
4、使用有效期：用户获得券后需要在指定期间消费。
5、备注：通常用来展示使用规则、使用地点、使用条件等。
B、其他属性指的是适合于业务或与其他业务发生关系的属性，例如优惠券仅限于（非）内部员工领取。优惠券需要在某个页面展示，展示时间和领取时间如何设置，展示的时候是否需要封面，这个封面也是属性。优惠券适用于哪些类型的商品，适用于哪些门店？
我在设计自己的优惠券的时候，本来想把展示时间和领取时间融为一个字段，即展示即可领取。但遭到项目成员的反对，建议把展示时间和领取时间拆分开，但我个人又觉得不合理，所以自认为取了一个折中方案。不强制填写展示时间，当不填写展示时间的时候，展示时间=领取时间，这样既保证了必要的展示，又减少了操作上的繁琐，在选择上更加灵活。
PS：设计字段的时候需要考虑优先级，展示时间和领取时间哪个概念更重要？
我觉得是领取时间，因为创建优惠券的目的是被领取，而不是被展示，所以展示时间需要服从领取时间。
四、券的状态
状态的梳理是最容易让人头痛的事情。
这是我最开始工作的时候做的一个角色状态对应表
优惠券更加复杂，因为它不仅包含自身的状态，还包括了一些关联状态，比如时间。
优惠券自身状态通常为：待领取、已领取。
加入时间后的新增状态：未开始、已开始、已结束（领取时间结束）
用户领取优惠券的状态变化：未使用、已使用、已作废（使用有效期过期）
与用户无关的状态尽可能少的展示，例如已结束的券直接隐藏掉就好了，和用户无关。
梳理状态是一个很痛苦的过程，但同时做好了也是很有成就感的过程。只有清楚状态，才能描述清楚流程。
五、券与物的关系（业务解耦）
知道前面的内容后，大致就知道如何创建一个优惠券了。但是只有实践过才会发现一个更深刻的问题。
我们创建了一个优惠券，创建的究竟是券本身还是一个优惠券入口？
换句话来说，创建券本身意味着，我创建了这个券后，他就放在仓库里，只有当我把它拿到商店时（关联到业务上），它才会变成消耗品。
创建优惠券入口意味着，我创建了这个券，他就始终在商店里，而不是在仓库里，无论用户领取还是使用，都是与商店发生关系。
其实在需求初期的时候，创建优惠券入口是符合直觉，而且不会有问题的，因为大家都只有一个商铺。但随着业务的增多，场景也逐渐增多。以淘宝为例，淘宝可以领券的场景很多，例如店铺、直播、聚划算等，假如创建优惠券入口，假如我想把店铺的优惠券页关联在直播中，那么店铺和直播就会建立一层关系。但是店铺和直播的基础属性是不同的，直播房间的名称和店铺的名称。
不是一个字段（概念）。如果把这些都放在一个页面里，会导致业务错综复杂。
所以最好的方法是把优惠券放在仓库，假如直播需要优惠券，那么就去仓库取货，而不是去店铺取货。这个略微类似于中台的概念，需要更深刻的理解业务解耦。
关于后台的表格字段设计（哪些字段应该主动展示，哪些字段应被动展示）：通过技术大佬的讲解，初步理解了后端建表、跨表查询的逻辑，将表格字段大而全的展示在页面中不仅会影响服务器性能，而且会影响用户使用后台的体验。例如优惠券在后端建表分为属性表和关系表，当页面中只展示单表（属性表）字段时，访问速度最快。有些字段是需要时时刻刻展示的，例如券的数量、名称、关联店铺的名字。
有些字段用户并不需要时刻看到，例如现在在哪些渠道展示，最好的办法是：把展示渠道设计成一个按钮，当他需要设置的时候点击按钮查询现有的关联渠道。如果一定有必要的话，可以在表格里加一个字段显示 是否有关联的渠道 结果是：是/否。
六、券与人的关系
只有有人用，优惠券才有价值，这也是其被创造的目的。用户的每一步操作，在后台都应该有相应的记录。
何时领取？在哪里领取？何时使用？在哪里使用？用在了那里？
如果是线下优惠券，还需要核销操作，记录好这些信息，不断优化迭代产品。
