企業(yè)服務(云服務)平臺:計費結(jié)算

3 評論 14415 瀏覽 83 收藏 13 分鐘

編輯導語:如今一些企業(yè)會開發(fā)服務的平臺,對于這些平臺,一些產(chǎn)品的服務會產(chǎn)生收費的模式和標準,根據(jù)不同的年月日等規(guī)定進行計費;本文作者分享了關于企業(yè)服務平臺中的交易模式——計費結(jié)算的設計,我們一起來看一下。

企業(yè)服務項目,產(chǎn)品策劃分為兩部分。

  • 業(yè)務載體,即技術服務開放平臺
  • 對外輸出的技術服務產(chǎn)品孵化

本系列主要講技術服務開放平臺的產(chǎn)品策劃怎么做,對企業(yè)服務產(chǎn)品感興趣的可以來看看。

上一章,我們講了產(chǎn)品和平臺用戶,這一章,我們主要講交易:計費&結(jié)算。

一、核心交易流程簡述

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

1. 生產(chǎn)產(chǎn)品——>定價

根據(jù)產(chǎn)品不同服務形式(產(chǎn)品類型)確定計費模式,一般是按量收費,需要確定計量項(最小計費單位)和單價。

如API按調(diào)用次數(shù)/按QPS每天計費;SDK按永久授權終端設備數(shù)量計費;獨立部署按年收費等,然后單價可能有默認價格和優(yōu)惠價格。

2. BD找到客戶——>報價——>提供免費測試

創(chuàng)建客戶賬號,并配置該產(chǎn)品有限期內(nèi)有限次數(shù)免費調(diào)用。

客戶進行測試。

3. 簽訂合同,分配資源

測試通過,正式合作,BD與客戶確定付費模式,預付費或后付費。

預付費一般為包年包月的購買形式,需要預先確認購買資源量;資源包購買后,即將相關資源分配給用戶,直到過期失效。

后付費,即先使用,后付費,在結(jié)算時按實際使用量計費,需要確定結(jié)算周期,一般按日/月結(jié)算。

4. 客戶消費

客戶調(diào)用API,或者使用SDK,系統(tǒng)搜索該客戶該產(chǎn)品的訂單列表(可能同時有多個訂單),根據(jù)特定策略篩選出訂單,如果該訂單是預付費的資源包,則需判斷剩余資源數(shù)量是否足夠;如是后付費方式,則進行累計計費。

5. 對賬結(jié)算

預付費模式,下單完成后就生成賬單;賬單支付后,才分配資源。

后付費,到達結(jié)算周期時,生成賬單,并提供用量明細;使用資源后,才支付。

總結(jié)如上圖,通過對核心流程的梳理,我們對交易系統(tǒng)的認知開始有了輪廓。

二、功能模塊設計

基于上述的輪廓,我們繼續(xù)思考系統(tǒng)的核心功能模塊設計。

我們根據(jù)是否生成賬單,劃分為兩大塊:計費和結(jié)算。

1. 計費

概念:按照計費規(guī)則計算出單個產(chǎn)品要收取的費用,并且按照結(jié)算周期聚合所有服務的計費明細 生成賬單。

企業(yè)服務的計費模式一般分為預付費和后付費。

1)預付費

一般就是包年包月的購買形式:客戶可根據(jù)自身對資源的使用需求選擇資源包,下單完成后會生成賬單。要注意資源到期提醒或者欠費預警。

2)后付費

指的是先使用后付費,在到達結(jié)算周可期時,生成賬單的計費模式。客戶需要在約定時間內(nèi)完成繳費;也涉及欠費管理。這種方式,對客戶方來說,用多少付多少,沒有資源浪費,更靈活。

對還處在發(fā)展早期的平臺更適合,或者客戶是大客戶,議價權較強的時候,一般都是后付費。流程如下:

3)配置計費規(guī)則

這個模塊既要支持配置資源包,也要支持后付費的計費規(guī)則。

①資源包

配置資源包的有效期起止時間,計量項,總量,以及分配規(guī)則和結(jié)轉(zhuǎn)規(guī)則。根據(jù)分配規(guī)則和結(jié)轉(zhuǎn)規(guī)則可分為「按月分配不結(jié)轉(zhuǎn)/按月分配可結(jié)轉(zhuǎn)/一次性分配不結(jié)轉(zhuǎn)/一次性分配可結(jié)轉(zhuǎn)」,影響下發(fā)和抵扣。

②后付費計費規(guī)則

  • 計費規(guī)則主要是根據(jù)產(chǎn)品的服務形式確認計費周期,最小計費單位(計量項),以及單價。
  • 算法:需要支持階梯式算法,即時間窗口內(nèi)用得越多單價越便宜。

要注意,在設計這一模塊的時候,盡可能高度抽象,以保證靈活度。因為To B業(yè)務,客戶是甲方爸爸,客戶可能會提出其他的計費規(guī)則,也需要我們系統(tǒng)能支持。這里可以考慮留一個口子,讓銷售人員或者運營人員手工錄入。(手工錄入或者是價格管理,優(yōu)惠管理這一塊,都會涉及到審批流管理模塊設計,這里不額外展開)

4)優(yōu)惠管理

支持運營配置優(yōu)惠方案,如優(yōu)惠券等。

5)計費順序策略

客戶使用同一產(chǎn)品,可能同時既有免費額度,也購買了預付費資源包或按量付費 ,這就涉及到計費順序的問題,也需要先確認好;比如:預付費QPS>預付費資源包>免費額度>按量付費。

如果購買了多個資源包,抵扣順序可以是從已購買的次數(shù)包中按照購買時間順序由早至晚,按照規(guī)格由小至大依次扣除相應次數(shù)。

6)到期提醒/欠費預警

資源包到期前/資源包即將用完/后付費觸發(fā)授信額度,需要提醒用戶續(xù)費,否則將停止服務。一是以郵件、短信、站內(nèi)信的方式推送給客戶。二是通知負責該客戶的銷售,銷售通過線下的方式推動客戶。

2. 結(jié)算

概念:對賬及發(fā)生實際的資金流轉(zhuǎn)。

1)結(jié)算觸發(fā)規(guī)則

預付費:是下單購買時就會立刻觸發(fā)結(jié)算,生成賬單,發(fā)給客戶確認,無誤后,就會向客戶提供發(fā)票,對方支付后,就會下發(fā)對應的資源到對方賬戶上。

后付費:到達結(jié)算周期,觸發(fā)結(jié)算,聚和賬單,發(fā)給客戶確認,無誤后,提供發(fā)票,對方支付。

2)聚合賬單

企業(yè)客戶可能有多個子賬號。有幾種方式。

  • 子賬號不單獨計費;子賬號使用主賬號的資源或使用量記在主賬號上。由主賬號負責結(jié)算。
  • 子賬號單獨計費;預付費時,主賬號涉及資源分配。由主賬號負責結(jié)算。
  • 子賬號單獨計費,獨立結(jié)算;一般是組織架構復雜的集團,要求子公司財務獨立核算。

3)對賬

賬單生成后,可能會因為業(yè)務上的一些問題需要調(diào)整。

4)付款

企業(yè)服務,不面向個人開發(fā)者時,一般都是線下對公匯款。預付費,匯款完成,即下發(fā)對應資源。后付費,匯款完成,即與賬單對應的計費流水進行核銷。

5)欠費管理

如果是預付費,購買時立即支付的方式;當客戶的資源包已經(jīng)用完,就會進入欠費流程,但是一般不會直接停服;超出資源包的部分可以以按后付費的方式結(jié)算,這里就需要有一個欠費授信管理的策略,需要結(jié)合客戶的風險程度,設置一個欠費額度上限。超過上限后,再進入下一步:停服。

如果是后付費,那企業(yè)客戶一般有賬期,比如下個月初結(jié)算上個自然月的帳,對賬完成后,客戶在30天內(nèi)支付完成即可;那這個賬期內(nèi),也是不停服的,同意需要授信管理策略,超過上限后,則停止服務;后付費,還有一種減少欠費的方式,即客戶使用前先要求對方充值一定的資金用以凍結(jié),使用后再結(jié)算,不過一般是大廠才(敢)這么做。

三、業(yè)務數(shù)據(jù)模型

大框架,頂層設計有了,我們可以提煉出來業(yè)務過程中關鍵對象的關系,進而抽象出底層的業(yè)務數(shù)據(jù)模型。

只有業(yè)務數(shù)據(jù)模型清楚了,正確了,建立在這之上的更細節(jié)的業(yè)務邏輯,流程,功能設計才會清晰無誤;且數(shù)據(jù)模型的設計會影響到數(shù)據(jù)庫表結(jié)構,字段的設計,是產(chǎn)品設計的根基,是設計之初就要想清楚的事情。

我之前的文章也提過,從項目的完整生命周期來看,數(shù)據(jù)表結(jié)構決定了拓展性;上線后,如果要改底層的數(shù)據(jù)表結(jié)構,成本會很高。

以計費流程為例,關鍵對象有:客戶、賬號、產(chǎn)品、訂單、賬單、計費模式、計量項、單價、計量(使用量)。

這些對象的關系是什么樣的呢?我們用ER圖來梳理一下。

簡單介紹一下ER圖:

ER圖概念:ER模型,全稱為實體聯(lián)系模型、實體關系模型或?qū)嶓w聯(lián)系模式圖(Entity Relationship Diagram),提供了表示實體類型、屬性和聯(lián)系的方法,用來描述現(xiàn)實世界的概念模型, 它是描述現(xiàn)實體對象之間關聯(lián)關系經(jīng)典方法。

ER圖三個核心要素:

  • 實體:表示一個對象,可以被(粗略地)認為是名詞,比如會員,優(yōu)惠券,公司
  • 屬性:對象所具有的屬性,特性。比如會員可以有昵稱,生日,注冊時間等屬性
  • 關系:表示對象與對象之間的聯(lián)系。比如老師這個對象和學生的實體之間的聯(lián)系。

ER圖中關聯(lián)關系有三種:

  • 1對1 :指實體集A與實體集B,A中的每一個實體至多與B中一個實體有關系;反之亦然。
  • 1對多:指實體集A中的每一個實體與B中至少有1個以上的實體有關系;且B中每一個實體至多與A中一個實體有關系。
  • 多對多 :指A中的每一個實體與B中至少有1個以上的實體有關系;反之亦然。

一般來說,我們設計的時候,如非必要,盡量避免多對多的關聯(lián)關系。

這里只是簡單介紹對ER圖感興趣的同學,可以自行搜索了解更多;另外說一點,ER圖的呈現(xiàn)方式很多,產(chǎn)品不必拘泥于某一個特定形式,描述清楚對象和關系即可。

關于數(shù)據(jù),安全,請看下一次更新。

 

作者:石青;微信公眾號:石青自習室

本文由 @石青 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自 unsplash,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 大佬,數(shù)據(jù)安全什么時候更新???來自2023年的呼喊

    來自北京 回復
  2. 不錯

    來自江蘇 回復
  3. 期待云服務平臺繼續(xù)更新

    回復