破解既有的行业痛点,解决信息流、业务流、资金流、物流等工业电商核心的方案
解决商品、商家与海关和国检系统备案,订单跨境支付和一键报关的方案
提供车源发布、车源查找、求购发布、报关报检、汽车物流、汽车配件相关服务
全网平台搭建,多触点连接用户,母婴店,专卖店、卖场、商城系统多模式并存
“互联网+零售” 对实体进行补充,又能让企业通过大数据更好地了解消费者需求
汽车配件电商平台能够打通产业链、提高工作效率、去中间化、降低成本等
农产品电商平台直连农产品产地,溯源追溯,传统农业与互联网+进行优质结合
在线考试/教育培训/职业技能/企业内训等,提供教育各个行业的解决方案
使用Spring Boot开发风格做到一键启动和部署,简化分布式系统开发,易二次开发和维护
易写区块链,定制开发私链、联盟链、公链,提供所有源代码,适合二次开发
平台自营+供应商入驻,的高并发解决方案,SpringCloud Alibaba技术架构
区块链+溯源不可篡改,溯源追溯,传统行业(例如农业等)与区块链进行优质结合
供求、求购方数据整合,双向打通货源“供应链”和全渠道“销售链”的电商平台
知识付费/教育培训/职业技能/企业内训等,源码100%开源的在线课堂软件
互联网的技术架构、全新的UI设计、丰富促销体系、多种支付方式、快递实时跟踪
多题型、题库测试、错题收集、章节练习、试卷练习、考试记录、自动判卷、发放证书
易写科技电商系统主体框架全部采用Apache主流框架进行开发,没有任何二次封装,方便二次开发
采用SpringCloud Alibaba技术架构,基于Maven构建,数据库读写分离、支持分库分表、独立图片和搜索服务器等
易写科技商城由京东、海尔电商公司互联网人开发而成,拥有解决高并发、高可用、秒杀等电商方面丰富的经验
易写科技商城代码和数据库开源,数据库每个表、每个字段都有注释,代码每个方法都有注释
易写科技商城系统可以有效防止SQL注入、XSS攻击、CSRF攻击、核心模块采用MD5加密传输,保证系统和数据安全
易写科技商城系统不仅在架构和代码层面把细节做到了,并且在业务流程也是
在介绍具体方案前,我想先强势案例一波优惠券。
优惠券之于电商,可以说是促销手段中至关重要的一环。相比于直接降价,利用优惠券来吸引顾客,其结果明显会更加有效。单纯降价,很有可能达不到吸引顾客的目的,反而会让人对商品的品质产生疑虑。例如一件偶尔被顾客看到的商品,以前都卖140,今天120,顾客很有对这个降价的感知非常不敏感,换言之,起不到价格吸引的目的。但优惠券就不同了,总结来说,它的用处可不简单。
优惠券四大好处:
1. 给顾客一种赶上”活动”,赚到了的感觉。优惠券作为促销活动一种,领+用的过程让顾客经历了一个,拿到可以抵用的钱,把抵用的钱花出去这样一个过程。因此,它更具参与感,也更能调动顾客的购物情绪。相信很多人也和我又一样的经历,点进一家淘宝店铺,如果有优惠券可以领,不管有没有决定要买,先领券再说。
2.拉动顾客二次进店。从第一点最后的分析来看,我们领了券,是否就打开了与卖家通话的一个通道了呢?当然是的,卖家得知了你对他的商品有兴趣,手中还握着你领了券的证据,时不时给你一个提醒:”喂,姑娘!你的券还没用呢,不买就是吃亏阿!”。成功拉回的顾客的概率有多少,我们不谈,但这样的手段,商家必定时屡试不爽的。
3. 促使顾客购买更多的商品。优惠券的数字游戏没那么简单,我们肉眼所见的满199-30,满299-50等等,在商家策划价格时就是满满的套路。本来只想买100的商品,难道眼睁睁看着满199-30的机会在我面前飞过?不可能!而刚好凑199又岂是那么容易就能达成的?超过了几十块金额倒了240,你告诉我你不会再去凑299?安啦安啦,买到就是赚到对不对!
4. 作为活动的触发点传递给顾客。举一个很典型的例子,近期广告不断的每日优鲜,以99-80的超低优惠吸引顾客注册,看起来他们要亏到不行了,但购买过的人应该都清楚,里面的商品的原价大都都是翻倍或更多来标价,消费者能明显感到单价是贵了的,但对于就是贵了多少这个准确的数字,不去深究,感知到的冲击力远不如满99-80来的强。电商虚高原价,用优惠券的套路时屡见不鲜了,但把它作为一种商业模式的突破口,不得不说每日优鲜在这片已经杀成红海的领域里,是做出了创新的。
关于优惠券的套路和优点,以上已经阐述了许多,不要嫌我烦阿喂!毕竟,只有了解清楚为什么做优惠券,我们需要达到什么样的目的,才能好好的深入这个功能,让我们的设计更加灵活,让消费者买的开心,商家们赚的开心。
平台优惠券是个什么玩意呢?简单来说,就是平台补贴,可根据一定规则,将发放的优惠券在各个入驻商家的店铺进行使用的优惠券。相比与店铺优惠券,需要考虑的东西会更复杂,更多样,并且需要结合公司实际的财务环节进行相应处理。
接下来我通过两个大模块介绍平台优惠券设计需要考虑的内容:1.业务流程;2.优惠券规则设计
首先讲业务流程相关内容
由于平台优惠券的补贴在确认收货后,需要以平台的名义将优惠的金额以实际金额打入商家的账户的,所以优惠券的生成、消费涉及到的是实际的金额往来。这就意味着优惠券的整个流程中,每一笔钱的收入和支出都需要有一个完善的体系去支撑,不能让金额算不清楚。
我们可以设计一个优惠券账户,初始金额由财务通过录入补充。将账户中的金额分为两部分,可用金额和冻结金额。其中可用金额表示可用来生成优惠券的金额,冻结金额用来表示已经生成的优惠券总金额,这部分金额是锁定状态,在解冻之前不可被用来生成优惠券。
关于优惠券生成和使用的操作流程,每个产品对于它的定义都可能不同,最重要的还是根据公司实际业务进行设计,让相关部门能够方便的处理这件事情。这里,由于涉及到的资金比较大,在设计方案时考虑到运营部门和财务部门的需求,还设计了初审和复审流程用来保证活动的内容和金额时是与预期相符的。
整体的思路分析如下:
先看正向流程:将可用金额根据需求转化为不同面值的优惠券(只有面值,无有效期),设置相应库存,此时这部分金额就转化为优惠券,即转化为冻结金额。再通过不同活动关联不同面值的优惠券,扣除相应库存,此时为冻结余额的内部转化。优惠券只有通过活动才能被发放出去。具体发放方式将在第二部分进行阐述。顾客领取优惠券并支付订单后,优惠券的相应金额进行解冻并转入在途金额,在确认收货后转入卖家账户。
再看逆向流程:有生成,就必定对应着回收,当一个面值的优惠券我们不需要再使用后,进行回收操作,即可将对应金额解冻,重新转化为可用金额。同样的,对于优惠券活动,活动结束后仍未发放出去的优惠券,也会自动回收到相应库存,可用以参与其它活动。而已发放出去(已被顾客领取)的优惠券,顾客在未支付取消订单时,返回至用户的账户,支付后取消订单以及过期、失效后的处理都是自动返回可用余额。
说到底,我们看到的五花八门的各种券,什么满减券、免邮券、折扣券,其呈现形式各有不同,但实质的东西并无太大差别,只需要将其中的脉络理清,就可以以一个最基础的形式支撑不同的运营需求。
前面已经说到,平台优惠券的发放通过优惠券活动的形式进行,而在创建活动之前,我们需要进行基本的优惠券的创建。基本的优惠券信息很简单,我们只需要明确优惠券名称、面值、数量的信息即可。接着在活动创建时,完善本次活动所发放优惠券的其他属性。有效期、发放张数、发放方式、使用条件、使用范围等等。这些内容也是如何支撑实际运营需求的关键。所以接下来我会一一分析每个点。
所谓发放方式,即本次活动的优惠券,我们希望通过什么样的形式发送到用户手中。比较常用的有自动发放,手动领取,链接发放,优惠码领取等。
自动发放:可以理解为霸道总裁式赋予,即系统自动将券强行塞入用户的账户中,告诉你,快来shopping吧,我们送券啦。
手动领取:有很多平台会设置一些领券的通道,很常见的是淘宝店铺的领券通道,用户在看到这些通道后,主动点击领取,优惠券就成功发放了。
链接发放:活动创建后,我们为活动中的券生成独立的领券地址,这些地址可以让运营投放到不同的页面。 优惠码领取:活动创建后,将所有被发放的优惠券转化为优惠码,通过优惠码来进行发放。
当然要有活动名称啦
活动时间的设置,我们需要根据发放方式来决定是否有必要设置,比如我的发放方式是自动发放或者优惠券码领取时,就没必要做一个活动时间的限制了。
而在手动领取和链接发放的情况下,设置一个活动时间,主要是用于规划我们这批优惠券发放的准确时间区间,体现活动的限制。
同样的,对于不同的发放方式,这里的设置有着不同的意义。对于自动发放而言,发放对象就是指现在这批优惠券我是强行塞到哪些用户手中。而对于其它发放方式而言,则可以理解为谁被允许来领取我发放的优惠券,举个例子,这次活动,我们是针对注册地址北京地区的用户进行的,那在这边我们就需要将这个条件在这里进行限制。
在实际操作设置中,我们允许一个活动添加多张优惠券,以一个活动的形式进行。其中,每种优惠券的内容需要进行单独定义。
预发量
作为平台级别的活动,通常我们进行优惠券活动,都是通过层层审批,且经费是相对固定,有限额的,所以,在进行活动创建时,这次活动发放多少多少面值的优惠券都需要预先被定义好,且不能随意增加。
单个用户领取上限
为了保证活动质量,对每个用户的领取上限进行约束。若为自动领取,则为单个用户发放数量。
有效日期
指券的可使用的有效期,需要注意的是,这里要把活动的有效期和券的有效期区分开来。活动对应着我想发放的日期,而优惠券的有效期是用户领到券后可使用的日期。通常我们可以定义为一段固定日期,或是在领取后X天内进行时用。
使用条件
即优惠券在满足什么条件下才能使用。可根据实际业务进行设置,如满X元,满X件,无条件等等。注意,这里的使用条件从大方向来看是对于订单而已,其实是对订单内在该优惠券的使用范围内的商品而言的。
使用范围
这是一个很容易与使用条件混淆的概念,在我看来,一个是约束钱,另一个是约束生效的商品。可根据实际业务进行相关设计,如限制某些店家,限制某些品类,限制某几个商品等等。
上面提到优惠券的使用条件可能会有非常多种情况,最复杂的莫过于多商家多商品的情况。也就是说,一张100元的优惠券,我们需要根据它的使用范围,来确定它在结算时,对哪些商品的金额进行了减免。
按照比例来分摊每个商品所见面的金额时,会遇到小数点无法取尽,造成所有优惠金额之和可能与优惠券总额不相等的情况。因此在定义这部分的算法时,需要注意的是,将最后一个分摊商品的优惠券金额用优惠券总金额-已分摊的金额,这样就能避免金额不对等的情况。
以上就是对于平台型优惠券的一些思考,欢迎拍砖交流。优惠券部分需要做的更完善,还大有可以挖掘的地方,电商是很明显的运营驱动产品的领域,而产品的灵活性能帮助运营更好的推动平台的发展。
工作日:9:00-18:00
售前:18612670879
微信:18612670879
Q Q:43006111