家政服务行业的转介绍业务及架构

本文内容1、什么是转介绍2、服务行业的转介绍特点3、到家转介绍架构设计

1、什么是转介绍

转介绍业务从广义上来说就是“老客户带新客户”，用来完成某一次交易;但笔者在这里所定义的转介绍更倾向为“分销”

“分销”的本质是什么？

分销本质上来说就是“代理销售商品”;“用户”代卖商品，并从中获取到一定报酬(佣金)的场景都属于分销场景;

这里的用户可以是     a) 合伙人：有自己的社群社区资源，     专业做商品分销的用户     b) 老客户：自己在平台购买过商品，     并推荐给其他用户来获取一定佣金     c) 专门从事商品分销的公司或者个体工商户     d) ....

电商模式的转介绍业务

本文主要讨论的基于互联网模式下转介绍业务的玩法; 在互联网场景下，电子商务是必须要介绍的一种转介绍销售场景.

如：- 传统电商模式：某宝的淘宝客体系、京东分销宝- 分销型社交电商：   云集：转型会员制社交电商   达令家：多级奖励制度的社交电商   云品仓：聚合社交和商品双重属性的“轻电商”   ......

互联网电商转介绍业务流转过程

电商转介绍业务流转是怎样的模式呢? 请看下图

如上是标准电商业务的转介绍业务流

推荐人代理商品-》并推荐给用户-》用户觉得商品还不错并下单购买-》转介绍系统针对购买的商品给推荐人进行佣金的计算-》系统下发佣金至推荐人指定的账户

基于上述业务流对推荐人视角来看

总结来说就是： 推荐人推荐商品-》基于商品计算佣金-》获得佣金

伴随着社区化、社群化、诚信社交的发展， 分销型电商业务正在蓬勃发展。未来市场潜力是巨大的。

家政服务行业同样也适用转介绍的场景，那服务行业的转介绍特点有哪些呢？

2、服务行业的转介绍特点

在上面介绍电商模式下转介绍的业务流来看，给推荐人返佣是“推荐一次返佣一次”的模式，在用户下单以后，基于用户的“下单金额”就可以进行返佣.

而在服务性行业的转介绍场景下最大的特点是： “推荐一次 ，返佣多次” 为什么会产生推荐一次，返佣多次的情况，这里结合笔者多年服务行业的从业经验来看，主要是服务商品提供方对于风险和成本把控的一种手段.

下面基于服务行业转介绍的业务信息流转进一步说明为什么会出现推荐一次，返佣多次的场景

服务行业转介绍业务流

以推荐劳动者为例：

劳动者所指：保姆月嫂育儿嫂

从上图可以看出， 服务行业最大的特点存在"服务周期"的概念， 举例58到家家政服务来说，从平台寻找一个劳动者-》到劳动者在到家平台完成认证成为合法商家-》劳动者在平台完成首次接单-》劳动者去客户家上门完成服务 整个周期很长。
理论上来说推荐人推荐的劳动者在到家平台周期越长，推荐人所获得的佣金越多，对于到家平台来说，越靠后的返佣给推荐人，风险和成本也就更可控。因此在设计返佣规则上也更灵活。

对比一下电商行业和服务行业的返佣模式：

更发散的来看服务行业的转介绍，我们可以看出服务行业有如下特点：

•服务的商品品类众多(劳动者线索、客户线索、保洁类商品、培训类商品....)•每类商品的返佣节点不固定，返佣金额不固定

劳动者线索可返佣的节点：认证通过、签单、上户客户线索可返佣的节点：面试阿姨、签单、阿姨上门服务保洁类商品：购买保洁服务、保洁师上门完成服务培训类商品：购买课程、进行培训、培训完成.....

•返佣策略多变，运营方法众多

针对服务行业的转介绍业务的运营多变性，返佣节点不稳定性，接下来，我们一起聊聊到家的转介绍平台系统架构是怎么设计的？

3、到家转介绍架构设计

在进行架构设计前， 我们会充分对现有业务进行调研和抽象， 最终如下图抽象出三个基本的业务概念

•资源(商品) - 要销售的资源(线索、商品、课程等等)•推荐人 - 帮到家平台销售资源的分销人•佣金 - 给推荐人推荐资源所得的报酬

针对三个基本的业务概念规划的到家转介绍架构如下：

中后台系统：

•针对佣金规划了 分销平台•针对推荐人规划了 合伙人管理平台•针对资源售卖方式规划了 共有基础服务平台

小前台

提供了各式各样的推广渠道，包括小程序、公众号、h5等，真正做到“推广多样化，数据统一化”

从上图我们可以看出，服务行业的转介绍业务和传统互联网电商行业最大的区别在于基于服务周期内的佣金计算部分和返佣多样性的差别。

接下来着重说说 分销平台的整体设计

分销平台

分销平台时序图

在上面我们提到家政服务行业最大的特点是服务周期内 “返佣多次”， 在技术层面上针对返佣多次，抽象了家政服务行业独有的业务概念“返佣节点”

tips：

   返佣节点：针对在服务周期内的每个需要给推荐人返佣的节点，
我们定义为返佣节点。

   

比如：       劳动者在平台完成了身份认证，我们给推荐人返佣xx元， 我们定义阿姨完成身份认证的这个节点就是返佣节点。

那么分销平台的整体逻辑运转轴就是基于“返佣节点”下的佣金来设计完成的。前面我们提到返佣节点是动态的， 那意味着整个分销平台的设计都是基于动态化设计思想来实现的。

具体表现在

•基于返佣节点的返佣规则配置化•基于返佣规则计算佣金逻辑动态化•返佣流程标准化

基于返佣节点的返佣规则配置化

规则配置 先上图

返佣规则配置化后，各个资源方接入成本下降了 50%↓，可快速响应业务需求，返佣节点的动态增减对系统完全无侵入，数据结构更稳定

技术实现

1.规则配置存储：json化存储，代码层进行数据结构化，对于数据对象的定义为抽象类-》子类的原则2.规则配置验证：在规则抽象类上提供 “验证触点”，抽象方法，各个子类具体实现数据的验证3.规则项版本号：为每个规则项定义版本号，如果当前规则项已经参与进行规则计算，在修改规则配置时系统会自动进行规则项版本的升级

规则类图

基于返佣规则计算佣金逻辑动态化

系统在实现过程中使用大量的策略模式来解决计算动态化的问题。

动态化的核心思想是：每增加一个规则配置，对应增加一个计算节点来支撑佣金的计算。

定义计算策略

@CommissionComputeStrategy(incomeNodes = {IncomeNode.WORKER_BAOMU_AUTHENTICATION， IncomeNode.WORKER_YUESAO_AUTHENTICATION， IncomeNode.WORKER_YUERSAO_AUTHENTICATION})@Componentpublic class WorkerClueAuthenticationComputeHandler extends WorkerClueCommissionComputeHandler 

策略路由

佣金计算器类图定义

预计算场景：推荐人还无法真实获取到佣金， 系统提前计算出推荐人预计所得收益以提高推荐人的积极性。

返佣流程标准化

核心思想： 对于返佣节点的扩充，整个分销主流程是稳定的，不需要做任何的变动。

针对上述分销平台时序图可知分销主流程是完全固定的。

佣金计算及返佣的主流程

名词解释：

生佣记录：针对推荐人的一次推荐，系统会按照返佣节点生成多笔记录，这些记录统称为生佣记录。

主流程

•预计算 - 针对推荐人推荐的资源提前进行佣金计算•可返佣 - 在整个服务周期内，通过定时轮询和MQ异步通知的机制监听资源方的状态是否真正满足可以返佣的条件•生成佣金订单 - 对满足条件的生佣记录按照返佣规则进行真实的佣金计算并生成佣金订单•打款 - 对生成的佣金订单按照特定条件会有选择的进行业务审核和财务审核，审核通过后会把佣金发放到推荐人指定的银行或第三方支付账户内•查询 - 在整个服务周期内对于推荐人和运营方提供完整的查询服务

举个实际示例：

小黄(推荐人) 发现邻居张阿姨(劳动者)一直想做月嫂相关的工作， 小黄通过公司的58家选小程序录入了张阿姨的手机号信息和姓名。58家选把劳动者信息和推荐人信息推送到分销平台，

预计算 分销平台根据张阿姨所在城市，是做月嫂工作等信息自动选择出一条返佣规则。并基于返佣规则提前计算出小黄预计在每个返佣节点能拿到多少佣金，并生成佣金记录

可返佣 - 这时公司招商团队发现张阿姨想在到家平台做月嫂工作，就联系张阿姨，指导阿姨怎样认证成为到家平台的月嫂劳动者，张阿姨通过阿姨一点通app进行人脸识别等一系列操作认证成为了到家的月嫂劳动者，分销平台主动监听到了商家系统里张阿姨已经认证成为了月嫂劳动者，系统判定可以给小黄(推荐人)返佣了

生成佣金订单 - 分销平台针对张阿姨的认证结果按照返佣规则进行真实佣金的计算，并生成佣金订单

打款 - 如果有必要，公司业务团队和财务团队会对给小黄返佣的这笔订单进行审核，审核通过后，小黄就可以收到这笔款项了

查询 - 张阿姨的认证、签单周期较长，小黄没事儿就在58家选小程序的返佣页面查看，我推荐的张阿姨有没有成为劳动者，我获得的佣金有没有到账

总结

针对服务行业的转介绍架构， 通过抽象服务周期内的返佣节点， 并做到返佣节点的返佣规则配置化，计算节点动态化，理论上适用于任何服务类场景的转介绍模式。

在设计转介绍业务时个人的一点心得：前期做好充分的业务调研，找准系统的逻辑运转轴，基于以上进行系统拆解和架构的设计。