編輯導語：如今一些企業會開發服務的平台，對于這些平台，一些産品的服務會産生收費的模式和标準，根據不同的年月日等規定進行計費；本文作者分享了關于企業服務平台中的交易模式——計費結算的設計，我們一起來看一下。

企業服務項目，産品策劃分為兩部分。

本系列主要講技術服務開放平台的産品策劃怎麼做，對企業服務産品感興趣的可以來看看。

上一章，我們講了産品和平台用戶，這一章，我們主要講交易：計費&結算。

一、核心交易流程簡述

首先，我們來捋一下一次交易的過程，看看核心操作有哪些？

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 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部