优惠券/优惠卡系统开发，优惠券/优惠卡App开发，优惠券/优惠卡小程序开发，需要了解优惠券/优惠卡模式详情费用工期模式制度功能等可咨询从事各类软件开发，优秀的团队为您量身定制解决方案，价格合理，用心服务

　　优惠券/优惠卡系统功能模块

　　无论是电商、外卖、打车、旅游等平台，优惠券/优惠卡都是拉新、促活、转化的必备工具。优惠券/优惠卡在不同平台的叫法也不同，有些称之为红包，有些称之为 代金券 ，有些称之为优惠券/优惠卡，但是其本质都是一样的。

　　优惠券/优惠卡系统有哪些用处？

　　用户需要的不一定是占便宜，而是占便宜的感觉。对运营人员来说，优惠券/优惠卡是重要而实用的营销工具。

　　大数据智能营销平台新零售称，优惠券/优惠卡从本质上来讲，是一种“价格歧视”策略，是 商家针对不同的消费者需求而进行的价格差异化，既不侵犯消费者平等权，也不违背公平原则，而是商家追求利润化的合理定价行为。

　　举个栗子：

　　假设一个汉堡成本5元，定价10元时，100人会接受此价格。

　　定价15元时，有60人会接受此价格，前者利润为(10-5)×100=500元，后者利润为(15-5)×60=600元。

　　但商家不想放弃另外40个支付意愿较低的消费者，于是决定用5元优惠券/优惠卡来吸引他们，同时对剩下那60个对价格不敏感的消费者依然维持15元的原价销售。此时商家利润为 60×15+40×10-5×100=800元，达到了化。

　　对用户，优惠券/优惠卡是个心理学问题， 用户需要的不一定是占便宜，而是占便宜的感觉。

　　如果产品直接降价，短时间内确实会使销量上升。但是当时间一长，用户熟悉了这个价格之后，这种刺激作用就没用了。当你提升回原来的价格，反而会使得销量下降。

　　而使用优惠券/优惠卡的形式，利用一种对比效应，使用户产生了占便宜的感觉，让用户产生一种有便宜不占白不占的冲动，从不买到买，从买到多买。

　　优惠券/优惠卡是一套规则的组合，它的基本信息包括优惠券/优惠卡名称、发放数量、优惠券/优惠卡是否可叠加、每人限领张数、是否和其他促销同时使用(优惠优先级)、使用规则等。

　　优惠券/优惠卡系统应用场景

　　把应用场景中的需求功能化，就可以得到系统的功能结构图了。

　　根据应用场景，整理出的功能结构。

　　优惠券/优惠卡系统流程

　　优惠券/优惠卡的“生命周期”：生成、发放(领取)、使用、结果回收。

　　优惠券/优惠卡系统功能

　　大数据智能营销平台新零售，优惠卡券系统的功能从结构图中可以看出是4个模块，结构图只是系统的框架，功能需要处理更细节的需求。

　　1、券管理

　　券系统的核心和基础就是券，需要先有券这个“物质”载体，才能有券的发放和使用等后续的业务及流程。

　　创建优惠券/优惠卡是优惠券/优惠卡系统设计的步，主要有以下几部分组成：基本信息、优惠类型、使用范围、有效期等。

　　券需要设置使用规则，但是只有规则无法实现“发放”和“领取”功能。规则需要有载体才能发放给用户，这个载体就是券码。同样的券规则发给N个不同的用户，使用规则相同，但每张券的券码不同。当用户使用券时，系统可以根据券码来判断这账券的使用规则是什么。

　　所以除了券的使用规则，我们还需要根据这些规则来生成具体的券码，有券码才能发放给用户。

　　1)券规则(券模板)

　　券的种类，主要有：礼品券、折扣券、满减券、立减券、优惠码等。

　　2)券码管理(券管理)

　　在券系统中券码才是正真的券，券规则只是一个逻辑。系统发券、用户领券、消费用券在系统中都是通过券码的流通来实现的。

　　券码就是一串随机生成的数字+字母组合的字符串，理论上越长可容纳的券数量越大。为了实际使用中方便，一般10-16位已经足够使用了。

　　券码要选择券规则来生成，这样生成的这批券码就有了对应券规则的券。

　　2、券活动管理

　　有了券码接下来要想办法把这些券码发放给用户，能让用户自己领，甚至花积分、花钱买那就更好了。

　　创建的优惠券/优惠卡只是一系列规则的组合，通常还需要一个活动页。活动页上可放一张优惠券/优惠卡，也可放多张，具体看业务需求。

　　活动通常包括活动基本信息和分享设置等。

　　基本信息：包括活动名称、活动时间、活动图片、活动状态和活动规则等。

　　1)发券设置：

　　运营人员通过券系统给用户推送券;设置发券营销活动，系统自动给用户发券;通过其它营销活动给用户发券(满赠、新人礼包 等)。

　　用户获得优惠券/优惠卡的渠道有很多种，主要有以下几种：新手注册、会员领取、邀请送券、活动送券、分享发券、主动除非等。

　　2)领券：

　　用户领取有两种方式：直领和点击领取。

　　设置领券活动(前端设计领券活动专区)，用户进入领券活动后自行领取;在前端页面展示券，用户自行领取。(商品详情页);通过其它营销活动领券(积分、抽奖、邀请有礼等)。

　　3、券使用

　　券的使用从场景不同可以分为：下单使用和 核销(非下单使用)，其实严格的讲两个方式最终的目的和结果都一样。

　　首先，要核实券的状态是否可用，以及是否满足券的使用规则;其次，如果满足券的使用条件则将券标记为“已使用”，同时给用户相应的“优惠”;，按照系统的“分摊规则”来将优惠的这部分金额做处理，以满足财务的记账要求。

　　1)下单使用

　　绝大多数的券都是在下单场景下使用的，因为一切营销活动的目的都是为了“下单”，券同样也不例外。

　　a. 线上电商下单：大家日常在京东、阿里系产品中券的使用都是线上电商中使用券。

　　b. 线下门店下单：现在越来越多的“新零售”都会遇到优惠券/优惠卡在线下使用的场景。其实也没有那么复杂，可以借鉴美团团火锅的场景：在美团团个火锅，到店以后出示订单详情的二维码，这样就解决了线上和线下打通的问题。

　　当然，并不是表面看起来这么简单，后面详细讲解。

　　c. 客服下单：如果 你们的平台客服人员还承担电话下单的职能，那么客服在下单时也需要考虑券的使用。

　　2)核销(非下单使用)

　　礼品券和满减券、折扣券的不同：礼品券可以直接礼品，不需要下单。而满减券和折扣券 下单是必要条件。

　　所以礼品券在电商平台并不多见，或者几乎没有。

　　礼品券更适用于线下向线下引流的场景，用户凭券到店可以一个……

　　a. 礼品券核销：用户凭券到店，在门店核销券。给用户发礼品。

　　b. 异业合作：异业合作大多都是临时的活动合作，所以一般情况下不具备系统接口打通，异业商家可以使用我方的券。

　　为了满足异业商家发放我方的券，可以将券码导出。通过异业商家的系统发放。或者直接把券码印成实物券，发放给用户。

　　用户到商家使用我方优惠券/优惠卡，也可以通过“a”的礼品券核销功能实现，只需要给异业商家开发系统权限即可。

　　3)优惠券/优惠卡退还：

　　要看具体的场景，一般有以下几种：

　　用户下单未支付，取消订单，优惠券/优惠卡可退还;商家在订单未完成的情况下，发起退款操作，优惠券/优惠卡可退还;用户下单支付后，申请退款，优惠券/优惠卡不退还。

　　4、券统计分析

　　数据分析是对用户领取、使用优惠券/优惠卡进行数据统计，从而查看活动效果。投入多大成本，带来多大转化率。

　　以下提供几个统计维度，仅供参考：

　　领取率;使用率;优惠总金额;用券总成交额;优惠总金额;费效比;用券笔单价;拉新数。

　　优惠券/优惠卡状态可分为：待使用、已使用、已过期，已取消。

　　优惠券/优惠卡系统的设计

　　上图涉及的内容基本上都能一目了然，接下来我们将重点放在优惠规则的设计上。

　　优惠规则无疑是优惠券系统的核心部分，能不能限度的适应市场运营需求，就看优惠规则实现得怎么样了。

　　显然，用穷尽法去实现市面上的优惠规则是不明智。

　　正所谓“世上不变的就是变”，我们必须提炼出优惠规则的本质，才能“以不变应万变”。

　　笔者对市面上常见的优惠规则进行了调研，并结合自身业务需求，可以将优惠规则大致分成两大类：

　　1、计算型规则。形如“无门槛直降20元”，“满xx减xx”等，这些规则都暴露给终端用户，是显而易见的，让用户知晓这个优惠券是如何参与计算。

　　2、限制型规则。相较于计算型规则，限制型规则大多数情况下是隐性的。比如：限制某些用户领取，限制某套券模板最多能发放多少金额的优惠券，限制优惠券的渠道等。这类规则可以很好的支撑日常的运营工作。

　　“万物相生相克”，众多的优惠规则，也并不是都能共存的，这里就引入了规则『互斥性』的概念。当一个优惠规则与另一个优惠规则不能同时存在于一套模板里的时候，我们就认为这两个规则是互斥的，这在设计规则的时候也需要有所考虑。

　　其次，优惠规则也会讲究先后顺序，所以必然就带来了一个优惠规则的『优先级』属性，我们约定，数字越小，表示越优先，也就是按从小到大的顺序。

　　以下给出一张完整的规则表，信息量较大，笔者将做必要的解释。

　　规则表中，渠道限制、对象限制、金额限制和数量限制四者皆属于限制型规则，优先级排在了较前面。同时，也给出了参数说明，规则描述，相对于模板的关系以及互斥规则，这些都是一目了然的。

　　接下来的扣减规则和封顶规则同属于计算型规则，也算是优惠券的重中之重了。

　　笔者着重解释一下满减规则中的“阶梯满减”。我们平常会看到有这类说法：每满100元减10元，言下之意便是：满100元减10元，满200减20，以此类推，笔者将其称之为“阶梯满减”规则。

　　优惠券/优惠卡系统规则编号设计

　　规则表中有涉及好多数字，笔者设计了一套生成规则。

　　规则编号是int型，Java 编程语言中，int全长 32位，如下图所示：

　　1、位是符号位，固定为0，且不允许出现 32位全是0的情况，即为正整数；

　　2、高8位是规则组别编号，理论上允许的数值范围是0~255，但是实际的业务规则是假设最多有15组优惠规则，每组优惠规则编号取10的倍数，范围即为 10~150；

　　3、第10位和11位作为备用，暂无实际用处，固定为00；

　　4、中间15位，存放规则组下的细则编号，允许的范围0~32767，但是实际业务规则是要达到两两互斥的目的，取值如下(以四位二进制为例)：

　　0001

　　0010

　　0100

　　1000

　　结论：排除全为0的情况，那么有N位，就有N组两两互斥。如果组内组外互斥都考虑，那么可取值就更少了；

　　5、末6位存放规则组的优先级，允许的值范围是0~63，实际取值从1开始，考虑到之后会插入其他的规则组，会在每两个规则组别直接预留两个级别，初始的优先级设置为1，4，7，10，13，16…；

　　6、按照上述规则，根据既定的组别和优先级可以生成上表中的细则编号。

　　渠道限制83888577

　　0 00001010 00 000000000100111 000001

　　用户类型限制167775300

　　0 00010100 00 000000000110001 000100

　　用户限制167776900

　　0 00010100 00 000000001001010 000100

　　总金额限制251660487

　　0 00011110 00 000000000100011 000111

　　单位金额限制251662535

　　0 00011110 00 000000001000011 000111

　　总量限制335545290

　　0 00101000 00 000000000001111 001010

　　个人所获限制335544778

　　0 00101000 00 000000000000111 001010

　　无门槛直减419430989

　　0 00110010 00 000000000001001 001101

　　满减419431565

　　0 00110010 00 000000000010010 001101

　　打折419436813

　　0 00110010 00 000000001100100 001101

　　封顶规则503323024

　　0 00111100 00 000000001100110 010000