谈会员卡系统的产品设计

　　本文从会员卡生命周期的主要流程说起，然后再谈会员卡相关的基本逻辑的思考，最后介绍一套基本的会员卡管理系统模块和整体流程，希望对你有所帮助。
　　作为一种大家喜闻乐见的营销手段，会员卡可谓历史悠久。据说在17世纪的欧洲就有贵族将会员制度作为身份和地位象征，用于彰显和平民不同的特权。到了现代社会，这种手法更是被各大公司发扬广大。其中最知名的当属美国运通的“黑金卡”，此卡的神通被各种书籍、报道和传闻神化，包括高得令人惊悚的额度、专属服务和顶级权益等等。
　　到了互联网时代，会员卡更是被各大电商所用，但凡是面向广大用户做销售的公司都喜欢来一套会员制度。但是会员卡本身的系统化并不是一件简单的事情。相反，作为各个公司内部与各大主要系统联系紧密的系统之一，获知会员卡系统的产品设计那是相当的困难（不信找谷歌度娘问啊，哈哈哈）。这就是本文价值所在了，本汪将从会员卡生命周期的主要流程说起，然后再谈会员卡相关的基本逻辑的思考，最后介绍一套基本的会员卡管理系统模块和整体流程。
　　会员卡本身是一个庞大而复杂的系统，本文仅从互联网产品的视角来分析，涉及到会员积分、等级、权益相关的话题也不谈论，秉持本汪一贯的只讲思路不讲细节、只画流程图和逻辑图不画界面原型的原则。但是，对于有需要的同行，绝壁是有参考价值的（得意脸，）。
　　一、会员卡的生命周期和流程
　　整体的流程见下图，不同类型的业务和形态会有不同。
　　在创建卡种的阶段，需要将卡的名称、覆盖的业务范围、各种卡的权益理清楚。在国内最常见的卡名称就是“金卡”、“银卡”、“铜卡”了，可谓简单粗暴，大家一听就知道谁高谁低谁牛逼。跟名字相对应的是使用范围和权益，这个也好理解，名字牛逼的自然覆盖的范围更大、有更多的权益。至于如何通过数值设计来划分不同等级，使不同等级的会员有不同的权益，以及如何更好地引导会员在平台上购买更多商品不是本文的主题，且不谈。
　　分配号段和制卡主要用于有多个地区的业务，更多的是出现在实体卡上。
　　举个类似的栗子，大家去查询手机号码时能查到归属地区，就是因为运营商对号段做了区分，如此一来就能跟踪到不同省公司、不同地级市级公司的发卡情况，也能一定程度上限制部分地区发行高优惠的卡流入其他地区（锅是谁的一查就知道）。
　　对于互联网业务来说，对于号段的需求并不强烈，往往是系统自动给每张卡分配一个ID就完事了。就制卡而言，也是线下零售业使用的情况偏多，线上的业务也往往没有这个需求，为啥呢？因为太！麻！烦！制卡需要找供应商，如果公司业务分了总部和各地区分部（或门店）那么制完卡后，还得把会员卡通过物流发送给下属机构，那么谁来寄送、找什么物流公司承运、谁来接收卡片、寄丢了是不是要补寄、分部急着用不能及时寄到时怎么办、分部收到卡号后怎么清点、发现卡少了如何处理等等一系列的坑实在太多。
　　您或许会说，那就分部（或门店）自己找供应商制作！OK，这就好比中央把印钞的权利下放到里地方！如何保证这么多供应商能达到相同的品质（比如一批会员卡1年就废了80，另一批会员卡3年才废30），怎么限制下属机构胡乱制卡，怎样保证每一张发出去的卡都到有效用户手上又是各种坑。
　　到了与用户流程相关的发卡、充值、消费、重新发卡、冻结卡片等，是日常生活中就能感受到的，只稍微提几句。首先是发卡和充值，有些业务场景下将发卡量、充值金额与下属机构的业绩相关联，那么需要在发生这两项业务时记录下操作机构和操作人。其次是这几个流程节点中需要获取用户的会员卡号和用户身份信息。对于多数互联网线上业务来说都不是问题，用户的所有操作记录和逻辑都在线上。但是对于线下的实体卡片又双叒叕麻烦了，是用户自己报手机号会员号，还是用机器刷卡，如果是刷卡的话用NFC、磁条还是扫二维码，确定一种方式后用什么机器和系统来实现等等。
　　二、线上会员卡基本逻辑的考虑
　　关于实体卡在前面说了很多，线下的部分在后面就不继续说了。其实不论是实体卡还是电子卡都需要系统支撑，这部分才是文章的关键。
　　说起会员卡，首先就需要明确卡内是否储值以及会员折扣相关的问题。会员卡储值本身就是一个涉及到金融管制的复杂的问题，如果按照正规的方式走，需要申请相关的金融发卡资质，不然就有非法集资的嫌疑。不过国内互联网野蛮生长，除非规模巨大的几家，其余的都在打擦边球。比如去年闹得沸沸扬扬的OFO、摩拜的用户保证金和充值问题，虽然金融监管机构三令五申，也不见两家申请金融牌照，不过从网上的相关新闻来看还是被逼着找了银行做资金托管。如果不储值，则只是作为用户身份的象征，给予不同等级的会员不同的特权。其中的一种特权也是最常见、与业务最相关的就是折扣。当出现多种业务时，折扣与之交叉会出现不同等级在办理不同业务时享受不同折扣的情况。
　　关于折扣卡的发行逻辑，在第一部分有涉及线下相关的流程。除了各种坑之外，线下渠道也有优势的一面，特别是现在线上获客成本高企、大家都在玩“新零售”的情况下更是如此。推广人员在线下直接触达目标用户并实现转化，在有些情况下（比如线下门店）的成本比线上低的多，近期北京各个物美超市推的“多点”App就是个例证（当然，他们主推App，在App中注册即会员）。为了能应对多种推广场景，就需要考虑线上、线下的发行渠道和方式。线上渠道即可以通过合作网站调用接口实现绑卡，也可以用人工运营的方式将兑换码与账户绑定；线下渠道则是实体卡和兑换码，比如将兑换码打印在卡上，目标用户在App上兑换成会员卡。
　　会员卡的使用过程中会出现各种情况，这里仅对几种常见的需要考虑的问题做说明。
　　首先是支付和折扣，用户使用会员卡的目的要么为了获得会员积分、提升会员等级，要么是为了享受会员折扣。那么就需要考虑是否部分商品只能由会员购买，是否需要会员价格和非会员价格。同样是会员价格，不同等级的会员是否享受差异化的权益（赠品不同、积分不同、服务通道不同等）。
　　其次是充值。会员卡能否反复充值，还是只作为储值卡，消耗完只能买新卡？之所以需要考虑这个问题，还是不同等级会员享有不同权益造成的。举个例子，5000元的储值卡可以享受7折，3000元的储值卡只能享受8折，如果可以对同一张卡反复充值，则购买了5000元储值卡的会员将一直享受7折（后续充值小于或者大于5000，在机制上都可以设计）。所以，如果会员折扣体系仅建立在卡面值上，则反复充值的方式不合理；如果还有其它体系（例如积分等）作为支撑，则可以。
　　多卡共用与上一个问题相似，都涉及到不同等级权益，举例说如果一笔付款使用了两张不同等级的储值卡，那么该以哪个折扣为准呢？
　　卡券共用是从营销上考虑的，没有明确的标准，机制依业务逻辑的需要而变。如果业务需要大规模推广拉来更多新用户，就可能允许卡券同时使用；如果用户到了一定量级，需要控制营销成本，则有可能不允许卡券共用。如果允许卡券共用，还得对成本再进一步做精细化计算：先扣券再折扣和先折扣后扣券产生的实付金额是不同，要根据不同的折扣额度、不同的优惠券额度和规则及客单价进行核算，才能知道哪种方式对当前的推广更有利。
　　最后是余额不足的情况如何处理，用户是否可以使用多种方式支付一笔订单就是个非常头疼的问题，不但前端App和网站上的交互不好处理，后端支付系统的设计也不简单。如果可以一单多支付方式，那么是否依然整体享受会员卡折扣，用其它方式补足余款？如果不能一单多付，那么余额不足时是不能使用会员卡支付的。
　　三、会员卡系统模块和流程介绍
　　以上这套是适合O2O业务使用的会员卡系统使用的流程。
　　首先需要创建卡种类，对卡的名称、面值、有效期及各种权益进行配置，完成配置后生成会员卡商品。对折扣和权益多补充一句，不同省份、地区因为物价水平不同，相同等级的卡可能会存在不同权益的情况，需要提前考虑到。例如，一款咖啡在上海售价是100元，在拉萨的售价可能是80元，是否同样都享受8折就需要从业务上进行考虑了。
　　与创建卡种类平行的流程是创建会员卡的发行渠道。就会员卡的场景来说，渠道管理模块本身无需太复杂，但是从营销成本来考量有必要做到细致准确，只有这样才能看出哪个渠道效果最好。此外，某些渠道对于使用会员卡可能会有特殊的要求。举例来说，为了推广App，把会员卡的折扣资源向这个渠道做倾斜；某些渠道出售的会员卡不能和优惠券叠加使用。
　　当生成了会员卡种类和销售渠道后，需要对会员卡生成发行批次。根据业务的复杂程度，有可能每个批次的会员卡售价、有效期、限售数量、适用的地区都不同。不同的批次需要不同的发行方式，有些批次放在淘宝上售卖，有些批次是地推，而有些批次是与便利店合作推广等等。对于线上出售的会员卡，通过接口调用实现系统自动绑卡是比较节省人工的方式；而通过兑换码发行的卡，要么是运营人员手工使用绑卡工具将卡与账户做绑定，要么是调取后台接口批量做绑定。
　　一旦绑定会员卡，则所有使用会员产生的消费记录都应该与卡做关联，便于监控卡的使用情况。
　　需要特别说明的是，如果会员卡储值，则需要在流程中特别注意业务、运营、财务、法务的角色分工。举例来说，每一个卡种都需要策略部门精心核算；每一个批次的发行都需要市场运营部门、财务部门审批，否则一旦出现资金问题，是没人能背得起这个锅的。
　　整体而言，系统本身的流程并不复杂，复杂的是如何更好地与业务相结合起来，做到以最简单、明了、便捷的方式支持业务；此外，因会员卡本身的价值属性，系统会与用户CRM系统、权限管理系统、财务系统、营销系统、订单系统、BI系统产生关联。
　　四、结语
　　笔者从毕业后第一份工作开始接触会员卡，从实体卡到电子卡，从权益卡到储值卡都有过些接触和了解，深知其中的坑是多么难填。但凡涉及到企业资金流动和使用的，必然牵扯到企业财务的制度和流程，一旦牵扯到财务，大部分产品经理都得懵逼。
　　所幸，这几年的工作见识的多了就能更从容地处理产品和业务之间的关系了。能读到这里的读者大概是被逼无奈了（哈哈哈），在业务层面上多做些考虑，划分几个主要的使用场景，再理清系统流程，然后再从流程中脱离出来将整个系统划分成各个模块。当业务流程、使用场景和后台的流程都考虑清楚了，再处理前台的交互和展示，这算是笔者的一点经验，与有需要的读者分享。