在了解了清算的相关概念之后，对于搭建计费体系，有些同学还是没有思路。作者结合自己的经验，分享如何从0到1搭建计费体系，从四个方面来总结方法，希望对你有所帮助。

看完本文，你会知道以下内容，文章较长，建议收藏观看。

1. 什么是计费
2. 计费的特点
3. 计费的整体业务流程
4. 如何搭建计费体系

一、什么是计费

上文我们介绍了O2O电商的支付清结算体系的主要内容（可点击链接查看），本篇我们分享计费体系的设计方法，也即上篇文章题目中的【清算】，清算可拆解为清分和结算，也有人拆解成清算和结算，在这不纠结字面意思，本质是相同的，就是算钱和打钱，清分/清算对应的即是本次要分享的计费体系。

首先说下什么是计费，可以直接通过字面拆解来解读，计费：计算费用，一句话概括就是：根据不同的计费规则，计算一笔订单/交易中，不同参与角色应该分配多少利益（主要为钱），简单说就是一个怎么分蛋糕的事情，起到承上启下的作用。

需要说明下上文中的订单和/交易不是电商中狭义的订单/者交易，而是广义上凡涉及到计费的事件/活动都囊括在内，本次以O2O电商的订单计费来分享后续内容，如下图（来源于网络）。

二、计费的特点

1. 业务属性强

计费体系相对于支付或其他底层系统，具有很强的业务属性，如果你仔细研究公司计费规则的话，可以通过计费模式的调整去推导业务大概的发展轨迹，举个简单的例子，某一阶段，外卖平台对于骑手小哥0抽佣，底层原因可能是这个阶段平台比较缺劳动者供给，需要使用0抽佣的点把供给提上来。

可能到过段时间，服务质量比较好的配送小哥抽佣会降低，那这个阶段的重点是提高服务质量，用服务质量吸引/留住客户。

有一个经常讨论的点就是计费模块放在业务体系还是中台体系，我个人觉得没有太大的疑问，计费应该放在业务体系内，原因上文也说了，计费模块有很强的业务属性，可能不同阶段都会有一个大的调整，这和中台体系“通用”的设计理念相冲突。

2. 风险与收益并存

计费体系很容易出业务成果，可能只是调整模型中的计费策略，就能带来很明显的营收数据的提升，但同时计费也是一个非常容易背大锅的模块，业务/系统逻辑复杂，稍微错一个公式就有可能造成百上万的损失，整体来说是一个风险与收益并存的业务，但如果有机会，我仍然非常推荐你去负责这块的东西，难，才有成长，干就完了。

三、计费整体业务流程

从上面图中可以看到，计费主要是分成3步：触发算钱动作、算/确认钱、打钱

第1步：劳动者服务完成，在APP/小程序完成确认动作，然后由计费模块的上游系统触发计费动作，计费系统启动资金清算流程。

第2步：根据计费结果生成结算单（O2O中就是劳动者工资单），这一步是非必须的，和各平台实际的业务模式有关，如果是标准服务，例如：打车、外卖，无需确认直接结算即可。

如果是保姆/月嫂这种长单非标准家政服务，劳动者薪资与多种服务因素有关，例如上下户时间、是否请假等等，生成结算单（工资单）后需要劳动者、平台（非必须）、客户确认后，方可进行资金结算。

第3步：按照订单参与角色与费用类型生成结算单后，计费系统请求结算平台完成资金结算，整体业务流程完结。

四、如何搭建计费体系

上面介绍了计费体系的整体业务流程，接下来分享如何从0-1搭建计费系统，主要还是从上文业务流程拆解，然后围绕自身业务模式去搭建计费系统，记住一个最重要的点：系统是为业务服务的，没有万能的系统，只有适合自己平台业务的系统

1. 计费模型

上图是计费体系的模型，模型拆解为4个要点：触发计费、计费模式、计费结果、打款结算，后续也主要是从这4个方面作为切入点分享如何搭建计费系统。

2. 系统架构

说完业务流程与计费模型，我们再简单说一下计费体系的主要系统间架构，见上图，简单说就是上游系统触发，计费系统完成资金清算，最后请求结算平台完成打款结算，在这不再赘述，下文会详细说明。

3. 从0到1搭建

STEP1：触发计费

计费动作的触发由计费的上游系统触发，可以是订单/交易系统，也可以是服务履约系统。

实际业务流程中，劳动者服务完成后，在APP/小程序操作确认动作，例如滴滴打车到地方后，会划一下去收款（图片来源于网络），同样的还有外卖小哥送到后，会划一下“我已送达”（图片来源于网络）。

劳动者动作触发后，服务履约系统会把此笔服务订单标记为“服务完成”，对应订单和交易也会变成“已完成”状态，同时发送MQ消息到计费系统触发资金清算，完成业务信息由订单信息流到资金信息流的转变。

有一个点需要注意，为了防止劳动者迟迟未确认服务状态（推单），服务履约系统需要做兜底机制，系统定时任务判断服务订单是否服务完成，完成订单自动完成推单动作，触发计费，完成资金结算，防止整个服务履约过程卡住，造成劳动者投诉或其他资金损失。

STEP2：计费模式

2个设计方向：

计费模式是整个计费体系中最核心也是最具业务属性的部分，简单来说就是蛋糕怎么分的问题，计费模式的制定总体可以抽象为两个方向，1个是抽佣制，1个是差价制，抽佣制整体相对简单些，差价制总体更灵活，拓展性更强。为了大家直观看出两个的区别，我举个简单的例子，见下图：

平台单笔毛利=售价-成本，例子中【订单费用】是售价，【劳动者收入】是成本。

如果平台想提高单笔订单毛利，要么提高售价，要么降低成本（有限制），从上图可以看出，平台提高售价后，两个计费模式平台收入都有提高，但是差价制平台赚的更多，相当于售价调高部分全部被平台所得。

一对比差价制的灵活性就凸显出来，因为售价提高不一定要给劳动者加工资，平台可以全赚，差价制把服务的售价与成本价解耦，二者相互独立，可以保证平台收益最大化。

当然也不是所有的O2O服务都能采取差价制的设计思路，这个设计方法更适用于劳动者服务/商品可以做标准定价的业务场景，例如滴滴打车，用户支付的订单金额与滴滴司机收到的劳动报酬没有必然的比例关系，劳动者的薪资是单独的定价模式。

抽佣制的其他玩法

常见的订单抽佣制除了最简单的固定比例抽佣，也可以有很多玩法，比较常见的如下面几种：

• 阶梯式抽佣，1~100单抽佣比例10%，101~200单抽佣比例为5%，促使劳动者更加努力地接单，从而增加平台营收。
• 分级抽佣，不同等级的劳动者，对应抽佣比例不同，等级越高抽佣比例越低，促使劳动者不断提高商家等级，具体怎么样提高商家等级，就和劳动者分层的策略有关了。
• 按照单量抽佣，月底根据单量确定抽佣比例，统一进行结算，例如月底累计服务100单抽佣比例为10%，月底累计超过服务100单，抽佣比例位5%，这个模式平台的诉求和阶梯式抽佣是一样的。
• 抽佣比例与会员权益绑定，例如货拉拉的会员权益策略，其中一个权益就是司机购买的会员等级不同，对应司机订单抽佣比例不同，购买的会员等级越高抽佣比例越低，平台最终通过会员服务费和劳动者想要赚回会员费从而更加努力接单来增加营收。

最后，我们制定计费策略的时候，一定要想好策略对应的平台核心诉求/本质目标是什么，是为了增加营收？还是为了稳定/增加供给？或者都要。

延伸展开：

上文我也提了劳动者薪资的计费策略不仅仅可以增加营收，还可以和劳动者分层结合起来，不同等级的商家薪资/抽佣策略不同，等级越高的商家抽佣更低/工资更高，进而促使商家都去努力提高自己的劳动者等级，进而提高劳动的质量与留存，把商家计费策略当成一个劳动者管理的抓手。

总结：整体【差价制】计费模式更灵活，可以多从这个方向制定计费策略，同时制定劳动者计费策略时，要多思考业务侧本质的诉求。

STEP3：计费结果

上文我们分享了计费体系中最复杂的部分，计费结果这块相对来说会简单一些，我以比较常见的抽佣制来分享这个模块，主要分为抽佣配置、计费动作、清算列表/详情，下图是大概的交互流程：

抽佣配置：

抽佣配置模块主要是配置计费相关数据，例如不同等级劳动者抽佣比例或薪资，还有其他计费规则参数，这个模块主要是计费配置信息的载体，例如下图抽佣配置页面（以滴滴举例）：

一个点：计费系统需要提供数据查询接口，供其他业务系统查询抽佣比例/薪资，进行端上展示或金额试算，核心参数如下：

计费动作：

上游系统触发计费动作后，计费系统根据制定的计费规则，从不同系统拉取所需数据或其他系统传输相关数据至计费系统，完成各种类型费用的计算，生成清算结果。

清算记录/详情：

为了提高计费问题排查效率，清算详情（计费结果）页面尽可能展示与订单计费相关的所有信息，信息主要分为3类（详见如下原型图）

单独说一个点，由于业务的历史原因或业务探索，有可能存在多种计费策略共存的情况，为了提高后续出问题排查的效率，订单清算详情里面一定要加一个字段用以区分当前订单的计费策略，也就是图中的【计费模式】。

清算记录原型：

清算详情原型：

说明：上图只是拿滴滴作为举例，滴滴实际的计费场景和模式要比举例复杂的多。

结算单确认/调整：

如果订单中某个参与角色的资金清算数据需要做确认，则单独拉一个页面作为结算单的实体，去承载这个角色的相关资金/订单/服务摘要信息，然后配合流程平台（审批流）完成结算单的串联确认。

结算单调整功能，有一个点需要说下，就是调整结算单时需要选择资金调整的来源/去处，保证资金流向的正确，降低资金损失，如下图：

STEP4：结算打款

计费系统根据计费规则计算出不同费用类型金额后，请求结算系统进行打款结算，需要注意的是，不同费用类型结算周期与结算方式不一样，需要在结算系统配置不同费用类型的结算规则，详情我会在结算系统说明，这里不再赘述。

4. 数据指标

主要是下面几个方向的数据：

计费策略对应的业务收益，这个是最主要的，计费数据准确性、劳动者薪资结算时效、结算单确认、调整效率、资金清算过程中资金损失风险。

五、总结

计费体系是一个承上启下的模块，将订单业务信息转化为资金信息，具有很强的业务属性，需要多去思考业务侧的底层逻辑和本质诉求，业务/系统复杂度不低，很有锻炼性，同时很容易出彩，如果有机会从事这块工作的话，勇敢抓住机会。