案例分享：手把手带你做“会员卡”后台管理设计

橙子哥哥 2023-07-28 03:21:30

大家好，今天给大家带来了新的干货，前面讲过了“财务流水”和“财务对账”的相关设计；这一篇趁热打铁，抽“财务流水”其中的一个“交易项目”——“付费会员业务”（严谨，后面称“会员卡业务”）来讲一讲。

“会员卡业务”听上去好像都是C端玩的东西，其实不然，“会员卡业务”不仅和用户的权益息息相关，因为涉及到收入，所以这块业务也和财务密切相关。

“会员卡业务”听起来简单，但是实际入手设计的时候要考虑到的点还是特别多的，一不小心就有可能给后面的工作挖了一个坑，今天给大家梳理一下这块产品设计。

好了，闲话少说，我们直接进入主题吧。

一、业务背景

业务背景其实很常见了，简单来说就是“付费会员卡业务”，类似于市面上视频会员、音乐会员等等，按照时间的长短去买，买了之后就可以在指定时间内享受特权，这其中所涉及到的有C端用户的操作以及C端与后台的交互等等。

对于C端用户而言，只有简单的三步，打开APP、下单、支付就可以享受会员权益了；而对于后台就相对复杂一点了，要记录操作，还要改动数据，大家会问，这有什么难的？前面几步确实没什么难度，但是涉及到业务闭环中的“退款”的时候，就需要稍加设置避免踩雷了，下面给大家细讲如下。

二、会员卡购买支付流程

1. 业务流程

购买流程与后台数据交互相对简单，直接给大家描述要点加图示了。

C端动作：用户下单——支付——获取会员权益
后台作业：【记录用户购买记录】、【记录会员卡购买记录】、【后台改变用户属性】、【设置会员到期时间】、【记录收入流水】

2. 【后台作业】项目释义

1）【记录用户购买记录】：相当于是用户操作日志。

2）【记录会员卡购买记录】：单独记录会员卡的购买记录，这里注意，为什么要单独记录会员卡的购买记录呢？

举个例子：如果用户使用了优惠券，使支付订单金额为“0”，那么就不会跳转至第三方的支付软件支付了，从自己APP内即可完成支付；同样道理，第三方支付平台亦不会有流水产生，而这条记录，也不宜记录至“财务流水”中，所以就单独拿出一个表记录用户的会员卡购买记录，也用于用户在C端查看账单使用。

注：记录会员卡购买记录的时候，建议将本次购买记录的会员起止时间也记录上，这是个关键点，下面讲到退款的时候会提到。

3）【后台改变用户属性】：根据用户购买的会员产品，改变用户对应的属性。

4）【设置会员到期时间】：根据用户购买的会员卡时间，设置用户的会员到期时间。

5）【记录收入流水】：根据订单详情，记录收入流水。

注：这里提到了多个表，大家看上去功能可能会有所重复（“用户购买记录”、“会员卡购买记录”、“收入流水”），没错，部分数据是有重复的，这里建议大家根据实际业务需要调整；如果问有那么多数据重复为什么不放到一张表里，因为实际业务需求的需要以及多表合用带来的冗余数据和调整困难以及查询问题各家技术解决方案不同，这里就不做具体技术讨论了。

3. 流程图

给大家用序列图描述一下流程吧，实在找不出更好类型的图表来描述了。

产品经理，产品经理网站

这一步需要的后台操作其实很少，基本上就是生成了一些数据而已，便于各个业务部门通过数据来做分析，都是些表格配合查询条件的界面，我就不放出来了。

三、会员卡申请退款流程

说起笔者会员卡退款的流程设计，真的是很充满戏剧性，因为当时系统还不是很完善，退会员卡的这个事情就一直被搁置着，还是走的线下实现——客服登记表格，同步给产品，然后再交给开发直接改数据，是不是很Low？也就当时数据量小的时候可以这样应付一下；结果没过多久，因为笔者所在企业地区业务调整，要面临大面积的退会员卡业务了，这时候才着手设计退会员卡的业务流程，可以说是仓促上阵了；虽然仓促，但是设计过程还是有条不紊的，该有的流程都有了，该预想到的问题也准备了解决方案，最终保障了我们能够平稳处理这次“事件”。

这也算是单独给大家交代了一下“退会员卡业务”的业务背景了吧Hah，虽然是一次仓促的设计，但是没吃过猪肉还没见过猪跑吗？不就是把钱退回到用户钱包里吗，这有什么难的？尽管笔者对这块业务在规划的时候有所准备，但还是踩了不少雷，和我的程序员伙伴共同努力，才如期交付了产品，下面把经验汇总一下，分享给大家。

1. 业务流程

在讲这块业务流程的时候，要给大家一些提示，有些历史大家没有经历过应该也听说过吧，早期的话费充会员然后申请退款、宽带充会员申请退款，现在的APP STORE申请退款等等；这些业务如果说有一个共性的话，那么都是如果退款是需要用户主动去提诉求的；而受理用户诉求的岗位是“用户服务部门”，也就是我们常说的“客服”。

然后呢，我们就明确了业务的发起以及业务在系统的入口。

C端动作：线上/电话提出诉求；
企业客服：查找用户信息——登记/操作退款申请；
企业审核：审核诉求，同意or不同意；
后台作业：【生成会员退款申请】、【后台改变用户属性暂停用户会员权益】、【同意与打款-原路退回/特殊】、【记录用户退款记录】（对应“记录用户购买记录”）、【记录会员卡退款记录】（对应“记录会员卡购买记录”，且需要改变“会员卡购买记录”的退款状态）、【记录支出流水】（对应“记录收入流水”）、【不同意-恢复用户会员权益并消息通知】。

2. 【后台作业】项目释义

1）【生成会员退款申请】：这个操作是由“客服”在后台操作生成，我们这里仅就“会员卡退款”业务展开讨论；这项业务在创建退款申请的时候也是存在两项注意点的，这两点是不太常见的业务场景，但也是实际业务中需要注意的。

恰巧笔者这两种情况都遇到了：

是否允许超过期限的会员卡购买申请退款，参考APP STORE购买的产品超过会员使用期限后仍然可以支持申诉退款；
是否支持按剩余天数操作退款申请，可以理解为是否支持退款金额手动设置，不超过原支付金额即可。

注：【生成会员退款申请】这一项中，退回方式也是我们要注意的事项，下面会讲到退款有“原路退回”和“特殊”，这里原路退回可以理解；但是还存在特殊情况，例如支付渠道没有退款接口，超过支付平台要求的退款时间等等，因为存在特殊的情况；所以建议在客服操作申请的时候就加以判断，让客服第一时间知道该申请何种方式的退款，从而向用户要全需要操作的信息。

具体见下面解释：

我们以用户用支付宝购买会员为例，没记错的话退款应该是走这个接口（trade.refund 统一收单交易退款接口），这个接口明确说明了：“当交易发生之后一段时间内，由于买家或者卖家的原因需要退款时，卖家可以通过退款接口将支付款退还给买家，支付宝将在收到退款请求并且验证成功之后，按照退款规则将支付款按原路退到买家帐号上；交易超过约定时间（签约时设置的可退款时间）的订单无法进行退款支付宝退款支持单笔交易分多次退款，多次退款需要提交原支付订单的商户订单号和设置不同的退款单号。一笔退款失败后重新提交，要采用原来的退款单号。总退款金额不能超过用户实际支付金额”；意思就是在交易产生后的一定时间内，是可以走退款接口申请退款的，退款回原路返回，并且同一笔订单可以申请多次退款。

为什么支付宝要要求在一定时间内，因为人家也是有结算账期的，不能让收入挂在那一年半载的等着你来操作退款吧；像这种能够正常退的，我们可以原路退回还不麻烦，但是像特殊渠道或者是超时的，就要通过特殊方法执行了。

特殊方法怎么走呢？就是需要“客服”人工向用户要企业所支持的退款渠道的账号了，这样手动录入一条退款申请；而支付的时候如果是支付宝，后面可以设计走批量转账的接口完成支付，这是“特殊”的流程。

2）【后台改变用户属性暂停用户会员权益】：“客服”操作了退款申请后，即需要冻结用户的会员权益，这里要注意的是如果支持按天退款，那么记录中需要将用户要退的天数记录下来。

因为一旦被拒绝，就要按照申请退款的天数再加回会员天数，加回的时候，还要同步设置对应会员卡购买记录中记录的会员有效时间；这一点很隐蔽，是为了考虑多次申请退款时避免会员卡状态和会员卡购买记录匹配不起来。

3）【同意与打款-原路退回/特殊】：这里是两个步骤，审批环节主要是根据客服提交的情况进行审批，主要讲一下退款操作，原路退回不多赘述了。

如果是特殊退款，例如登记用户支付宝账号的退款，可以通过支付宝批量转账的接口实现退款（alipay.fund.trans.uni.transfer 单笔转账接口），如果是其他没有接口的支付渠道就不建议了；一是资金安全问题，二是实在没必要再为此单独设计流程了（然后就是打款失败的场景我们也暂时不考虑了，只需要保留一个修改打款信息的功能，并返回审核即可）；同意之后，推送消息给到用户。

支付宝API截图：

产品经理，产品经理网站