优惠券模板图片—优惠券模板图片_优惠券模板设计素材
昨天阿强送了我一张购车的优惠券，甚是勾起我要买车的欲望。一个纯钢的男子汉，没有一辆像样的汽车，就像老孙少了金箍棒一样，谈何雄起！此刻，望着这张优惠券，脑子里面想到的竟然不是飞驰人生，却勾起了我对年少头发飘逸时候做的那套优惠券产品的冥想…
说到优惠券模板素材，就不得不提高省，大家好，我是【高省】APP运营高小省，咱们高省是一个可省钱佣金高，能赚钱有收益的平台，百度有几百万篇报道，也期待你的加入。技术支持【高量】（搞流量，找高量）
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
一、优惠券的回忆
那是2016年的第一场雪，稍微比以往时候来的晚一些。公司产品迭代方向需要转战至微信卡包，那个年度最火的新产品，导火线是公司利用微信卡包生产的全网第一张电子诊疗卡。
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
那时，大家都要相信微信平台的巨大流量带来的红利，也就是要相信，微信卡包将可能会是下个风口吧！那么我要做的，在这张卡片的理念基础上，去建立整个优惠券的产品体系。
1. 项目惯性思维
既然要结合微信卡券设计产品，首先，就是要做微信平台开放API能力的调研，理解平台产品的设计逻辑。
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
从文档中轻松的理解到其卡包的设计逻辑：
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
主流程：创建——投放——领取——核销。
当然，创建优惠券，并非是一张实际的优惠券，而是一个优惠券的模板，待用户领取后，根据当前优惠券模板设置好的参数，再生成一张具体的券——一张如同在店铺门口小姐姐给你发的那个券，可以打印出来的券！
创建的渠道，除了可以通过微信平台自己的后台进行创建，还可以开放式的，允许第三方系统通过API接口进行创建，考虑到第三方系统本身可能已经存在优惠券的板块，API还要允许第三方系统自定义券码（会不会有人不知道券码是个什么东西哇？）。
投放渠道任意，只要触达用户即可。如微信公众号消息、短信、第三方系统的APP等，提供给用户去领取。但是有个问题，这里的领取要考虑到添加到微信卡包，所以领取渠道有所受限，因此要放投放渠道的链接放到微信体系里面去。
领取，点击——添加到卡包。
核销的话，也是根据不同场景的需求，设定卡券的使用场景，如线下扫码核销、商城支付时，选择优惠券核销等等。
2. 我设计的产品解决方案
我这样设计了我们系统的优惠券板块：
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
后台创建优惠券时，完全对接微信卡包开方的API，从创建、投放、核销、管理全方位接洽。我家后台亦可管理我们的优惠券，且做到优惠券和微信上的优惠券实时同步。
3. 失败场景举例
后来支付宝也出了卡包，我才醒悟过来，我的上面设计的产品被微信绑架了。或者说，我的产品就是微信卡包的一个弟弟，还是亲生的那种，还不能够再契给支付宝做契弟。
二、实景操作
1. 想起了来自店长老阿姨传授的经验
那天老板专门给我找了个老阿姨，给我介绍他们店里面做优惠券活动的方式：
做好活动预算，预计投入多少钱做优惠券，和财务报备；
设计好优惠券的形态：10元、50元、100元等；
定好每个级别的优惠券要派多少张，且每张定好其唯一的优惠券编码（这个就是券码），且录入系统中；
找UI小妹妹设计个样板，打印出纸张；
让店铺的小姐姐去门口派发给路人或者在收银台顾客消费的时候再给用户发两张；
做好优惠券核销记录，跟踪整个活动数据；
做好经营报表，给一份给财务同事。
有些步骤因为公司的业务流场景不一样有所不同，比如我们公司对优惠券的预算就没有要求，随便运营怎么操作，最后考核指标按照毛利率和销量进行考核就好了。
2. 产品抽象性思维
阿强曾经多次和我强调过，如今互联网看到的基本上所有产品，其实都是以前实物场景的复制。
我仿佛大彻大悟过！的确，在互联网盛行之前，这个实景的业务都进行了多久了！比如说商城购物，就是超市的购物流，你看看那个购物车！比如美团的外卖，从原来是店里的外卖仔延伸到共享外卖仔！等等……
所以一款产品，不应该停留在构思其功能上的表现形式，从其本身的实景业务从出发，理解其操作流，更加便于我们进行互联网的产品化！
回过头来看微信的卡包。我想起来我的钱包，除了钱，什么银行卡、网吧上网卡（你和我一个年代的话，你也有）、某某会所会员卡，还有刚刚老阿姨店里送的优惠券，都塞进去了，这个就是卡包的概念。
而这里每一张塞进卡包里面的卡，卡上面的唯一标识号，就是制卡商系统中唯一的识别号。比如银行卡号（当然卡包没有加入银行卡类型），对应在银行系统中的唯一识别号；比如票证里面的电子社保卡、发票、甚至电子身份证的，也是有其对应的系统的。
于是微信的卡包，我想到的这个模型：
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
3. 我从实景出发思考设计的优惠券方案
深入思考下，微信平台的卡包和我系统优惠券的关系，结论是，他们家是他们家，我们家是我们家，一定程度上面来讲，微信卡包跟我平台毛线关系没有，所以：
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
平台自己玩好可以了，从创建、投放、领取、验收，一条龙搞定。但是老板讲，一定要放到微信卡包里面去啊，看起来就高大上好多！绝对没有毛病，我可以让你放到N多个卡包里面去，什么支付宝卡包、微信卡包，都可以：
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
非必要时，不对接微信卡包。在有用户需要添加优惠券到微信卡包时，可以在这个时刻进行微信卡包对接初始化，也就是从创建、投放、领取一步到位。
当然，在开始之前，根据微信平台的要求，还需要上传一些素材的，比如卡券的背景图片或者图片之类的。记住，这个时候微信那边暂时的优惠券券码，就是我平台上的优惠券ID了。我才不要再把产品寄生虫到别人家的产品中，毕竟，我需要保证我的产品体系闭环先。
4. 想起了一个更垃圾的优惠券产品
讲到这里，我想再分享一张产品图：
技能篇：从微信卡包的产品逻辑来看产品经理的抽象性思维
不要讲什么券码的，拼音创建的那个优惠券，就是优惠券，这样有没有什么毛病？
那么就是每个用户领取的优惠券都是都是一个ID，那么这个东西对接不到微信的卡包去（他们不支持你给每个用户的券码都一样），每个用户不可能领取多张券，这个根本就不是优惠券。
就算那么多那么，这个产品在一个企业里面，竟然被用了6年，且没有迭代更新过！设计的那么垃圾，他的确很垃圾吗？
三、最后
搞产品时，结合实际场景出发，把现实的场景抽象到产品中去，这个我把它称之为抽象性思维。
比如如今的火火热热的中台的概念，把这个中台比喻成一个插板，这个原理会不会有些类似，然后再思考下其工作的原理，再设计下。
