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

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

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

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

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

一、核心交易流程简述

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

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