文章会从优惠券的几种使用场景说起，对满足场景的流程设计和优惠券逻辑配置做了简要分析，希望对你有益

大家知道，前几年O2O火的时候，各家平台为了拉新促活都大量补贴用户。彼时各种优惠券满天飞，力度大到什么程度呢？可以说，只要肯下功夫去找券，用户一天的衣食住行都花不了多少钱。

甚至还催生了一条刷券-卖券-刷单的产业链，专业薅羊毛组织眼观六路耳听八方，平台活动上线就一哄而上囤积大量优惠券，然后在某宝上低价出售。这么一来平台高兴——订单量、用户量瞬间上升；用户高兴——享受同样的产品和服务却能节省很多钱；羊毛党高兴——空手套白狼而且没什么风险。最后“羊毛出在猪身上”，平台通过VC融资，VC再逼着平台在资本市场上卖身。

在这个过程中优惠券可谓功不可没，起到了培养用户习惯的作用。试想象，如果滴滴、快的不大量发券，有多少用户会尝试手机打车；如果美团、饿了么不发券，用户手机点外卖的频次会是怎样。就目前的市场情况而言，但凡是做线上线下业务对接的，没有哪家平台不发券。不搞个活动发个券的，都不好意思说自己是电商或者O2O。

那么问题就来了，优惠券平台一般都是公司内部使用，不为外人所知。而且业务越多越广，优惠券平台的逻辑就越复杂；公司越大、部门越多，优惠券审批、发行的流程就越长。这就苦了产品狗了。要说简单的页面逻辑和交互逻辑，到处都能抄得到。不但如此，还能边抄边品头论足，对孰优孰劣说出个一二三。

但是对于优惠券有哪些逻辑，优惠券平台该怎么搭建，一张优惠券怎么完成从生产到消费的流程，这些问题不是简单的看两眼别人家的产品就能知道了。而这些问题正好是本汪要通过文章给读者叨叨的。文章会从优惠券的几种使用场景说起，然后接着谈满足场景的流程设计和优惠券逻辑配置，最后再对平台权限做一个补充说明。

（由于本犬只熟悉O2O相关的业务，对于电商类的业务不够了解，所以只能从O2O的角度来谈）

一、优惠券使用的场景

使用优惠券的目的无非是为了拉新或者促活（对电商而言，还有提高客单价的功用）。好的优惠券设计能扩大平台的知名度，降低用户使用的门槛，迅速吸引一批用户进入平台，以较低的成本提升平台的活跃度，拉升用户的ARPU值，提高平台的交易流水。优惠券大多配合活动一起发放，通常有以下几个使用场景（从平台方的角度看）。

需要注意的是这里只是做了粗略的区分，具体的使用场景根据不同的业务类型，平台的不同发展阶段，以及不同的营销目的都会产生差异。比如，关注微信公众号给用户送券，推荐其它用户注册后给推荐人送券，用户完成实名认证后领券，用户成功绑定银行卡后领券等等。总之，只要是能想得出、跟踪的到的线上活动，只要是能辅助实现业务目的的场景都可以考虑使用优惠券。

二、优惠券平台的整体流程

对于业务量大的平台，优惠券平台可以是一个单独的系统。每个业务线可以有自己的App、网页、公众号等，也可以有自己的营销节奏和打法，但是都可以调券平台的接口来实现优惠券的生产。券平台也能按照规则控制各条业务线的用券情况。以比较规范的流程而论，生成一张优惠券需要经历4个步骤，每个步骤都可以对应到系统中的一个模块。

第一，建立营销预算。本汪待过的公司都在年末制定下一年度的整体预算，在每个季度会调整滚动预测并对上一季度的营销开支、营销效果等进行回顾。当然，营销费用可以花在户外广告上，可以花在SEM上，也可以花在用户补贴上。优惠券可以归到用户补贴一类，如果与公司的财务系统打通，或者财务人员手工将用户补贴的预算录入系统的，则在创建预算时直接选择即可。如果没有这方面的系统支持，则需要和财务部门明确是否有预算及预算的额度是多少。

第二，基于预算创建营销活动。营销活动不是请客吃饭，不是写文章，不是想做就能做的，得先掂量一下腰包里有多少钱。如果当前周期内的营销预算都花完了，即使您想做活动公司财务部门也不会同意的（除非另外走审批流程追加预算，此处不讲）。

读者可能会问：有钱我直接发券就行，想要什么券就发什么券不就结了，为什么要再创建活动呢？请注意，我们这里说的是优惠券营销平台，不单单是生产券和管理优惠券，更要追踪优惠券产生的效果和给平台带来的价值。承载优惠券的是一个又一个的活动。成熟的运营部门会开脑洞想各种“阴招阳谋”来达到“喜欢您来，喜欢您再来”的目的，那么必然会策划各类活动。但是每个活动的效果如何，带来了多少PV，多少UV，转化了多少个新用户，产生了多少订单、多少流水，这些都是运营部门所关心的（不然没法跟老板交代，也没法吹牛逼啊）。

活动的模型中包括名称，开始时间，结束时间和活动渠道。优惠券批次的生成必须在活动开始和活动结束的时间之间，而投放渠道主要是为了能统计渠道的效果。一般来说线上渠道可以有App、网站、公众号、微博及合作的网站，线下渠道有地推、楼宇广告、公交车身等等。

第三，在活动下创建优惠券批次。为什么需要批次呢？一次精心策划的市场营销活动是细节的堆砌，需要经历预热、开幕、高潮、收尾、二次营销等过程，每一个节点需要不同的打法也就需要不同批次的优惠券支持。

随便举个例子来说，比如本汪要做一场电商的节日活动（本汪没做过电商，以下纯属瞎掰）。在预热阶段我需要给新注册的用户发放一批新手券，让新老用户去领取品类券、店铺券和全场通用券；在开幕阶段，为了进一步刺激用户消费，我需要生成一批优惠券包，并通过短信的方式告知没有领取本次活动优惠券的老用户；在高潮阶段做个转盘抽奖，给下单付款的用户抽奖的机会，去随机抽取半价券或者免单券；在收尾阶段，为了处理客诉，需要客服手动给用户发券安抚；最后，在货品到达用户手上时，可以附上合作商家或者品类的纸质店铺券，刺激用户后期继续在平台上消费。

如此下来，一场活动需要好几个批次的优惠券来覆盖各个阶段的营销需要。此外，即时是一个阶段的一种玩法也需要多个批次。再次举例，为了扩大传播刺激用户分享我的电商活动页面，我给在banner页面上报名参加活动的用户A送券，如果A分享了活动链接到朋友圈再送A一张券，B在朋友圈里看到了A分享的页面，进入页面去注册成为新用户，我再给B送一张券。这么一来，就需要准备3个批次的优惠券了。与活动的道理相近，对批次进行管理能更好发现各个批次的效果。当然能创建批次的前提是期间内有预算，并且是在活动进行期间。

第四，基于批次发行优惠券。发行优惠券是需要对应场景的，也就是说应用的场景决定了优惠券的发行方式，决定了有些券由系统自动触发，而有些券需要人为发放。因此，除了选择优惠券的发行方式，还需要选择发给哪些用户，是发给新用户，还是老用户，是全平台发放还是符合某些特征的用户发放，这些都需要调取CRM获得用户名单后才能确定。此外，如果平台有相应的政策，可能不能给同一个用户在一段时间内重复发券，便于控制成本。

其实就大多数平台而言，是比较难获得用户的人口属性的，而用户在平台上活动所产生的运营数据更容易利用得多，所以通过BI并结合CRM来筛选具有一定平台特征的用户是较为合理的。如果系统不能给予太多支持，也可以给人工操作留下空间，在模块上留一个功能直接导入用户名单即可。

三、优惠券的配置逻辑

这里引用一张京东后台的图，读者可以先感受一下。其中大多数的字段和配置都是电商和O2O业务所通用的，此外再配合业务本身的需要进行相应的调整即可适用。

抽象整理后，可得到如下思维导图，各个字段和维度均已列出，满足一般的适用场景应该没有压力。

四、关于业务权限的说明

优惠券平台的最终用户主要是运营人员和财务人员。财务人员在平台上的作用在于制定和管理营销预算，以及已使用优惠券的核销，未使用优惠券的平账等。他们并不参与优惠券的生产和发放，所以不需要这部分的权限，但是财务人员需要相关的财务审批权限和查看报表的权限。

上文提过这个平台模型是面向一个公司所有业务部门的，所以在超级管理员之下需要配置多个事业部主管担任管理员角色，在事业部管理员之下是总部的运营人员，总部之下是全国其它城市的运营人员。运营人员需要活动管理权限、配置和生产优惠券的权限、查询优惠券的权限。

就数据权限来说，普通的数据权限规则（即什么职级的人看到什么级别的数据，什么区域的人看到该区域的数据，管理员看到所有的数据）就能满足要求，这就不是这篇文章要讨论的内容了。

五、结语

有人说补贴对于平台就像是兴奋剂一样，短期使用可以起到良好的刺激效果，但是如果长期进行下去则伤害极大。其实这种说法不见得准确，如果平台流量足够大，会有很多合作商家愿意为流量买单，而平台不需要出一分钱。

如何让羊毛出在猪身上是商业模式和商务策略的问题。当平台拉来商家后，活动也做了，订单也上去了，但是可能来的用户都是羊毛党而不是目标人群。羊毛党把一个平台薅秃后接着对其它平台下手，如何防范刷单是风控的问题……除此之外涉及到优惠券相关的话题还很多，本汪暂不全面阐述，留待以后再写。

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

题图来自PEXELS，基于CC0协议