前言
在上一篇文章中，我们了解了优惠券的起源，以及随着互联网的出现，优惠券的能力进一步被挖掘的发展历程；今天直接上干货，聊一聊Saas商城系统的优惠券产品逻辑究竟要如何设计。
优惠券的框架设计
优惠券的生命周期如下
我们的优惠券设计的目的，也就是解决生命周期每个环节的问题。
- 店铺如何发布优惠券？
- 店铺中的用户如何领取到优惠券？
- 领取到优惠券的用户如何使用优惠券？
- 店铺通过那些维度去复盘优惠券的效果？
其中的问题1、2是放在一起考虑的，发布优惠券的时候，我们不仅需要考虑优惠券的基本信息，也需要提前思考优惠券通过什么渠道发放到目标用户手中。
我们首先聚焦于发布优惠券的产品逻辑。
发放优惠券
发布优惠券中我们可以将其分为2个大类，基础设置与发放规则。
基础设置包含优惠券名称、优惠券类型、发放数量，等的优惠券的基本信息，这样的基本信息在任何商城几乎都是通用的。
发放规则是发放渠道、定向发放、发布平台、领取限制，等等平台独特的，配合运营而存在的设置。
基础设置
这部分产品逻辑无论哪一家的saas都是大同小异的，都是对现实优惠券的抽象。
有的saas系统中，将优惠券的设置单独抽出来，叫做优惠券模板，其产品流程为，首先发布优惠券模板，然后发布优惠券的时候再选择模板，随后设置发放规则，才算发放成功，比如微盟；
绝大部分saas都没有这样做的必要，因为如果不是极其复杂的产品，过于细化产品逻辑，反而增加了技术、运营的使用难度。
券名称（用户见） + 券名称（店铺见）
券名称不仅需要设置用户可见的优惠券名称，还需要设置后台独有的优惠券名称
为什么存在这样一个字段呢？
因为同名称 + 规格的优惠券可能被发布在不同的渠道，如果不存在字段在后台进行区分，店铺运营人员就无法通过用户见的优惠券名称快速区分同名优惠券的具体渠道；
为了满足运营人员快速区分渠道的目的，系统内部就需要针对优惠券增加一个内部可见的名字
也许有小伙伴会说，将不同的渠道信息写到优惠券备注里面不就好了，这样确实可以，但是优惠券备注字段一般是不支持搜索的，这就需要运营人员手动筛选，所以店铺见的券名称字段是非常有必要的。
这2个字段在优惠券列表页面都需要支持搜索。
优惠券类型
尽管优惠金额千变万化，我们始终可以用满减券、折扣券这2个抽象纬度进行归纳；当然虽然场景的精细化，还可以衍生出更加细分的优惠券类型，我们先说通用的。
折扣券除了设置具体折扣之外，一般还要设置门槛与优惠上限，我们归纳一下，一般这样设置
- 优惠内容
- 满xx元，打xx折
- 无门槛，打xx折
- 优惠上限
- 无优惠上限
- 最多优惠xx元
满减券的逻辑和折扣券类似，不过满减券已经设置了具体的优惠金额，所以不再需要设置优惠上限，一般存在以下设置
- 优惠内容
- 满xx元，减xx元
- 无门槛，减xx元
以上2种类型几乎包含了通用saas商城90%以上的应用场景，所以如果不是非常重视用户运营，或者行业需要，增加额外的优惠券类型是不划算的。
趣味性的包含随机金额券，则需要设置随机区间、商品兑换券，需要设置指定商品、买一送一券、赠品券，此类优惠券使用频率与场景相对低频，所有在开发优先级上，需要慎重考虑。
应用范围
回想一下，我们拿到的线下优惠券，是不是基本都会指定单品或者指定类目，这样指定优惠范围的逻辑在saas商城系统的发布优惠券中是不可或缺的，一般应用范围存在以下几种纬度。
指定商品、指定类目、指定供货商、全场通用
注意一点，这里的指定都是可以指定多个的，并非只能指定一个，比如指定多个商品、指定多个类目。
另外就是关于全场通用，这个选项saas商城谨慎添加，因为该应用范围存在以下特点
- 应用范围太大
- 同时使用频率不高
- 全场通用券容易被撸羊毛，偏离效果预期
- 一旦运营人员点错，后果不堪设想
所以如果全场通用类型优惠券在业务上不是必要的，则不进行添加。
发放数量
这就是指优惠券具体的发放数量。
要注意的是，发放数量在编辑的时候，一般只能添加，不允许减少，这是因为减少优惠券可能导致已领取的优惠券数量超出实际库存，也会对系统的稳定性造成风险。
有效期与活动时间
在店铺后台发券的时候可以指定优惠券可使用时间，一般存在2种类型
- 用券时间
- 指定用券时间范围，比如指定xxxx - xxxx时间段可用
- 指定领券后有效期，比如领券后x天内有效
- 活动时间
- 执行之间端，优惠券是
用券时间的限制，大家都比较好理解，存在时间限制的券，会增加用户的使用动机，存在有效期的优惠券也降低了程序的运行负担。
而活动时间，我调研多数竞品看是不存在的，而我站在店铺运营者的角度来看，觉得这个字段是有存在的必要的。
我们可以想象一个场景，在春节节假日期间运营需要发布了一张全场优惠券，用户领券后，30天内可用，春节之后无法领券。如果不存在活动时间，运营人员就需要在春节节假日结束的时候手动关闭优惠券，或者活动入口。
这样的事情，完全可以交给程序完成，就是增加活动时间的概念。
还有一点需要注意的是，当活动时间小于优惠券的使用时间的时候，优惠券不会随着活动时间的过期而过期，而是按照自己的使用有效期规则。
到此为止，我们的发布优惠券的基础模块就完成了，这一部分的产品设计是比较简单的，大部分的产品逻辑都是类似的，无论是参考竞品，还是自行设计，最终都会走向类似的终点，将尽力聚焦于商家运营需求，或者用户需求才是重点；
基础设置的示例图
完成了如何发布优惠券，下一步，我们就要看看用户如何获得优惠券。
发放规则
发放渠道（重点）
我们可以想象一下，在我们的日常生活中，有多少种途径可以完成领券动作
- 在商品详情页领券。
- 在社群中的优惠券链接完成领券。
- 在线下海报完成领券。
- 通过特定的卡密兑换优惠券。
- 在签到、抽奖活动中获取优惠券。
- ….
我们可以想到很多很多领券的途径，在我们发布优惠券的时候，需要控制优惠券可以在什么渠道被领取，如果没有渠道的概念，原本打算发给社群的优惠券，在商城类就可以领取，券就会被截胡了；后期的数据统计也无法细分查看不同渠道的转化率。
另外优惠券有了渠道的区分，即使是同样规格的优惠券，在后期的优惠券数据统计上，也可以看到不同渠道的效果如何，总之，优惠券渠道的区分对于店铺运营来说都有很重要的意义。
一般存在什么样的发放渠道呢？
商城渠道
用户可在商城内的优惠券集合页面、可用商品的商品详情页面领取优惠券
手工渠道
一般用于客服为用户补发优惠券，用户无法手动领取。
外部渠道
运营可以导出可兑换优惠券的券码，并分配给第三方，第三方的用户通过兑换、购买等等方式获取到指定券码，最后按照活动提示，回到商城中，将兑换码兑换成可使用的优惠券；一般用于异业合作。
以上3个渠道为基本渠道，几乎每个saas商城都存在的，而下面的渠道则和具体的业务绑定，属于个性化的渠道
券包渠道
券包渠道优惠券无法直接被用户领取，而是需要运营人员在后台的券包管理模块，选择多个该渠道的优惠券，发布成一个券包，用户再通过指定渠道、或者首页弹窗，领取券包，自动获取券包中的所有优惠券。
抽奖渠道
发布在抽奖渠道的优惠券，可以在发布抽奖活动的配置中，配置指定优惠券，用户即可通过抽奖获得该优惠券。
签到渠道
发布在签到渠道的优惠券，可以在发布签到活动的配置中，配置指定优惠券，用户即可通过指定的签到天数获取该优惠券。
标签渠道
发布在标签渠道的优惠券，可以在标签管理中配置指定优惠券，用户达成某种条件，自动获得标签的时候，也就会自动获取优惠券。
自动标签可以有效的完成用户精细化运营的需求，我文中所写的方式是，先发券，再去标签管理中进行绑定，如果精细化运营要求比较高，可以在发布优惠券的时候就指定标签，这样操作上更加直观。
关于 券包、抽奖、签到、标签与活动运营存在强关联的优惠券渠道，如果对运营不存在精细化的需求，可以不在进行划分，统称为自动渠道。
细分的渠道虽然可以让系统更加稳健，让后期的统计更加简单直观，但是也不是没有缺点，增加了实际运营的理解难度，也增加了操作步骤，所以到底是精细化还是简单直观，需要根据自己的产品特性进行判断。
领取限制
券的数量是有限的，一个用户可消费的量也是有限的，如果不对券的领取加一限制，会造成券的浪费，也会造成潜在订单的流失，所以发放优惠券的领取限制是很有必要的
领取限制一般存在以下几种
- 不限次数
- 每人限制x次
- 每人每天限制x次
- 每人每月限制x次
领取限制并非一成不变的，究竟是什么样的领取限制，在设计产品的时候，我们需要根据服务对象的需求来决定。
领取与使用平台
很多saas商城不仅支持微信小程序，可能还支持h5、微信公众号、xx小程序，等等。
首先，不同平台的运营规则是不一样的，比如虚拟类商品就不允许在小程序中进行售卖，那么虚拟类商品的优惠券就不可以在微信小程序中被领取与使用；或者某些运营需求，我们希望用户在指定渠道领取与使用，这些运营需求的实现都需要再发布优惠券的时候限制领取与使用平台。
是否加入微信券包
如果saas商城支持微信公众号、微信小程序，我们的ToC的商城用到微信的鉴权能力，技术上就没有阻碍了。
开启该功能后，用户在商城中完成领券的时候，我们也可以将券加入到用户的微信券包，加入微信券包的券存在过期提醒，可以快过期的时候二次唤醒用户，也可以通过优惠券直达商城，是不错的功能。
不过要注意的是，加入微信券包的券，尽量是高价值的，低价值的优惠券无法引起用户的兴趣，快过期了再提示用户使用，会加剧用户的反感，甚至导致用户的投诉，所以该功能也需要慎重使用。
外部优惠券的发放逻辑
在上述优惠券发放渠道中，存在一个比较特殊的优惠券渠道，就是我们的外部渠道，外部渠道的券，是我们发放给第三方产品，或者公开区域，用户无法在站内获取的优惠券。
因为站内无法获取，则需要我们导出券码，让用户可通过站外渠道进行领取，所有我们的后台需要支持导出优惠券的功能。
为了更好的运营效果，优惠券也不是一股脑全部导出的，因为可能存在多个外部渠道，A渠道需要1000张，b渠道需要2000张，不能让运营人员去手动拆分做这种工作，所以我们需要先生成指定渠道，再导出优惠券。
外部优惠券在优惠券列表表格中会多出2个按钮，第一个是生成，第二个是导出。
假设我发布了10000张优惠券，分别导出给A、B、C渠道，则发布完成后，点击生成，生成的时候填写生成数量、导出渠道，完成指定渠道的外部优惠券的生成，B、C同理。
外部优惠券生成完成后，再点击导出，再选择上一步声明的指定渠道，即可导出指定渠道的所有优惠券兑换码，同时还可以在导出时设置券码状态，未领取、未使用、已使用或者全部，针对性导出。
最后，我们将导出的csv文件，给到第三方的外部渠即可。
到此为止，我们发放优惠券的全部功能就梳理完成了。
用户使用优惠券
在C端用户使用优惠券的逻辑就非常简单了，为了更好的用户体验，领券页面到下单的产品路径一定是越短越好，一般存在如下特征
- 商城内存在一个“我的优惠券”页面，我的优惠券页面需要有券码兑换功能，方便用户兑换发放出去的外部优惠券
- 如果优惠券是指定单商品，点击使用优惠券，则直接进入指定单商品，如果是多商品可用，则进入一个可用商品集合页面，确保最短产品路径。
- 在最终下单环节，自动帮助用户选择最便宜的优惠券，同时为用户提供切换可用优惠券的产品功能。
关于ToC的产品逻辑可参考竞品非常多，也不是本文的重点，所以这里就不做过多赘述了。
优惠券效果复盘
每当我们的优惠券活动结束后，并且用户的券已经全部被使用，或者失效，我们便可以根据优惠券的多维数据建立漏斗模型。
发券数量 - 领券数量 - 使用数量
另外还有优惠券成本、优惠券支付金额、优惠券新老用户数，等等偏向于业务维度的数据统计。
假设数据分析发现，大量用户没有领券，我们则需要反思我们渠道是否存在问题，导致优惠券的曝光不足。
亦或者领取到使用的转化低于预期，我们则需要考虑，领券用户是否对商品不感兴趣，或者券的价值过小，最终导致用户领券，但没有足够的下单动机。
总之，在领券与使用2个环节的转化漏斗结合用户画像，以及渠道的，等相关影响因素，可以分析出一些宝贵的结论，再反哺下一次的优惠券营销活动。
最后
优惠券作为saas电商系统最常见的营销活动，在用户的拉新、促活、转化，等多个维度都可以发挥作用，是作用极大的，贯穿整个系统的功能，所以各位产品，一定要思考用户的需求，慎重做产品决策，构建出操作便捷、功能强大的优惠券模块。
