編輯導語：訂閲制，主要通過按月扣款來完成交易。如果消費者不主動取消，則默認服務繼續。它為消費者提供的是週期性服務，老用户每個月都會連續消費，為產品帶來收入，所以有人説訂閲制是一種“連續賺錢”的模式。基於此，訂閲制的後台設計我們應該怎麼做呢？
訂閲制（Subscription Model），是一種為消費者提供週期性服務的商業模式。
常用於軟件或服務廠商，比如愛奇藝提供月卡、季卡、年卡的會員視頻內容服務，Adobe 提供年付的軟件使用服務等等所有按週期對使用權進行付費的產品都稱得上是「訂閲制」。
本文不探討訂閲制的優勢及演變過程，只介紹對於 SaaS 廠商使用的訂閲制的後台設計，其中絕大部分設計參考了優秀的計費 SaaS 產品的設計邏輯，如：Recruly,Chargebee,Baremetrics。
一、產品目錄（Product Catalog）首先，SaaS 產品需要有可售賣的產品，通常包含以下三種類型。
1. 基準產品（Basic）我們一般會把多個付費功能打包為一個基準產品，基準產品只是描述它包含的付費功能，並不包含訂閲週期，因此基準產品在這裏是沒有定價的。
在愛奇藝的例子中，它的基準產品有：黃金會員（提供在手機和 iPad 上觀看會員視頻）、星鑽會員（提供在手機、 iPad 、電視上觀看會員視頻），這是兩個不同的基準產品。
在 SaaS 廠商通常定義一些付費功能為某個付費版本，比如在 Figma 中，分為免費版、專業版、團隊版。在黑帕雲中，分為免費版、標準版、專業版。不同的版本包含的功能不同。
2. 增量產品（Addons）增量產品一般跟隨基準產品，比如電信運營商的 300Mb 流量包、100 分鐘通話時長等等都屬於增量產品。它們的特點是也是按週期付費，同樣的，單純的增量產品沒有自己的定價，需要和付款週期一起定價。
通常發生在你購買的基準產品不能滿足使用需求，可以通過購買增量產品追加。並且下個付費週期可以繼續訂閲這個增量產品。
3. 一次性產品（One-time）一次性產品和一錘子買賣的「買賣制」一樣，支付後，商品即屬於消費者，所以一次性產品通常是一次性付費。
它可以跟隨基準產品也可以不跟隨基準產品，與增量產品的最大區別是，一次性產品沒有訂閲週期。也就是説，下個訂閲週期不會再繼續將一次性產品計入付費。比如愛奇藝的超前點播、播放券，支付完成視為交易完成。
二、套餐（Plan）套餐至少是由「售賣的產品」+「付費週期」組成。也就是説，相同的付費週期不同的產品、相同的產品不同的付費週期都是不同的套餐。如月付標準版和年付標準版就是兩個套餐。
套餐可以根據產品類型分為基準套餐和增量套餐。比如基準產品+月付則可以組成一個基準套餐，增量產品+月付可以組成一個增量套餐。在一些官網的套餐中通常指的就是基準套餐。
前文所述，基準產品和增量產品是沒有定價的，而套餐才有定價。因為這二者都是訂閲模式，所以需要在付費週期的基礎上才有定價。
三、價格模型（Price Model）價格模型主要用於描述收費的方式，套餐可以以不同的價格模型進行售賣。
1. 單位計費 （Per unit）單位計費是週期性按單位計費的價格模型，很多 SaaS 產品套餐都按席位為單位進行銷售。企業可以按需購買即在購買套餐時需要選擇購買的席位數量，需要增加席位時，再為這些席位繼續購買基準套餐。
以單位計費售賣的套餐（黑帕雲）
2. 固定費用（Flat fee）固定費用是週期性固定收費的價格模型，這個價格模型中已經包含了單位。比如所購買的套餐中已經包含了席位數，如「100 人的年付高級版」指的就是固定費用。如果需要增加席位，則可以以增量套餐的形式進行購買。
同樣的，因為已經標定了單位，所以對於增量套餐的價格模型也是固定費用。
以固定費用售賣的套餐（語雀）
3. 用量計費（Volume）用量計費只按單位計費（無週期性），並且可以將單位價格取決於總數量的範圍。在這種模式下，我們需要定義數量範圍和每個單位的價格。
一次性產品的價格模型通常是「用量計費」，比如購買一張觀影券時，每張單價是 6 元，購買 3 張觀影券時，每張價格是 5.5 元。
四、訂閲（Subscription）當一個團隊購買了某個基準套餐後，就會生成一個訂閲，增量套餐會跟隨基準套餐，一般描述一個團隊的訂閲的套餐信息。無論基準套餐還是增量套餐，訂閲狀態都包含三種狀態。
1. 活躍（Active）當前套餐生效中，那麼這個訂閲的狀態就是活躍。
2. 未續費（Unpaid）套餐到期即為未續費，如果套餐過期後，再進行續費，訂閲從「未續費」更改為「終止」，那麼會新創建該團隊訂閲，生效日期為訂閲開始日期。
這裏未續費狀態存在的原因主要是為了計算流失率，如果一個團隊狀態已變成未續費，則視為這個團隊流失。
3. 終止（Cancel）更換訂閲視為終止當前訂閲，比如團隊從月份套餐更換為年付套餐，那麼當前的月份套餐就被終止了。此時也會生成新的訂閲。
所以有了以上的狀態，對於訂閲而言，一個團隊某天只對應一個訂閲。
五、支付與退貨（Revenue&Credit Notes）所有的支付與退貨都以訂閲進行計算。比如在計算某個訂閲支付時，當前套餐價格*購買數量即可計算出需要支付的金額。退貨也是一樣的，根據當前訂閲已支付的金額和剩餘有效期計算需要支付給用户的金額或其他等價物（如優惠券）。
這樣設計就能夠通過支付或退貨控制團隊的訂閲狀態，每一次的訂閲修改都與支付或退貨記錄有關，這非常利於財務的工作。
六、發票&税（Invoice&Tax）用户發生了支付行為後，作為 SaaS 廠商則需要給用户提供發票。
正常的開票邏輯都很好理解，就是用户支付的金額已經包含了税，税的部分是由我們來交。所以這時候如果用户想要退貨時，在計算退款時需要操作是否退税。如果這個支付訂單已經開票了，那在退款時就需要扣除税後再計算退款。
本文對於訂閲制的後台設計為筆者本人的理解，僅供參考。如有錯誤，煩請指正，感謝閲讀。
作者：colA，公眾號：babykoala與產品設計
本文由 @babykoala 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議