2023年企业服务(云服务)平台:计费结算_第1页
2023年企业服务(云服务)平台:计费结算_第2页
2023年企业服务(云服务)平台:计费结算_第3页
2023年企业服务(云服务)平台:计费结算_第4页
2023年企业服务(云服务)平台:计费结算_第5页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

企业服务(云服务)平台:计费结算企业服务项目,产品策划分为两部分。

业务载体,即技术服务开放平台对外输出的技术服务产品孵化本系列主要讲技术服务开放平台的产品策划怎么做,对企业服务产品感爱好的可以来看看。

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

一、核心交易流程简述

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

1.生产产品——定价

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

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

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

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

客户进行测试。

3.签订合同,安排资源

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

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

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

4.客户消费

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

5.对账结算

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

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

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

二、功能模块设计

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

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

1.计费

概念:根据计费规章计算出单个产品要收取的费用,并且根据结算周期聚合全部服务的计费明细生成账单。

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

1)预付费

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

2)后付费

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

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

3)配置计费规章

这个模块既要支持配置资源包,也要支持后付费的计费规章。

①资源包

配置资源包的有效期起止时间,计量项,总量,以及安排规章和结转规章。依据安排规章和结转规章可分为「按月安排不结转/按月安排可结转/一次性安排不结转/一次性安排可结转」,影响下发和抵扣。

②后付费计费规章

计费规章主要是依据产品的服务形式确认计费周期,最小计费单位(计量项),以及单价。算法:需要支持阶梯式算法,即时间窗口内用得越多单价越廉价。要留意,在设计这一模块的时候,尽可能高度抽象,以保证敏捷度。由于ToB业务,客户是甲方爸爸,客户可能会提出其他的计费规章,也需要我们系统能支持。这里可以考虑留一个口子,让销售人员或者运营人员手工录入。(手工录入或者是价格管理,优待管理这一块,都会涉及到审批流管理模块设计,这里不额外绽开)

4)优待管理

支持运营配置优待方案,如优待券等。

5)计费挨次策略

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

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

6)到期提示/欠费预警

资源包到期前/资源包即将用完/后付费触发授信额度,需要提示用户续费,否则将停止服务。一是以邮件、短信、站内信的方式推送给客户。二是通知负责该客户的销售,销售通过线下的方式推动客户。

2.结算

概念:对账及发生实际的资金流转。

1)结算触发规章

预付费:是下单购买时就会立即触发结算,生成账单,发给客户确认,无误后,就会向客户供应发票,对方支付后,就会下发对应的资源到对方账户上。

后付费:到达结算周期,触发结算,聚和账单,发给客户确认,无误后,供应发票,对方支付。

2)聚合账单

企业客户可能有多个子账号。有几种方式。

子账号不单独计费;子账号使用主账号的资源或使用量记在主账号上。由主账号负责结算。子账号单独计费;预付费时,主账号涉及资源安排。由主账号负责结算。子账号单独计费,独立结算;一般是组织架构简单的集团,要求子公司财务独立核算。3)对账

账单生成后,可能会由于业务上的一些问题需要调整。

4)付款

企业服务,不面对个人开发者时,一般都是线下对公汇款。预付费,汇款完成,即下发对应资源。后付费,汇款完成,即与账单对应的计费流水进行核销。

5)欠费管理

假如是预付费,购买时马上支付的方式;当客户的资源包已经用完,就会进入欠费流程,但是一般不会直接停服;超出资源包的部分可以以按后付费的方式结算,这里就需要有一个欠费授信管理的策略,需要结合客户的风险程度,设置一个欠费额度上限。超过上限后,再进入下一步:停服。

假如是后付费,那企业客户一般有账期,比如下个月初结算上个自然月的帐,对账完成后,客户在30天内支付完成即可;那这个账期内,也是不停服的,同意需要授信管理策略,超过上限后,则停止服务;后付费,还有一种削减欠费的方式,即客户使用前先要求对方充值肯定的资金用以冻结,使用后再结算,不过一般是大厂才(敢)这么做。

三、业务数据模型

大框架,顶层设计有了,我们可以提炼出来业务过程中关键对象的关系,进而抽象出底层的业务数据模型。

只有业务数据模型清晰了,正确了,建立在这之上的更细节的业务规律,流程,功能设计才会清楚无误;且数据模型的设计会影响到数据库表结构,字段的设计,是产品设计的根基,是设计之初就要想清晰的事情。

我之前的文章也提过,从项目的完整生命周期来看,数据表结构打算了拓展性;上线后,假如要改底层的数据表结构,成本会很高。

以计费流程为例,关键对象有:客户、账号、产品、订单、账单、计费模式、计量项、单价、计量(使用量)。

这些对象的关系是什么样的呢?我们用ER图来梳理一下。

简洁介绍一下ER图:

ER图概念:ER模型,全称为实体联系模型、实体关系模型或实体联系模式图(EntityRelationshipDiagram),供应了表示实体类型、属性和联系的方法,用来描述现实世界的概念模型,它是描述现实体对象之间关联关系经典方法。

ER图三个核心要素:

实体:表示一个对象,可以被(粗略地)认为是名词,比如会员,优待券,公司属性:对象所具有的属性,特性。比如会员可以有昵称,生日,注册时间等属性关系:表示对象与对象之间的联系。比如老师这个对象和同学的实体之间的联系。ER图中关联关系有三种:

1对1:指实体集A与实体集B,A中的每一个实体至多与B中一个实体有关系;反之亦然。1对多:指实体集A中的每一个实体与B中至少有1个以上的实体有关系;且B中每一个实体至多与A中一个实体有关系。多对多

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论