在上周的时候,我发布了一篇文章
《从红包看饿了么、美团外卖的烦恼》,没想到(自认为)引起比较大的动静,自己也很意外,只是很多人并不是在探讨“烦恼”,也确实不太好聊这个事,笔者本身也是猜测。更多的人来问我,关于优惠券的设计方案,甚至有朋友来找我要关于优惠券设计的资料。

文章对优惠券设计的整个体系进行的大方向的分析整理,梳理了优惠券设计的整体框架,希望对你有益。

首页

其实文章发表的也蛮巧的,在文章发表后的当周,饿了么也将原本以异业合作为主的红包,变成了更有参与感和社交属性的类美团红包,也属于一个蛮巧合的事情。

图片 1

在上一篇文章《优惠券的设计指南(一)》中,已经将优惠券整套系统进行了大的框架梳理,接下来的文章将着重于细化每个系统的设计,将慢慢从框架变成有血有肉的系统。

饿了么分享优惠券调整

image

优惠券系统,作为整套系统的基础和核心,将首先进行设计。当然了,考虑到业务的不同,我在这里做了一个过滤。一方面是优先将框架讲清楚;另一方面就是基于当前饿了么、美团外卖的下单之后分享的红包作为业务基础,去讲解我理解的设计。

其实在去年我的一篇文章《作为产品经理,我是如何理解产品的功能边界?》,为了引出我讲到的“边界”的概念,我借用了设计优惠券的时候的一个例子,在哪个时候,也曾经有朋友给我留言,询问我关于优惠券的设计。

在上周的时候,我发布了一篇文章《从红包看饿了么、美团外卖的烦恼》,没想到(自认为)引起比较大的动静,自己也很意外,只是很多人并不是在探讨“烦恼”,也确实不太好聊这个事,笔者本身也是猜测。更多的人来问我,关于优惠券的设计方案,甚至有朋友来找我要关于优惠券设计的资料。

优惠券系统

说真的,当某一个朋友或读者,问我要相关优惠券或者其他的资料时,我其实蛮怕的,因为任何的产品设计的出发点,都是业务,虽然业务和业务之前有共同性,但脱离业务的设计是没有任何参考意义的,产品的设计,都是基于对业务的理解和目标的出发点而设计出来的。

其实文章发表的也蛮巧的,在文章发表后的当周,饿了么也将原本以异业合作为主的红包,变成了更有参与感和社交属性的类美团红包,也属于一个蛮巧合的事情。

在上一篇文章中,讲到的优惠券系统,包括三部分:优惠金额、限制、有效期。那接下来,将分别去讲述。

为了让大家更容易理解和可参考,本文的优惠券设计指南,是基于饿了么的“下单后分享优惠券”这个业务模式而设计的。完全是我对这个业务的理解而出发,并不能代表饿了么或者美团就是这样设计的。设计仅供参考,希望大家从中学到的方法,如有雷同,纯属巧合。

图片 2

思路框架

本文会将红包、优惠券,统一成“优惠券”这个叫法。

image

一、优惠金额

作为优惠券,作用自然是对金额进行优惠,那优惠的额度,自然是关注的焦点。从目前的情况来看,设置可归纳为两种,固定金额和浮动金额。

一、业务介绍

要想设计好产品,首先要理解业务。

其实在去年我的一篇文章《作为产品经理,我是如何理解产品的功能边界?》,为了引出我讲到的“边界”的概念,我借用了设计优惠券的时候的一个例子,在哪个时候,也曾经有朋友给我留言,询问我关于优惠券的设计。

1、固定金额

固定金额言外之意就是这张优惠券的金额是固定的,
不会随着订单的金额进行变化,比如满减券、立减券,都可算作固定金额。

固定金额属于比较基础性的方式,也是目前比较通用的方式。
满减券意思是满足多少金额才享受减免,比如满30减5元;立减券则没有金额限制(订单金额必须高于减免金额。若订单金额小于减免金额,则使用后,金额为0),使用就会减免。

1. 业务介绍

饿了么优惠券的业务模式如下:

  • (1)当用户在饿了么平台下单成功后,会提示可进行优惠券的分享;
  • (2)用户将优惠券分享到社交平台;
  • (3)自己或其他人可进行领取优惠券到账户;
  • (4)在下单时,可使用优惠券,享受减免优惠;

业务流程

关于分享中的设定第几个人是最大,还有发放异业合作的红包,由于是业务主线下的特点需求分支,因此不在主线范围内。

说真的,当某一个朋友或读者,问我要相关优惠券或者其他的资料时,我其实蛮怕的,因为任何的产品设计的出发点,都是业务,虽然业务和业务之前有共同性,但脱离业务的设计是没有任何参考意义的,产品的设计,都是基于对业务的理解和目标的出发点而设计出来的。

2、浮动金额

浮动金额,就是这张优惠券的金额是浮动的,在某一种情况下会产生不同的金额。引起优惠券价格的因素,一般分为订单和行为。

2. 数据指标

理解了业务之后,那还有一个需要了解,也就是目标,该如何监控我的效果好还是不好,是不是需要调整,那就涉及到几个目标。

  • (1)分享率。也就是当用户下单后,有多少订单比率会产生分享。这是一个源头,所以需要监控好;
  • (2)领取率。当我的优惠券分享出去后,假设可以供10个人领,那分享出去的有多少人领取,还有领满率多少,也就是我这优惠券发出去,有10个用户全部领取完了,这比率多少;
  • (3)使用率。用户领取了优惠券后,有多少的使用率,直接决定了最终的效果,也就是转化率;
  • (4)拉新数。这应该是个附带的,用户分享,势必会产生新用户的注册和下单,这个数据也可以看一下;

数据监控

当然除了以上的,由于业务和公司的不同,还会有其他数据的监控,需具体情况具体分析。

为了让大家更容易理解和可参考,本文的优惠券设计指南,是基于饿了么的“下单后分享优惠券”这个业务模式而设计的。完全是我对这个业务的理解而出发,并不能代表饿了么或者美团就是这样设计的。设计仅供参考,希望大家从中学到的方法,如有雷同,纯属巧合。

(1)订单

订单一般也是比较常见的一种,比如折扣券,就是基于订单进行确定的优惠金额。比如发放的8折券,就代表按订单金额的80%计算,那20%就是优惠金额,但具体的优惠金额会随着订单的价格不同而不同。
当然了,这里的订单价格,一般会分为两种,实际需支付金额和订单金额。由于在部分业务场景中,存在对部分产品或服务进行不计入优惠的范畴,所以会进行区分。

目前,折扣券也是属于比较流行的一种券优惠模式。

二、框架设计

理解了业务模式,也明白了数据指标,假设需求就是实现如当前饿了么、美团外卖一样的优惠券获得。当然这里是为了简化才这样做的,各位需求方,千万不要如上面所说的:“和XXXXX一样就好了”这样的需求,任何一个产品经理都不想听到这样的话,这个在产品经理眼里,不对,不管在谁眼里,都等于没说。

本产品设计,会按照“产品的功能边界”的设计思路,进行对整个系统的设计,也就是通过构建不同的系统,进行对接式的方式,将不同的系统进行串联,最终形成完整的系统。

本文会将红包、优惠券,统一成“优惠券”这个叫法。

(2)行为

行为是指当用户进行了某种行为后,会基于行为进行判断优惠金额。饿了么、美团外卖的第X领取红包最大,就是这样的模式。

但“基于行为进行判断”这个逻辑一般会放到活动系统,而非在优惠券系统。

对于行为类的,
优惠券系统一般会设置优惠区间,设置两档的优惠区间,大的优惠区间和小的优惠区间。然后当有了行为后,基于逻辑后的结果,进行确定是取大的优惠区间,还是小的优惠区间。然后再确定优惠金额。

1. 优惠券系统

既然是一套发放优惠券的活动,那自然会有一个优惠券系统,可以对优惠券进行规则设定。

本质上,优惠券其实就是一套规则的集合体。规则一般包括:优惠金额、限制、有效期等。

优惠券系统

(1)限制

限制里面一般基于业务不同进行不同的设定,以外卖为例,会有使用时间的限制,比如该优惠券是午餐的,那使用时间就是11点—2点;再比如会有品类的限制,比如该优惠券是下午茶的,那所选商家必须是下午茶品类的,比如奶茶店之类。

(2)优惠金额

对于优惠金额,一般是设置当前优惠券的金额,有的是固定金额,比如满减券、立减券;有些浮动金额,比如折扣券,随机券(当前饿了么、美团外卖就是随机券,领取时确定金额)。

(3)有效期

由于优惠券一般是基于活动进行发放,大多数是设定一个有效期限,比如3天、10天,起始日期已领取开始计算的模式。

对于异业合作的券,由于如果在领取时调取第三方领取接口,再进行发放,会存在比较大的风险,一般的处理时,是在优惠券系统创建一条异业合作的优惠券,然后通过导入对方券码的方式进行发放。

对于券码的导入、生成导出,如果业务需要,也会考虑进去。券码的导入时在进行发放异业合作优惠券时而设定,而生成导出,是在借助第三方发放优惠券,而增加的处理操作方式。

一、业务介绍

要想设计好产品,首先要理解业务。

二、限制

这里的限制,是指非金额的限制,金额的限制,在“优惠金额”中已经设置。而这里的限制,是业务层面的限制。

这里拿饿了么、美团外卖的业务举例子。业务层面的限制包括:地区、使用时间、品类……
比如地区,会限制使用地区,发放上海地区的券,
无法在杭州的门店使用;比如使用时间,会限制券的使用时间,该券是下午茶券,从14:00-17:00
,那在此时间段之外的无法使用;比如品类,会限制品类,比如该券是下午茶券,那只是是购买奶茶、甜点等品类时进行使用;

限制有很强的业务属性,完全体现了对业务的理解和深入程度,也从侧面能反映出运营的精细化程度。

2. 活动系统

优惠券是规则的集合体,那活动就是将优惠券包装成一个活动,然后推给用户的实体。

一个活动一般包括优惠券、个性化、有效期三部分。

活动系统

  • (1)优惠券

    也就是该活动准备发放的优惠券,去进行对优惠券的关联。

    这里对于随机券的处理上,一般会基于成本的考虑去设定总优惠金额,尽管每张券可能是随机金额,但一个活动的总的优惠金额其实已经限定了。

  • (2)个性化

    为了吸引用户,尽管活动模板是固定的,但会提供比较大的个性化设定,可随着运营的调整进行不同内容的展示。

    个性化一般包括分享个性化、内容个性化、规则个性化。

    • ①分享个性化。当前主流的分享都变成了微信为主,微信也提供了可定制分享内容的方式,包括标题、描述、图片。

    • ②内容个性化。便是基于活动模板进行的设定,比如头图、领取成功的弹层、按钮的跳转链接、活动说明等等,都是可以进行定制化设定的。

  • (3)有效期

    这里的有效期一般是设定活动的有效期,去限定活动。

    一般是设置一个日期区间。

1. 业务介绍

饿了么优惠券的业务模式如下:

  • (1)当用户在饿了么平台下单成功后,会提示可进行优惠券的分享;
  • (2)用户将优惠券分享到社交平台;
  • (3)自己或其他人可进行领取优惠券到账户;
  • (4)在下单时,可使用优惠券,享受减免优惠;

关于分享中的设定第几个人是最大,还有发放异业合作的红包,由于是业务主线下的特点需求分支,因此不在主线范围内。

图片 3

image

三、有效期

关于有效期的设定,会有两种,一种是固定的有效期,设定一个是时间段;另一种是设定一个有效数,比如30天,一般是从领取之日起30天内有效。
饿了么、美团外卖一般是发放的第二种,从领取之日起多少天有效的方式,可以增加紧迫感,促进用户下单。

3. 发放系统

有了优惠券,去限制使用和确定优惠规则。有了活动,作为优惠的发放实体,供用户参与。那接下来就是发放系统了,去设定活动的发放。

发放系统,是通过对不同节点的梳理,进行设置不同节点的发放活动,及对发放的限制。一般包括范围和个性化。

发放系统

  • (1)范围

    范围是指什么样的用户能够参与到活动的发放,对于像饿了么、美团外卖这样全国性的,势必会进行差异化的优惠,比如对于北山广,需求比较旺盛的,
    参与度高的, 该设定什么样的运营策略,那运营策略的呈现就是活动。

    范围一般会限定节点、地区、业务、用户。地区和业务相对来讲比较好了解,用户也是需要去筛选和过滤的,
    比如对于会员性质的用户和非会员性质的用户,那下单后分享的活动是否进行区别对待之类的。对用户的过滤,是比较考验平台对用户的理解,和运营策略是否执行到位和准确的一个很重要的因素。

    节点表示该活动是在什么样的状态下呈现,比如下单成功、注册成功等等,可以通过设定不同的节点,进行对用户推送不同活动,让用户进行参与。

  • (2)个性化

    这里的个性化,包括两块,限制和展示。

    限制,是指在当前范围下的诸如领取限制等。比如一个用户一天只能领取该范围下3个活动的优惠券。

    展示,是指基于该范围,设定给用户端的展示内容,比如弹层文案、图片等。

这里要注意的是,发放系统发放的活动是基于活动系统生成之后,发放的子活动,也就是当节点发生时,产生的活动是一个子活动。

2. 数据指标

理解了业务之后,那还有一个需要了解,也就是目标,该如何监控我的效果好还是不好,是不是需要调整,那就涉及到几个目标。

  • (1)分享率。也就是当用户下单后,有多少订单比率会产生分享。这是一个源头,所以需要监控好;
  • (2)领取率。当我的优惠券分享出去后,假设可以供10个人领,那分享出去的有多少人领取,还有领满率多少,也就是我这优惠券发出去,有10个用户全部领取完了,这比率多少;
  • (3)使用率。用户领取了优惠券后,有多少的使用率,直接决定了最终的效果,也就是转化率;
  • (4)拉新数。这应该是个附带的,用户分享,势必会产生新用户的注册和下单,这个数据也可以看一下;

图片 4

image

当然除了以上的,由于业务和公司的不同,还会有其他数据的监控,需具体情况具体分析。

四、后台设计

后台框架

上面的内容,只是基于优惠券系统的三部分进行讲述的,属于理论,如果你将按照这个进行设计后台,那将是完全错误的一件事情。

对思路的分析,是要从整体进行归纳和分析,而对于系统的设计,而是从一张优惠券的角度进行设计。
这是完全不同的两个角度。

那回归到一张优惠券,其实就是多个规则的组合,那就需要进行对规则进行梳理,然后集中到一个优惠券上。

后台的设计,会从饿了么的产品出发,
基于APP内看到的内容进行分析,而非官方设计,仅供参考。

4. 数据系统

优惠券系统、活动系统、发放系统,是让这个业务能够跑起来,结合下单系统,可以形成一个很好的闭环。而数据系统,是完成第二部分的,也就是对目标和结果监控,获得数据的数据系统。

数据系统一般需要监控下单数、活动数、优惠券数。

数据系统

  • (1)下单数,是指当用户下单是符合活动发放时条件时,所产生的订单数;
  • (2)活动数,是指当用户进行分享后,产生的活动数;
  • (3)优惠券数,是指用户领取的用户数量,使用可以当做优惠券的一个状态进行标记;

拉新数量,可以通过在优惠券数的统计中,对手机号或者会员ID进行标记是否为新用户的方式产生;

那么在最开头提到的四个数据:分享率、领取率、使用率、拉新率,变可通过数据系统进行计算和展示。

分享率 = 活动数 / 下单数 * 100%;
领取率 = 优惠券数 / (活动数 * 每个活动参与数)* 100%
每个活动参与数即表示每个活动允许多少用户领取;
使用率 = 优惠券使用数 / (优惠券数 – 优惠券退券数)
如果优惠券可以退券,一般会把退券数刨除,也有是不刨除,主要看业务需求;
拉新数 = 领取过优惠券的用户中,标记为新用户的数量。

对于固定计算规则的数据,可以通过图表等更友好的方式进行展示,方便查看。

二、框架设计

理解了业务模式,也明白了数据指标,假设需求就是实现如当前饿了么、美团外卖一样的优惠券获得。当然这里是为了简化才这样做的,各位需求方,千万不要如上面所说的:“和XXXXX一样就好了”这样的需求,任何一个产品经理都不想听到这样的话,这个在产品经理眼里,不对,不管在谁眼里,都等于没说。

本产品设计,会按照“产品的功能边界”的设计思路,进行对整个系统的设计,也就是通过构建不同的系统,进行对接式的方式,将不同的系统进行串联,最终形成完整的系统。

1、规则

从上面讲述到的优惠金额、限制、有效期,其实都是规则的一部分。

从目前对业务的理解和优惠券的设计,大致上分了以下几大限制:金额规则、品类规则、品牌规则这三类。

三、 总结

系统总结

优惠券系统,确定优惠券的规则;活动系统,发放优惠券的实体;发放系统,设定活动的发放规则;数据系统,记录行为中产生的数据。四个系统相互配合,构成一套完整的优惠券活动发放系统。

当然,这里的“系统”不代表是个很庞大的内容,只是用“系统”这个词,来代替相关直接的区隔。

以上前期的思考和梳理的过程,后面的文章,
将深入到每个系统中去,去讲述该如何设计和思考,优惠券本身就是一个比较庞大,而且和业务有很强关联性的产品,借助一篇文章时很难讲完的。

最后,也特别说明一下,由于优惠券本身与业务的关联度非常强烈,业务的不同,会直接影响到整个系统的设计,特别是越细节的内容,越与业务紧密相连。该文章是以饿了么下单之后的分享红包这个业务出发,设计的优惠券整套系统,敬请知悉。

1. 优惠券系统

既然是一套发放优惠券的活动,那自然会有一个优惠券系统,可以对优惠券进行规则设定。

本质上,优惠券其实就是一套规则的集合体。规则一般包括:优惠金额、限制、有效期等。

图片 5

image

(1)限制

限制里面一般基于业务不同进行不同的设定,以外卖为例,会有使用时间的限制,比如该优惠券是午餐的,那使用时间就是11点—2点;再比如会有品类的限制,比如该优惠券是下午茶的,那所选商家必须是下午茶品类的,比如奶茶店之类。

(2)优惠金额

对于优惠金额,一般是设置当前优惠券的金额,有的是固定金额,比如满减券、立减券;有些浮动金额,比如折扣券,随机券(当前饿了么、美团外卖就是随机券,领取时确定金额)。

(3)有效期

由于优惠券一般是基于活动进行发放,大多数是设定一个有效期限,比如3天、10天,起始日期已领取开始计算的模式。

对于异业合作的券,由于如果在领取时调取第三方领取接口,再进行发放,会存在比较大的风险,一般的处理时,是在优惠券系统创建一条异业合作的优惠券,然后通过导入对方券码的方式进行发放。

对于券码的导入、生成导出,如果业务需要,也会考虑进去。券码的导入时在进行发放异业合作优惠券时而设定,而生成导出,是在借助第三方发放优惠券,而增加的处理操作方式。

(1)金额规则

金额规则,主要是确定优惠的模式,包括满减、立减、折扣三类。是固定金额,还是区间金额,会当做一个属性进行设定,基于设定,来确定折扣金额。区间金额不会出现在折扣类型上,只会出现在满减、立减上。

固定金额设置

浮动金额设置

2. 活动系统

优惠券是规则的集合体,那活动就是将优惠券包装成一个活动,然后推给用户的实体。

一个活动一般包括优惠券、个性化、有效期三部分。

图片 6

image

(1)优惠券

也就是该活动准备发放的优惠券,去进行对优惠券的关联。

这里对于随机券的处理上,一般会基于成本的考虑去设定总优惠金额,尽管每张券可能是随机金额,但一个活动的总的优惠金额其实已经限定了。

(2)个性化

为了吸引用户,尽管活动模板是固定的,但会提供比较大的个性化设定,可随着运营的调整进行不同内容的展示。

个性化一般包括分享个性化、内容个性化、规则个性化。

  • ①分享个性化。当前主流的分享都变成了微信为主,微信也提供了可定制分享内容的方式,包括标题、描述、图片。
  • ②内容个性化。便是基于活动模板进行的设定,比如头图、领取成功的弹层、按钮的跳转链接、活动说明等等,都是可以进行定制化设定的。

(3)有效期

这里的有效期一般是设定活动的有效期,去限定活动。

一般是设置一个日期区间。

(2)品类规则

从饿了么APP来看,品类包括:果蔬生鲜、甜品饮品、美食、商超便利、早餐、夜宵、鲜花、医药、帮买帮送、准时达这几个品类。

由于品类作为公共内容,可不再维护范围内,品类规则,只是需要基于业务需要,对品类进行包装和再分组,形成符合的要去,比如鲜果超市红包,则品类会包含果蔬生鲜、商超便利两个品类。

品类设置

3. 发放系统

有了优惠券,去限制使用和确定优惠规则。有了活动,作为优惠的发放实体,供用户参与。那接下来就是发放系统了,去设定活动的发放。

发放系统,是通过对不同节点的梳理,进行设置不同节点的发放活动,及对发放的限制。一般包括范围和个性化。

图片 7

image

(1)范围

范围是指什么样的用户能够参与到活动的发放,对于像饿了么、美团外卖这样全国性的,势必会进行差异化的优惠,比如对于北山广,需求比较旺盛的,
参与度高的, 该设定什么样的运营策略,那运营策略的呈现就是活动。

范围一般会限定节点、地区、业务、用户。地区和业务相对来讲比较好了解,用户也是需要去筛选和过滤的,
比如对于会员性质的用户和非会员性质的用户,那下单后分享的活动是否进行区别对待之类的。对用户的过滤,是比较考验平台对用户的理解,和运营策略是否执行到位和准确的一个很重要的因素。

节点表示该活动是在什么样的状态下呈现,比如下单成功、注册成功等等,可以通过设定不同的节点,进行对用户推送不同活动,让用户进行参与。

(2)个性化

这里的个性化,包括两块,限制和展示。

限制,是指在当前范围下的诸如领取限制等。比如一个用户一天只能领取该范围下3个活动的优惠券。

展示,是指基于该范围,设定给用户端的展示内容,比如弹层文案、图片等。

这里要注意的是,发放系统发放的活动是基于活动系统生成之后,发放的子活动,也就是当节点发生时,产生的活动是一个子活动。

(3)品牌规则

这个可以算作是品类的一个细分,当然也可以独立拿出来进行设定。

对于连锁类的比如麦当劳,一个品牌下面包含很多的门店,但无法通过品类限制,则可通过品牌进行规则设定。这里与品类规则是个互斥的,也就是设定了品牌,就无法设定品类,而且品牌是单选,不建议无法进行多个选择。

关于品牌规则, 可在设定一张优惠券时进行设定。可不进行规则设定。

4. 数据系统

优惠券系统、活动系统、发放系统,是让这个业务能够跑起来,结合下单系统,可以形成一个很好的闭环。而数据系统,是完成第二部分的,也就是对目标和结果监控,获得数据的数据系统。

数据系统一般需要监控下单数、活动数、优惠券数。

图片 8

image

  • (1)下单数,是指当用户下单是符合活动发放时条件时,所产生的订单数;
  • (2)活动数,是指当用户进行分享后,产生的活动数;
  • (3)优惠券数,是指用户领取的用户数量,使用可以当做优惠券的一个状态进行标记;

拉新数量,可以通过在优惠券数的统计中,对手机号或者会员ID进行标记是否为新用户的方式产生;

那么在最开头提到的四个数据:分享率、领取率、使用率、拉新率,变可通过数据系统进行计算和展示。

分享率 = 活动数 / 下单数 * 100%;

领取率 = 优惠券数 / (活动数 * 每个活动参与数)* 100%
每个活动参与数即表示每个活动允许多少用户领取;

使用率 = 优惠券使用数 / (优惠券数 – 优惠券退券数)
如果优惠券可以退券,一般会把退券数刨除,也有是不刨除,主要看业务需求;

拉新数 = 领取过优惠券的用户中,标记为新用户的数量。

对于固定计算规则的数据,可以通过图表等更友好的方式进行展示,方便查看。

2、优惠券

设定好了规则,就要开始设定优惠券了。此时的优惠券,完全是基于规则的整理和组合了。

优惠券

三、 总结

图片 9

image

优惠券系统,确定优惠券的规则;活动系统,发放优惠券的实体;发放系统,设定活动的发放规则;数据系统,记录行为中产生的数据。四个系统相互配合,构成一套完整的优惠券活动发放系统。

当然,这里的“系统”不代表是个很庞大的内容,只是用“系统”这个词,来代替相关直接的区隔。

以上前期的思考和梳理的过程,后面的文章,
将深入到每个系统中去,去讲述该如何设计和思考,优惠券本身就是一个比较庞大,而且和业务有很强关联性的产品,借助一篇文章时很难讲完的。

最后,也特别说明一下,由于优惠券本身与业务的关联度非常强烈,业务的不同,会直接影响到整个系统的设计,特别是越细节的内容,越与业务紧密相连。该文章是以饿了么下单之后的分享红包这个业务出发,设计的优惠券整套系统,敬请知悉。

3、之后

难道这样就结束了吗?显然并没有,这里只是将规则也好,优惠券也罢,只是将新建做了一个界面的设计,其他的还包括列表的展示、筛选条件的选择、编辑时的可编辑部分……都是需要后续基于业务进行逐渐丰富的。本文就不在赘述了。

五、异业合作

那对于异业合作的是怎么样的一个模式?

其实异业合作就是将合作方作为优惠券的发行方,进行对优惠券的发放,一般的步骤是:

异业合作发券流程

那么对于优惠券需要做的就是:1、区分是自己券还是合作券;2、发谁的券;

那么单单从优惠券的角度,是加了一个模式,当模式为合作券时,需要同时增加合作方选择。

合作方优惠券

当然了,既然是合作方的券,那就需要在列表中增加一个导入功能,可支持导入合作方的券,同时可单独设置导入的规则,比如提醒、提醒警戒数等等。

关于优惠券的发放逻辑,包括异业合作,将在下一篇文章《优惠券的设计指南(三):活动系统篇》中,详细为大家讲解,优惠券的发放逻辑,敬请期待。

素材下载地址:
http://pan.baidu.com/s/1slodnVR
密码:h429

相关文章