一个真实的服务困境

成都立信笨鸟，川内服务了2000多家网吧。
远程部十几个工程师，每天通过【企业微信建群】的方式，为这些网吧提供线上技术支持。

听起来很标准，对吧？

但只有真正在一线干过的人才知道，这种模式有一个巨大的隐患——漏单。

2000多个群，消息随时在跳。工程师轮班倒，难免有消息被刷过去。客户在群里发了问题，迟迟没人响应。一次两次还好，次数多了，客户信任就会一点一点被消耗。

第一次尝试：技术方案，但走不通

立信笨鸟不是没有努力过。

他们之前尝试了一个方案：结合企业微信会话存档，设置群聊质检规则。一旦超时未响应，系统自动向相关人员及管理层拨打电话，提示漏单。

听起来很合理，但实际跑起来，问题接踵而至——电话太频繁，被封号了。

而且，海量的群聊消息提醒红点，让每一个工程师都必须把每一个红点点掉，无论这个群里是不是真的需要服务。

更麻烦的是，复杂的问题能躲就躲，没有人愿意主动接难活。

技术方案走了两条路，都堵住了。

第一次交付：功能上线，一个月后发现没人用

云路天行介入后，给出了第一版方案：

利用企业微信会话存档的能力，增强会话管理功能。群聊消息发出后，立即在后台生成服务提醒。

当班人员通过上下班时间，动态更改分单规则的责任人，系统按责任人顺序自动分配服务任务。

服务人员在后台填写服务记录并发起工单。

逻辑清晰，功能完整。

这个项目，开发费收了5000元。

按照正常的商业逻辑：交付验收→客户确认，项目就结束了。
但一个月后，我们看了一下后台数据——完全没有人用。

第二次迭代：体验优化，依然败给习惯

为什么没人用？

我们和一线工程师聊完，才发现一个关键问题：在服务诉求比较集中的时候，工程师根本没有时间去填服务记录。这个分单系统不但没有帮到大家，反而成了一个额外的负担。

于是我们立刻做了第二次迭代：

• 在服务提醒页增加快速进入企微群聊的图标，点击图标即自动变为“已响应”状态

• 修改会话管理接口，客户每发一次消息就更新未读消息数据

• 每一次点击自动刷新页面，让工程师实时知道还有多少条未读

我们以为这次应该没问题了。
但现实很快给了我们第三课——体验优化，败给了使用习惯。

工程师们习惯了原来的工作方式，新系统虽然好用，但大家还是下意识地绕过去。

第三次介入：从软件到绩效管理

我们意识到，光靠功能优化是不够的。

于是我们专门做了工作负荷统计表，主动关注系统的使用情况。一旦发现有累积的任务未处理，就主动联系立信笨鸟的负责人，了解原因、寻找对策。

最后，我们主动提出了一个更大胆的建议：结合绩效方案来管理。

• 响应时限：5分钟

• 处理时限：2小时

在工作负荷统计表中，增加超时数据统计，按超时次数扣除相应绩效。

这个方案得到了立信笨鸟管理层的认可。

从那一刻起，每一条服务请求都落实到人，制度上保证了及时处理，服务效率发生了质的改变。

客户成功不是口号

回过头看这个项目，有几点很值得说：

• 5000元的开发费，我们干了远超这个价格的事。功能交付之后，我们主动做了两次体验迭代，又主动介入到立信笨鸟的绩效方案设计中。这不是合同要求的，是我们自己觉得应该做的。

• 客户成功的核心不是交付功能，而是让功能真正被人用起来。再好的系统，如果一线人员不用，那就是零。而要让他们用起来，光靠体验设计不够，有时候必须深入到客户的管理制度中。

• 这也是老客户不断回归的根本原因。很多企业出去比较了一圈，最后还是回到云路天行平台。因为大家发现，比功能更稀缺的，是一家公司做事的态度。

云路天行一直有一个朴素的理念：收钱不是目的，客户成功才是追求。

这个理念不是写在墙上的口号，而是在一个项目里，我们愿意花多少力气去较真、去迭代、去主动超出预期。

一个系统能不能真正帮到客户，不在于它有多复杂的技术，而在于做这个系统的人，有多在意它是不是真的被用起来了。

这，就是云路天行的答案。

更多解决方案：云路天行