我理解的 toB 产品框架(三)

前文再续,书接上一回。上一篇文章跟大家分享了这一、两年的 toB 产品的一个趋势,本篇想跟大家分享下另一个趋势。如果你没有看过我之前的分享,可以看看:

我理解的 toB 产品框架(一)

我理解的 toB 产品框架(二)

如果说 toB 产品的第一个趋势是应用互联,那么另外一个趋势就是企业间的信息互联。像传统私有云的 toB 产品,基本上就是个信息孤岛,企业信息很少流出,或者与其它企业直接交换信息。举个例子:

你的客户需要订一批货物,销售一般会在公司的ERP或CRM系统录入订单或合同,然后走审批。该合同可能还需要快递到你的客户那里,然后又走一遍审批。最后完成生产和发货。整个流程异常繁琐,而且速度很慢。(这个场景已经算是快的了,还有更长更麻烦的。)另一方面,即使是简单的信息触达,可能都会很麻烦。拿钉钉做为例子:

你所在的公司在使用钉钉,内部交流一直是使用钉钉,但是当你需要跟你的合作伙伴、你的客户交流时,你还是需要打开邮箱、QQ或者微信,因为你的合作方不一定在使用钉钉。

第一个场景,将会是目前 toB 平台产品重点关注的切入点。即类似钉钉3.0推出的服务窗的概念。企业的外部好友(合作伙伴、客户、甚至供应商)都能通过这个服务窗发起订货、退货甚至联系客服等等。而这个服务窗的背后,将会是企业的ERP系统,甚至是企业的智能制造系统。其产品框架将会类似(A、B为不同企业):

理想化的场景将会是这样的故事(举例,非实际):

如果某经销商需要订购100箱面包,该经销商直接在面包生产商那订购,面包生产商收到订购订单后,系统自动进行库存盘点,如果发现货物不足,机器自动开始生产。同时发现面粉也不够了,会自动向上游的面粉厂订购面粉。这套产品框架貌似能跑通,但是实际上是个大坑。比如目前钉钉提供的服务窗能力对于 B2B 的企业估计就比较麻烦了,毕竟这种企业涉及的订单金额更大,流程也更加繁琐,人情交易也更多。如何在做到信息流动之余,还做到销售提速,将是产品需要突破的地方。单纯的信息流动并不能让企业用起来,只有让企业看到了利润才是最关键的。

另一方面,B2C的企业跑这套流程,可能也不太好使,因为C端的用户并不一定使用钉钉,不过阿里倒是可以考虑将旺旺与钉钉、微博与钉钉打通,从而解决B、C端之间的消息触达问题。但是仍然很难根本上解决消息触达的问题。所以就目前看来,谁最优机会根本上解决消息触达的问题?估计就是企业微信了。

小程序的出现,意味着未来企业微信也将会存在应用平台的能力,而且它的能力比我之前提到的 toB 产品框架还要强大,因为它在普通的框架上,还搭载了独特的程序框架,大大提高了体验,不像现在的H5应用那样需要实时加载。而且,因为页面可以调用小程序提供的组件,这些组件早已内置在微信客户端,它们的体验将会更加「原生」。所以我认为未来较为理想的 toB 的产品框架将会是这样:

平台除了提供带有 toB 属性的能力外,还会额外提供统一的设计、审核以及运营规范,甚至还会提供类似Swift那样的开发语言,或者类似微信小程序那样的特有语言。

不过我脑海中还有一个更加疯狂的设想,那就是...

好吧~这次貌似写得有点多了,很累呀~

Comments
Write a Comment