企业服务(云服务)平台:计费结算

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

编辑导语:如今一些企业会开发服务的平台,对于这些平台,一些产品的服务会产生收费的模式和标准,根据不同的年月日等规定进行计费;本文作者分享了关于企业服务平台中的交易模式——计费结算的设计,我们一起来看一下。

企业服务(云服务)平台:计费结算

企业服务项目,产品策划分为两部分。

  • 业务载体,即技术服务开放平台
  • 对外输出的技术服务产品孵化

本系列主要讲技术服务开放平台的产品策划怎么做,对企业服务产品感兴趣的可以来看看。

上一章,我们讲了产品和平台用户,这一章,我们主要讲交易:计费&结算。

一、核心交易流程简述

首先,我们来捋一下一次交易的过程,看看核心操作有哪些?

1. 生产产品——>定价

根据产品不同服务形式(产品类型)确定计费模式,一般是按量收费,需要确定计量项(最小计费单位)和单价。

如API按调用次数/按QPS每天计费;SDK按永久授权终端设备数量计费;独立部署按年收费等,然后单价可能有默认价格和优惠价格。

2. BD找到客户——>报价——>提供免费测试

创建客户账号,并配置该产品有限期内有限次数免费调用。

客户进行测试。

3. 签订合同,分配资源

测试通过,正式合作,BD与客户确定付费模式,预付费或后付费。

预付费一般为包年包月的购买形式,需要预先确认购买资源量;资源包购买后,即将相关资源分配给用户,直到过期失效。

后付费,即先使用,后付费,在结算时按实际使用量计费,需要确定结算周期,一般按日/月结算。

4. 客户消费

客户调用API,或者使用SDK,系统搜索该客户该产品的订单列表(可能同时有多个订单),根据特定策略筛选出订单,如果该订单是预付费的资源包,则需判断剩余资源数量是否足够;如是后付费方式,则进行累计计费。

5. 对账结算

预付费模式,下单完成后就生成账单;账单支付后,才分配资源。

后付费,到达结算周期时,生成账单,并提供用量明细;使用资源后,才支付。

企业服务(云服务)平台:计费结算

总结如上图,通过对核心流程的梳理,我们对交易系统的认知开始有了轮廓。

二、功能模块设计

基于上述的轮廓,我们继续思考系统的核心功能模块设计。

我们根据是否生成账单,划分为两大块:计费和结算。

1. 计费

概念:按照计费规则计算出单个产品要收取的费用,并且按照结算周期聚合所有服务的计费明细 生成账单。

企业服务的计费模式一般分为预付费和后付费。

1)预付费

一般就是包年包月的购买形式:客户可根据自身对资源的使用需求选择资源包,下单完成后会生成账单。要注意资源到期提醒或者欠费预警。

企业服务(云服务)平台:计费结算

2)资源包

资源包根据分配规则和结转规则可分为「按月分配不结转/按月分配可结转/一次性分配不结转/一次性分配可结转」,影响下发和抵扣。

3)到期提醒/欠费预警

资源到期前或者客户即将用完资源,需要提醒用户续费,否则将停止服务;一是以邮件、短信、站内信的方式推送给客户,二是通知负责该客户的销售,销售通过线下的方式推动客户。

4)后付费

指的是先使用后付费,在到达结算周可期时,生成账单的计费模式。客户需要在约定时间内完成缴费;也涉及欠费管理。这种方式,对客户方来说,用多少付多少,没有资源浪费,更灵活。

对还处在发展早期的平台更适合,或者客户是大客户,议价权较强的时候,一般都是后付费。流程如下:

5)配置计费规则

计费规则主要是根据产品的服务形式确认计费周期,最小计费单位(计量项),以及单价。

  • 价格:不同客户,可能优惠不一样,单价不一样。
  • 算法:需要支持普遍的资源包或是阶梯式算法,即时间窗口内用得越多单价越便宜。
  • 优惠管理:支持销售人员或运营人员配置优惠方案。

要注意,在设计这一模块的时候,尽可能高度抽象,以保证灵活度;因为To B业务,客户是甲方爸爸,客户可能会提出其他的计费规则,也需要我们系统能支持。

这里可以考虑留一个口子,让销售人员或者运营人员手工录入(手工录入或者是价格管理,优惠管理这一块,都会涉及到审批流管理模块设计,这里不额外展开)。

6)计费顺序策略

客户使用同一产品,可能同时既有免费额度,也购买了预付费资源包或按量付费 ,这就涉及到计费顺序的问题,也需要先确认好;比如:预付费QPS>预付费资源包>免费额度>按量付费。

如果购买了多个资源包,抵扣顺序可以是从已购买的次数包中按照购买时间顺序由早至晚,按照规格由小至大依次扣除相应次数。

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 协议

给作者打赏,鼓励TA抓紧创作!

随意打赏

提交建议
微信扫一扫,分享给好友吧。