0%

一个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的玩法。这个可比现在什么充值送多少来的好(从长远角度)。充值送多少这种不就是收割未来啊。

twilio