起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識企業服務（云服務）平臺：計費結算
編輯導語：如今一些企業會開發服務的平臺，對于這些平臺，一些產品的服務會產生收費的模式和標準，根據不同的年月日等規定進行計費；本文作者分享了關于企業服務平臺中的交易模式——計費結算的設計，我們一起來看一下。
企業服務項目，產品策劃分為兩部分。
- 業務載體，即技術服務開放平臺
- 對外輸出的技術服務產品孵化
本系列主要講技術服務開放平臺的產品策劃怎么做，對企業服務產品感興趣的可以來看看。
上一章，我們講了產品和平臺用戶，這一章，我們主要講交易：計費&結算。
一、核心交易流程簡述
首先，我們來捋一下一次交易的過程，看看核心操作有哪些？
1. 生產產品——>定價
根據產品不同服務形式（產品類型）確定計費模式，一般是按量收費，需要確定計量項（最小計費單位）和單價。
如API按調用次數/按QPS每天計費；SDK按永久授權終端設備數量計費；獨立部署按年收費等，然后單價可能有默認價格和優惠價格。
2. BD找到客戶——>報價——>提供免費測試
創建客戶賬號，并配置該產品有限期內有限次數免費調用。
客戶進行測試。
3. 簽訂合同，分配資源
測試通過，正式合作，BD與客戶確定付費模式，預付費或后付費。
預付費一般為包年包月的購買形式，需要預先確認購買資源量；資源包購買后，即將相關資源分配給用戶，直到過期失效。
后付費，即先使用，后付費，在結算時按實際使用量計費，需要確定結算周期，一般按日/月結算。
4. 客戶消費
客戶調用API，或者使用SDK，系統搜索該客戶該產品的訂單列表（可能同時有多個訂單），根據特定策略篩選出訂單，如果該訂單是預付費的資源包，則需判斷剩余資源數量是否足夠；如是后付費方式，則進行累計計費。
5. 對賬結算
預付費模式，下單完成后就生成賬單；賬單支付后，才分配資源。
后付費，到達結算周期時，生成賬單，并提供用量明細；使用資源后，才支付。
總結如上圖，通過對核心流程的梳理，我們對交易系統的認知開始有了輪廓。
二、功能模塊設計
基于上述的輪廓，我們繼續思考系統的核心功能模塊設計。
我們根據是否生成賬單，劃分為兩大塊：計費和結算。
1. 計費
概念：按照計費規則計算出單個產品要收取的費用，并且按照結算周期聚合所有服務的計費明細 生成賬單。
企業服務的計費模式一般分為預付費和后付費。
1）預付費
一般就是包年包月的購買形式：客戶可根據自身對資源的使用需求選擇資源包，下單完成后會生成賬單。要注意資源到期提醒或者欠費預警。
2）后付費
指的是先使用后付費，在到達結算周可期時，生成賬單的計費模式?？蛻粜枰诩s定時間內完成繳費；也涉及欠費管理。這種方式，對客戶方來說，用多少付多少，沒有資源浪費，更靈活。
對還處在發展早期的平臺更適合，或者客戶是大客戶，議價權較強的時候，一般都是后付費。流程如下：
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 協議
大佬，數據安全什么時候更新??？來自2023年的呼喊
不錯
期待云服務平臺繼續更新