需求背景：公司的促销体系中已经有了红包和回团立返，现对于微信渠道接入微信卡劵进行促销。
需求拆分：
由于本篇文章主要想讲的是后端产品，对于前端只做简要带过，保证整个流程是通畅的。
前端：
- 卡劵的发放（如卡劵发放着陆页、摇一摇等方式）；
- 用户领取卡劵；
- 卡劵的呈现（列表页可使用卡劵的标识、订单填写页选择卡劵的入口、卡劵列表呈现页）；
- 用户下单时使用卡劵。
后端：
1、下单和支付
当用户获取到卡劵，下单进行支付时，整个订单的金额需要扣除卡劵的优惠金额，这里有一个疑问：电商类的网站，一个订单产生之后不一定是立即支付的，有些甚至是几天之后才能支付完，那么用户下单时使用了卡劵，但过了X天实际支付时卡劵过期了，这个时候订单金额怎么办，卡劵的抵扣还是否有效？
从用户角度来说，我下单那一刻使用了卡劵，我就应该继续享受这个优惠。这里虽然有疑问，但对于最终的方案其实争议不大。不过引申出两个细节：
a、卡劵什么时候属于过期？（卡劵的过期：这就要求卡劵在创建的时候填写开始和结束时间---所以我们还需要做个卡劵的创建页面）
b、卡劵什么时候算是核销？（卡劵的核销：清款成功后进行卡劵的核销）
2、卡劵信息的显示
a、上面我们谈到了卡劵的支付，那么支付完成后，拿到了订单号，我们就可以在后端系统通过订单号看到整个订单的详细信息，如下单人信息、价格明细、OP同事的操作日志等等，当然也会知道对于使用卡劵的订单进行一个标记，如新增一行说明该订单使用卡劵的详细信息：如卡劵号码和卡劵的优惠规则（满2000抵200的卡劵）。
b、除了新增一列说明卡劵的信息之外，在订单详情里还有一处显示也需要加上卡劵，那就是订单的价格明细：
订单总价=产品销售价+单房差+保险-抵扣金额（在这里对于使用卡劵的订单需要减去卡劵的抵扣金额）。
3、卡劵的退款
我们谈到了下单、支付和卡劵信息的展示，顺着这样的逻辑下来，就到了退款。一个使用卡劵的订单他的退款逻辑是怎样的？跟红包有什么区别？我们分开来对比下：
a、对于红包来说：红包属于平摊
如整个订单1000元，使用了100元的红包，而整个订单有2个成人，那么当用户申请退一个成人时，在没有违约金的情况下：退款的金额为（1000-100）/2=450，由于红包属于公司自己的优惠政策，退款后的红包是否回归到用户账户？这个就看公司政策怎么定的了。(但即使退了一个人对于另一个人来说也是享受红包的)。
b、对于卡劵来说：卡劵不是平摊，而是整退
再比如同样整个订单1000元，使用了100元的卡劵，而整个订单有2个成人，那么当用户申请退一个成人时，在没有违约金的情况下：退款的金额为（1000-100）/2=450，但这里跟红包就有了不同，红包是平摊，你退了一个人另一个仍然享受50元的红包优惠，但是卡劵没有退一半的说法，只能把整个卡劵退给用户，但卡劵整退回了用户的账户，那另一个人就没有优惠了，相反还需要用户补回第二个人卡劵抵扣的50元钱，但你让用户退款之后再付款，体验是非常差的，所以这里需要对退款金额和补回金额进行最终的计算，比如这个例子要退给用户450元，又要用户补回第二个人50元的卡劵优惠金额，那就是最终只退给用户400元。
c、还要考虑下发生退款后不满足卡劵使用规则（满1000元抵100）的问题：申请退款后不满足卡劵使用规则且价格有变动时，只在退款审核完成后显示最新价格。
d、注意点：当存在退款记录时，不可再次申请退款，只有退款处理完成后才能再次申请退款，返还卡劵是在退款审核通过后进行。
退款的逻辑有点绕人，接下来我会单独开篇文章分享下退款功能
4、订单变更
对于我们这种旅游行业的非标品项目，每一个订单都来之不易，一个订单产生之后都会有专门的OP同事去跟进，在出游之前很容易订单有变化，比如要再带上谁谁谁（加人），谁谁谁有事去不了了（减人），或者决策有变化了，想换到另一条线路上=> 这就有了订单变更这个功能。
问题来了，卡劵的规则是满1000减100的优惠：
- 如果我这个订单是800元的，现在加了一个人（300元）满足了规则，订单金额是有变化的（原线路变更）；
- 如果我这个订单是1100元的，减了一个人（300元）就不满足规则了，这时候订单金额也是要变的（原线路变更）；
- 如果这个订单对应的产品是可以使用卡劵的，但变更到一个不能用卡劵的产品上，这时候卡劵要判断是否要退回用户账户（新线路变更）；
- 如果这个订单对应的产品是不能用卡劵的，但变更之后的产品可以使用卡劵，那金额也要跟着变（新线路变更）；
- 如果这个订单对应的产品是可以用卡劵，变更之后的产品也可以使用卡劵，那还要判断应该用哪种卡劵（新线路变更）。
看晕了吗？
在我理解中，前端产品经理重交互，后端产品经理重逻辑，需要后端产品经理对于整个流程、系统非常熟悉，要有全局观，有可能某一处的改动会涉及到方方面面。
喘口气，结束了吗？
--！，还没有！
5、监控
刚做后端产品经理时前面4点费了好大劲，终于要看到成功的曙光了，很容易把监控这一点给忘了。
是不是要做一个卡劵的监控页面，可以查询发出去了多少张卡劵，哪些订单使用了卡劵，有哪些是核销失败的卡劵，核销失败的卡劵还要做个手动核销的功能...
6、其他需要考虑的点
- 是否与其他活动（红包、回团立返）互斥；
- 卡劵是否退回用户账户的标准：卡劵已核销或者卡劵已过期则卡劵不退；
- 取消订单时也需要判断卡劵是否退回。
RTX截图未命名.png
整体上微信卡劵的接入后端会涉及到这6个方面，第一次写后端产品的文章，希望跟大家一起讨论，共同进步~
大家有想说的就给我留言吧~
网友评论