科技猎企业服务（云服务）平台：计费结算
编辑导语：如今一些企业会开发服务的平台，对于这些平台，一些产品的服务会产生收费的模式和标准，根据不同的年月日等规定进行计费；本文作者分享了关于企业服务平台中的交易模式——计费结算的设计，我们一起来看一下。
企业服务项目，产品策划分为两部分。
- 业务载体，即技术服务开放平台
- 对外输出的技术服务产品孵化
本系列主要讲技术服务开放平台的产品策划怎么做，对企业服务产品感兴趣的可以来看看。
上一章，我们讲了产品和平台用户，这一章，我们主要讲交易：计费&结算。
一、核心交易流程简述
首先，我们来捋一下一次交易的过程，看看核心操作有哪些？
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 协议
