关于 ToB 产品与服务的一些思考

对于toB的产品而言，企业首先要把工具价值做好。这里的“好”有几个层次

首先，能满足大部分客户的核心共性需求。

其次，在满足需求的基础上，把体验做好。

再次，在体验完善的情况下，满足一些个性化的需求。

最后，才是想办法打造产品的生态。

对于个性化的需求，可以开放接口或者开放一段可编辑代码给到客户。对于服务型平台来说，我觉得功能不要做得太”重“，灵活性相对更重要一些。很多企业在这里做了很多客户不需要的功能，浪费了大量资源。把软件搞得很”重“。

对于服务方面，我认为改善体验也是服务的一环。体验是基础。除了产品体验外，接触用户和服务用户的过程也是可以做“体验管理”的。有几个关键点

1、信息传递要专业、高效。

现在基本都有客户群，但群里的工作人员，处理问题方面不够专业、高效。这就要求，公司不仅需要给一线接触客户的员工做好培训，而且还要授予处理突发事件的一定自主权。

关于培训，软件越复杂，培训越困难。所以要考虑建立一个问题清单库，让90%的问题，都能够很快速地找到解决方案。同时，需要让一线员工及时地更新问题清单库。

关于授权，这是一个度的问题。每个公司要自己去尝试和探索。水至清则无鱼，完美的制度，也是限制。这里面需要做好平衡。

2、响应客户的流程。

客户出了问题，想要找到对应人解决问题。这个时间需要多久？如果光靠微信群或者人的主动性来解决实时性问题，是不靠谱的。毕竟员工没办法24小时在线。要懂得用流程/机制解决问题。

比如，现在常用的工单。让用户提交工单，同时在提交过程中引导对方查看是类型问题的解决方案。这一块很多公司都有做，但是体验并不好。

同时，在员工端，要设置一个奖励机制。客户的通过抢单的方式，谁先抢到，并且能在一定时间内解决，这个客户的未来的续费就会拿出一部分用来奖励为这个客户服务过的员工。当然这一切都是匿名的。这样不管大小客户，大家都会抢单。

3、服务还包括功能的迭代。

现在做软件服务A客户提一个需求，平台收钱做出来后，有些还需要加钱给到其他客户。这种操作其实并不合适。反之，我觉得把需求列出来，让所有需要的人共同承担开发费用更为合理。当然这需要一个机制来同步所有人的需求。

用社区来管理需求也是一种方式，但实际可以做得更轻一点。专门做一个轻量级的需求管理的网站。这里的核心目的就是让需求以可视化的方式呈现出来。这样才能让客户更好地理解需求，搞清楚这个需求是不是真的需要。我感觉很少有企业在这块花心思。

很多ToB产品容易犯一个错误，就是在工具价值和服务体验都没做好的时候，就想办法去做模式创新，去做规模。这样就算前期跑起来了，产品和服务也跟不上。而且在快速奔跑中，还容易把一些问题隐藏起来，后期处理更麻烦。