编辑导语:订阅制，主要通过每月扣款来完成交易。如果消费者不主动取消，默认服务继续。它为消费者提供周期性服务，老用户每个月都会持续消费，为产品带来收入，所以有人说订阅制是一种“持续赚钱”的模式。基于此，订阅系统的后台设计应该怎么做？
订阅制是一种为消费者提供周期性服务的商业模式。
常用于软件或服务厂商，如爱奇艺的月度、季度、年度会员视频内容服务，Adobe的年度软件使用服务等。所有按周期支付使用权的产品都可以称为“订阅制”。
本文不讨论订阅系统的优势和演进，只介绍SaaS厂商使用的订阅系统的后台设计，大部分参考了优秀计费SaaS产品的设计逻辑，如Recruly、Chargebee、Baremetrics等。
一、产品目录
首先，SaaS产品需要有适销对路的产品，通常包括以下三种。
1.基准产品
一般情况下，我们会将多个付费功能打包到一个基准产品中。基准产品只描述其包含的付费功能，不包括订阅期。因此，这里不对基准产品进行定价。
以爱奇艺为例，其对标产品为:黄金会员和星钻会员，是两种不同的对标产品。
SaaS厂商通常将一些付费功能定义为付费版本。比如在Figma，有免费版，专业版，团队版。在黑帕云，分为免费版、标准版和专业版。不同版本的包含不同的功能。
2.增量产品
增量产品一般沿用基准产品，如300Mb流量包、100分钟通话时长等。电信运营商的都是增量产品。它们的特点是定期付款。同样，简单的增量产品也没有自己的定价，需要和支付周期一起定价。
一般发生在你买的基准产品不能满足使用需求的时候，可以通过购买增量产品来补充。并且可以在下一个支付周期继续订阅这个增量产品。
3.一次性产品
一次性产品和一锤子买卖的“买卖制”是一样的。付款后商品属于消费者，所以一次性产品一般一次性付款。
可以跟随基准产品，也可以不跟随。与增量产品最大的区别是，一次性产品没有认购期。也就是说，下一个订阅周期不会继续将一次性产品纳入付费。比如爱奇艺的提前点播和播放券，支付完成视为交易完成。
第二，包装
至少套餐由“待售产品”和“付款期”组成。换句话说，付款周期相同的产品，同一产品付款周期不同的，都是不同的套餐。比如月标版和年标版就是两个套餐。
根据产品类型，包可以分为基本包和增量包。比如基准产品+月供可以形成基准套餐，增量产品+月供可以形成增量套餐。官网有些包通常指的是基准包。
如上所述，基准产品和增量产品不定价，套餐产品定价。因为两者都是订阅模式，需要以付费周期为基础定价。
第三，价格模型
价格模型主要用于描述计费方式。套装可以以不同的价格模式出售。
1.单位计费
单位计费是一种周期性单位计费的价格模型，许多SaaS产品包都是按座位销售的。企业可以按需购买，即在购买套餐时需要选择购买的席位数，当需要增加席位时，会继续购买这些席位的基准套餐。
按单位出售的包装。
2.固定费
固定费用是周期固定费用的价格模型，已经包含了单位。比如座位数已经包含在购买的套餐里了。例如，“100人年度高级版”指的是固定费用。如果需要增加席位，可以采用增量套餐的形式购买。
同样，因为单位已经校准，所以增量套餐的价格模式也是固定费用。
以固定价格出售的套装
3.使用计费
使用量只按单位收费，单价可以取决于总量的范围。在这种模式下，我们需要定义数量范围和每个单位的价格。
一次性产品的价格模式通常是“按使用量计费”。比如买一张电影票，每张票的单价是6元，买三张电影票，每张票的价格是5.5元。
四。签署
一个团队购买一个基准包，就会生成一个订阅，增量包会跟随基准包，一般描述一个团队订阅的包信息。无论是基础套餐还是增量套餐，订阅状态都包括三种状态。
1.活跃的
当前订阅有效，因此该订阅的状态为活动。
2.不续约
订阅到期后不再续订。如果在订阅到期后续订，并且订阅从“未续订”更改为“已终止”，则新创建团队订阅，生效日期为订阅开始日期。
这里之所以存在不续费状态，主要是为了计算流失率。如果一个团队的状态变成了不续约，这将被视为团队流失。
3.结束
变更认购被视为终止当前认购。比如团队从包月改为包年，当前的包月将被终止。还将生成新的订阅。
所以有了上面的状态，对于订阅来说，一个团队一天只对应一个订阅。
动词 （verb的缩写）付款和退货
的所有支付和回报都是通过订阅计算的。例如，在计算订阅付款时，当前套餐价格*购买数量可以计算出要支付的金额。退货也是如此。根据当前订购的已付金额和剩余有效期来计算要向用户支付的金额或其他等价物。
这样设计可以通过付款或退货来控制团队的订阅状态，每一次订阅修改都与付款或退货记录相关，对财务工作非常有利。
不及物动词发票和税收
用户付款后，SaaS供应商需要向用户提供发票。
正常的开票逻辑很好理解，就是用户支付的金额已经含税，税是我们交的。所以，这个时候如果用户想要退货，就需要在计算退税的时候操作是否退税。如果此支付订单已经开具发票，将在扣除税款后计算退款。
本文订阅系统的后台设计是我自己的理解，仅供参考。如有错误，请指正。感谢您的阅读。
本文由@babykoala原创发布。每个人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
