編輯導語：如今一些企業會開發服務的平台，對於這些平台，一些產品的服務會產生收費的模式和標準，根據不同的年月日等規定進行計費；本文作者分享了關於企業服務平台中的交易模式——計費結算的設計，我們一起來看一下。
企業服務項目，產品策劃分為兩部分。
本系列主要講技術服務開放平台的產品策劃怎麼做，對企業服務產品感興趣的可以來看看。
上一章，我們講了產品和平台用户，這一章，我們主要講交易：計費&結算。
一、核心交易流程簡述首先，我們來捋一下一次交易的過程，看看核心操作有哪些？
1. 生產產品——>定價根據產品不同服務形式（產品類型）確定計費模式，一般是按量收費，需要確定計量項（最小計費單位）和單價。
如API按調用次數/按QPS每天計費；SDK按永久授權終端設備數量計費；獨立部署按年收費等，然後單價可能有默認價格和優惠價格。
2. BD找到客户——>報價——>提供免費測試創建客户賬號，並配置該產品有限期內有限次數免費調用。
客户進行測試。
3. 簽訂合同，分配資源測試通過，正式合作，BD與客户確定付費模式，預付費或後付費。
預付費一般為包年包月的購買形式，需要預先確認購買資源量；資源包購買後，即將相關資源分配給用户，直到過期失效。
後付費，即先使用，後付費，在結算時按實際使用量計費，需要確定結算週期，一般按日/月結算。
4. 客户消費客户調用API，或者使用SDK，系統搜索該客户該產品的訂單列表（可能同時有多個訂單），根據特定策略篩選出訂單，如果該訂單是預付費的資源包，則需判斷剩餘資源數量是否足夠；如是後付費方式，則進行累計計費。
5. 對賬結算預付費模式，下單完成後就生成賬單；賬單支付後，才分配資源。
後付費，到達結算週期時，生成賬單，並提供用量明細；使用資源後，才支付。
總結如上圖，通過對核心流程的梳理，我們對交易系統的認知開始有了輪廓。
二、功能模塊設計基於上述的輪廓，我們繼續思考系統的核心功能模塊設計。
我們根據是否生成賬單，劃分為兩大塊：計費和結算。
1. 計費概念：按照計費規則計算出單個產品要收取的費用，並且按照結算週期聚合所有服務的計費明細 生成賬單。
企業服務的計費模式一般分為預付費和後付費。
1）預付費
一般就是包年包月的購買形式：客户可根據自身對資源的使用需求選擇資源包，下單完成後會生成賬單。要注意資源到期提醒或者欠費預警。
2）後付費
指的是先使用後付費，在到達結算周可期時，生成賬單的計費模式。客户需要在約定時間內完成繳費；也涉及欠費管理。這種方式，對客户方來説，用多少付多少，沒有資源浪費，更靈活。
對還處在發展早期的平台更適合，或者客户是大客户，議價權較強的時候，一般都是後付費。流程如下：
3）配置計費規則
這個模塊既要支持配置資源包，也要支持後付費的計費規則。
①資源包
配置資源包的有效期起止時間，計量項，總量，以及分配規則和結轉規則。根據分配規則和結轉規則可分為「按月分配不結轉/按月分配可結轉/一次性分配不結轉/一次性分配可結轉」，影響下發和抵扣。
②後付費計費規則
- 計費規則主要是根據產品的服務形式確認計費週期，最小計費單位（計量項），以及單價。
- 算法：需要支持階梯式算法，即時間窗口內用得越多單價越便宜。
要注意，在設計這一模塊的時候，儘可能高度抽象，以保證靈活度。因為To B業務，客户是甲方爸爸，客户可能會提出其他的計費規則，也需要我們系統能支持。這裏可以考慮留一個口子，讓銷售人員或者運營人員手工錄入。（手工錄入或者是價格管理，優惠管理這一塊，都會涉及到審批流管理模塊設計，這裏不額外展開）
4）優惠管理
支持運營配置優惠方案，如優惠券等。
5）計費順序策略
客户使用同一產品，可能同時既有免費額度，也購買了預付費資源包或按量付費 ，這就涉及到計費順序的問題，也需要先確認好；比如：預付費QPS>預付費資源包>免費額度>按量付費。
如果購買了多個資源包，抵扣順序可以是從已購買的次數包中按照購買時間順序由早至晚，按照規格由小至大依次扣除相應次數。
6）到期提醒/欠費預警
資源包到期前/資源包即將用完/後付費觸發授信額度，需要提醒用户續費，否則將停止服務。一是以郵件、短信、站內信的方式推送給客户。二是通知負責該客户的銷售，銷售通過線下的方式推動客户。
2. 結算概念：對賬及發生實際的資金流轉。
1）結算觸發規則
預付費：是下單購買時就會立刻觸發結算，生成賬單，發給客户確認，無誤後，就會向客户提供發票，對方支付後，就會下發對應的資源到對方賬户上。
後付費：到達結算週期，觸發結算，聚和賬單，發給客户確認，無誤後，提供發票，對方支付。
2）聚合賬單
企業客户可能有多個子賬號。有幾種方式。
- 子賬號不單獨計費；子賬號使用主賬號的資源或使用量記在主賬號上。由主賬號負責結算。
- 子賬號單獨計費；預付費時，主賬號涉及資源分配。由主賬號負責結算。
- 子賬號單獨計費，獨立結算；一般是組織架構複雜的集團，要求子公司財務獨立核算。
3）對賬
賬單生成後，可能會因為業務上的一些問題需要調整。
4）付款
企業服務，不面向個人開發者時，一般都是線下對公匯款。預付費，匯款完成，即下發對應資源。後付費，匯款完成，即與賬單對應的計費流水進行核銷。
5）欠費管理
如果是預付費，購買時立即支付的方式；當客户的資源包已經用完，就會進入欠費流程，但是一般不會直接停服；超出資源包的部分可以以按後付費的方式結算，這裏就需要有一個欠費授信管理的策略，需要結合客户的風險程度，設置一個欠費額度上限。超過上限後，再進入下一步：停服。
如果是後付費，那企業客户一般有賬期，比如下個月初結算上個自然月的帳，對賬完成後，客户在30天內支付完成即可；那這個賬期內，也是不停服的，同意需要授信管理策略，超過上限後，則停止服務；後付費，還有一種減少欠費的方式，即客户使用前先要求對方充值一定的資金用以凍結，使用後再結算，不過一般是大廠才（敢）這麼做。
三、業務數據模型大框架，頂層設計有了，我們可以提煉出來業務過程中關鍵對象的關係，進而抽象出底層的業務數據模型。
只有業務數據模型清楚了，正確了，建立在這之上的更細節的業務邏輯，流程，功能設計才會清晰無誤；且數據模型的設計會影響到數據庫表結構，字段的設計，是產品設計的根基，是設計之初就要想清楚的事情。
我之前的文章也提過，從項目的完整生命週期來看，數據表結構決定了拓展性；上線後，如果要改底層的數據表結構，成本會很高。
以計費流程為例，關鍵對象有：客户、賬號、產品、訂單、賬單、計費模式、計量項、單價、計量（使用量）。
這些對象的關係是什麼樣的呢？我們用ER圖來梳理一下。
簡單介紹一下ER圖：
ER圖概念：ER模型，全稱為實體聯繫模型、實體關係模型或實體聯繫模式圖（Entity Relationship Diagram），提供了表示實體類型、屬性和聯繫的方法，用來描述現實世界的概念模型， 它是描述現實體對象之間關聯關係經典方法。
ER圖三個核心要素：
- 實體：表示一個對象，可以被（粗略地）認為是名詞，比如會員，優惠券，公司
- 屬性：對象所具有的屬性，特性。比如會員可以有暱稱，生日，註冊時間等屬性
- 關係：表示對象與對象之間的聯繫。比如老師這個對象和學生的實體之間的聯繫。
ER圖中關聯關係有三種：
- 1對1 ：指實體集A與實體集B，A中的每一個實體至多與B中一個實體有關係；反之亦然。
- 1對多：指實體集A中的每一個實體與B中至少有1個以上的實體有關係；且B中每一個實體至多與A中一個實體有關係。
- 多對多 ：指A中的每一個實體與B中至少有1個以上的實體有關係；反之亦然。
一般來説，我們設計的時候，如非必要，儘量避免多對多的關聯關係。
這裏只是簡單介紹對ER圖感興趣的同學，可以自行搜索瞭解更多；另外説一點，ER圖的呈現方式很多，產品不必拘泥於某一個特定形式，描述清楚對象和關係即可。
關於數據，安全，請看下一次更新。
作者：石青；微信公眾號：石青自習室
本文由 @石青 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 unsplash，基於 CC0 協議