一个ToB系统的裂变

对于ToB系统一般都是销售很重的事情，因为涉及到预算会非常多，因此大家都是比较小心的。

而很多时候我们的计费方式比较粗犷，没有做到精细化控制。因为我们的模式还是销售产生订单的模式。而这样的问题就是每个客户都需要销售去谈一个价格，根本没法进行裂变。

所谓裂变的含义是客户自己来帮你推广，也可以增加你的日活月活等等。

而无论是saas还是paas的服务，如果能够做到精细化的计费方式，那我们可玩的方式就很多了。精细化的计费前提很多都需要有精细化的控制方式。

还是以贵司的客服系统为例。

现在是每个坐席每年假设收2000元钱。 那每年卖1万个就是2000万的水平，加上各种打折，估计也就剩下1200万吧。平均到一个月就是100万收入的水平。

那接入各种精细化的玩法呢？

规则如下：
每个租户可以每天有几个免费接待限额，多了就按一个会话0.1元来收取。如果要达到100万收入，那就需要1000万个会话每个月。减去每月免费「假设为2个」的，大概需要1030万会话。

同时我们提供连续几天登录多送几个接待限额，而且加上邀请注册也赠送接待限额。邀请的人花费多也可以赠送限额。总之在这个系统，接待会话数就类似于「系统货币」一般存在。整个系统就是丰俭由人。对于会话量的用户也可以进行阶梯定价。好比CDN一样，用多少TB一个单价一样。

假设就如上2个玩法，那从技术角度需要做什么呢？

控制注册： 防止机器人邀请，如何识别这个注册是真实的人？手机号？IP？身份信息？
控制登录： 如何防止机器人登录
会话控制： 超过免费额度的接入请求怎么处理？
超时控制： 用户需要控制多久的会话就自动丢弃了。
扣费详单： 用户需要知道自己每一笔支出是什么。同时提供相应的趋势。
余额控制： 用户可以自己设置还剩下多少余额或者会话量提醒用户，登录提醒，短信提醒，邮件提醒。对于欠费的用户如何处理？ 给予信用额度？还是直接关停？已经集成的那些用户还会有请求过来怎么处理？

这样才算一个合格的saas或者paas服务了。依靠用户口碑自己去推荐推广。这怎么感觉是拼夕夕的做法呢，将购物变成游戏一般，当然你可以自己进行切换各种模式。

而对于客服人员也可以引进各种级别，青铜，白银，黄金等等。这样不是有趣很多。来个提示“您本月的接待数超过96%的客服人员。” 再来个每个接待数的客服坐席数量。当然很多该注意隐私的部分必须得注意。

而整个系统的架构应该就跟twilio一样的。这样客户就完全可以自己定义啊，自由度大大提升。这个愿望好像有点远。不过这样才算是一个ToB的系统裂变成了ToC的玩法。这个可比现在什么充值送多少来的好（从长远角度）。充值送多少这种不就是收割未来啊。