订阅制后台的模型设计
订阅制（Subscription Model）是一种为消费者提供周期性服务的商业模式。常用于软件或服务厂商，比如爱奇艺提供月卡、季卡、年卡的会员视频内容服务，Adobe 提供年付的软件使用服务等等所有按周期对使用权进行付费的产品都称得上是「订阅制」。
本文不探讨订阅制的优势及演变过程，只介绍对于 SaaS 厂商使用的订阅制的后台设计。
其中绝大部分设计参考了优秀的计费 SaaS 的产品设计逻辑。
如：Recruly,Chargebee,Baremetrics。
01 产品目录（Product Catalog）
首先，SaaS 产品需要有可售卖的产品，通常包含以下三种类型。
基准产品（Basic）
我们一般会把多个付费功能打包为一个基准产品，基准产品只是描述它包含的付费功能，并不包含订阅周期，因此基准产品在这里是没有定价的。
在爱奇艺的例子中，它的基准产品有：黄金会员（提供在手机和 iPad 上观看会员视频）、星钻会员（提供在手机、 iPad 、电视上观看会员视频），这是两个不同的基准产品。
在 SaaS 厂商通常定义一些付费功能为某个付费版本，比如在 Figma 中，分为免费版、专业版、团队版。在黑帕云中，分为免费版、标准版、专业版。不同的版本包含的功能不同。
增量产品（Addons）
增量产品一般跟随基准产品，比如电信运营商的 300Mb 流量包、100 分钟通话时长等等都属于增量产品。
它们的特点是也是按周期付费，同样的，单纯的增量产品没有自己的定价，需要和付款周期一起定价。
通常发生在你购买的基准产品不能满足使用需求，可以通过购买增量产品追加。并且下个付费周期可以继续订阅这个增量产品。
一次性产品（One-time）
一次性产品和一锤子买卖的「买卖制」一样，支付后，商品即属于消费者，所以一次性产品通常是一次性付费。
它可以跟随基准产品也可以不跟随基准产品，与增量产品的最大区别是，一次性产品没有订阅周期。也就是说，下个订阅周期不会再继续将一次性产品计入付费。比如爱奇艺的超前点播、播放券，支付完成视为交易完成。
02 套餐（Plan）
套餐至少是由「售卖的产品」+「付费周期」组成。也就是说，相同的付费周期不同的产品、相同的产品不同的付费周期都是不同的套餐。如月付标准版和年付标准版就是两个套餐。
套餐可以根据产品类型分为基准套餐和增量套餐。比如基准产品+月付则可以组成一个基准套餐，增量产品+月付可以组成一个增量套餐。在一些官网的套餐中通常指的就是基准套餐。
前文所述，基准产品和增量产品是没有定价的，而套餐才有定价。因为这二者都是订阅模式，所以需要在付费周期的基础上才有定价。
03 价格模型（Price Model ）
价格模型主要用于描述收费的方式，套餐可以以不同的价格模型进行售卖。
单位计费 （Per unit）
单位计费是周期性按单位计费的价格模型。
很多 SaaS 产品套餐都按席位为单位进行销售。企业可以按需购买即在购买套餐时需要选择购买的席位数量，需要增加席位时，再为这些席位继续购买基准套餐。
以单位计费售卖的套餐（黑帕云）
固定费用（Flat fee）
固定费用是周期性固定收费的价格模型，这个价格模型中已经包含了单位。
比如所购买的套餐中已经包含了席位数，如「100 人的年付高级版」指的就是固定费用。如果需要增加席位，则可以以增量套餐的形式进行购买。
同样的，因为已经标定了单位，所以对于增量套餐的价格模型也是固定费用。
以固定费用售卖的套餐（语雀）
用量计费（Volume）
用量计费只按单位计费（无周期性）。并且可以将单位价格取决于总数量的范围。在这种模式下，我们需要定义数量范围和每个单位的价格。
一次性产品的价格模型通常是「用量计费」。比如购买一张观影券时，每张单价是 6 元，购买 3 张观影券时，每张价格是 5.5 元。
04 订阅（Subscription）
当一个团队购买了某个基准套餐后，就会生成一个订阅，增量套餐会跟随基准套餐。一般描述一个团队的订阅的套餐信息。
无论基准套餐还是增量套餐，订阅状态都包含三种状态。
活跃（Active）
当前套餐生效中，那么这个订阅的状态就是活跃。
未续费（Unpaid）
套餐到期即为未续费。
如果套餐过期后，再进行续费，订阅从「未续费」更改为「终止」，那么会新创建该团队订阅，生效日期为订阅开始日期。
这里未续费状态存在的原因主要是为了计算流失率，如果一个团队状态已变成未续费，则视为这个团队流失。
终止（Cancel）
更换订阅视为终止当前订阅。
比如团队从月份套餐更换为年付套餐，那么当前的月份套餐就被终止了。此时也会生成新的订阅。
所以有了以上的状态，对于订阅而言，一个团队某天只对应一个订阅。
05 支付与退货（Revenue& Credit Notes）
所有的支付与退货都以订阅进行计算。比如在计算某个订阅支付时，当前套餐价格*购买数量即可计算出需要支付的金额。
退货也是一样的，根据当前订阅已支付的金额和剩余有效期计算需要支付给用户的金额或其他等价物（如优惠券）。
这样设计就能够通过支付或退货控制团队的订阅状态，每一次的订阅修改都与支付或退货记录有关，这非常利于财务的工作。
06 发票&税（Invoice&Tax）
用户发生了支付行为后，作为 SaaS 厂商则需要给用户提供发票。
正常的开票逻辑都很好理解，就是用户支付的金额已经包含了税，税的部分是由我们来交。所以这时候如果用户想要退货时，在计算退款时需要操作是否退税。如果这个支付订单已经开票了，那在退款时就需要扣除税后再计算退款。
本文对于订阅制的后台设计为笔者本人的理解，仅供参考。如有错误，烦请指正。
感谢阅读。