white crt tv turned on beside white remote control

工单效率这么低,为什么还要选择工单服务?

为什么觉得工单的效率低?

和语音聊天、 IM 沟通,工单系统作为一个「问答」形态的产品,必然带来是消息回复的不那么及时,你也很难像 IM 一样,一波语音通话,直接打过去,让对方的同学接听。 但,这就意味着效率低么?

也不尽然,我们觉得语音通话和IM 沟通能够提高效率是因为 能够在很短的时间内尽可能多的传递信息给对方。但这并非语音通话和 IM 沟通才能提供的,实际上,我们用好异步交流的方式,同样,甚至可以更好的传递信息。正是因为你将工单系统当作 IM 系统来使用,才造成效率低。

什么是好的工单系统的用法?

工单系统的异步沟通回复实效性差,但相应的,也倒逼我们必须在尽可能少的消息当中补充足够多的上下文,帮助工单服务人员来更好的协助我们巡查问题。比如,附带上出问题的条件和代码、提供信息帮助对方定位、提供复现的方式(是不是觉得很眼熟?我们在开源社区也被要求在提交 issue 的时候尽可能多的提供信息)。 当我们提供了尽可能多的信息的时候,我们才能更好的让工单系统起到作用,才能更好的传递信息,解决我们的问题。

工单引发的全局最优和局部最优的思考

从工单系统出发,我又想到了一个话题 —— 「全局最优和局部最优」。我们常说,要追求全局最优解,而不是局部最优解。就比如腾讯停止某个不那么擅长业务,显然,从局部来看,对于负责对应业务的同学来说,这不是一个最优解。但对于公司层面来看,释放人力去做更有价值的事情才是最优解。

为什么会选择工单?

和语音通话/IM 沟通相比,工单系统的优势在于何处?语音通信和 IM 沟通虽然可以很方便的将信息传递,但对于信息的沉淀和再次利用,并没有什么帮助。实际上用户并不会主动在历史当中搜索。

你会发现,用户并不会主动搜索历史问题,他们更喜欢直接提出问题,然后等待解决。 既然如此,那工单系统所承载的服务,自然也就能够提供不同的和更加强大的能力,帮助 oncall 同学来解决服务的压力。

工单并不完美

当然,现在的工单系统并不能做到想要的最优,比如在我看来,这里还有很多东西是我们没有做到的,比如自动记录用户进入 oncall 页面的 path(这样 oncall 同学可以直接知道用户是在哪个模块出现的问题)、自动记录提示用户选择 service id(这样就不用每次都提醒用户输入 service id)、自动根据用户输入的信息提供可能的回复。

可以看到,这里面其实是有很多的 gap 没有处理好的。也正是这些没有处理好的事情,让现在的 oncall 系统看起来不那么的美好。 但你我都知道,事情总是在演进的,现在不好不意味着他不能让事情变得更好。让工程师直接提供 oncall 固然可以让服务变得更好,但对于业务的可持续性、成本的优化和不断的产品迭代来看,并不能算是一个最优解。

而客服系统其实是一个标品,我们会看到 ZenDesk、Tawk.to、Intercom等等一系列的客服系统,都在提供服务,从某种角度上来看,这验证了客服系统/工单系统的方向的正确性。而一个好的客服系统,应该是让用户很快得到帮助(比如自动帮助用户搜索问题),让工程师可以更加专注(比如把问题的解决更好的总结成经验)。

发表评论

您的电子邮箱地址不会被公开。