为什么觉得工单的效率低？
和语音聊天、 IM 沟通，工单系统作为一个「问答」形态的产品，必然带来是消息回复的不那么及时，你也很难像 IM 一样，一波语音通话，直接打过去，让对方的同学接听。 但，这就意味着效率低么？
也不尽然，我们觉得语音通话和IM 沟通能够提高效率是因为 能够在很短的时间内尽可能多的传递信息给对方。但这并非语音通话和 IM 沟通才能提供的，实际上，我们用好异步交流的方式，同样，甚至可以更好的传递信息。正是因为你将工单系统当作 IM 系统来使用，才造成效率低。
什么是好的工单系统的用法？
工单系统的异步沟通回复实效性差，但相应的，也倒逼我们必须在尽可能少的消息当中补充足够多的上下文，帮助工单服务人员来更好的协助我们巡查问题。比如，附带上出问题的条件和代码、提供信息帮助对方定位、提供复现的方式（是不是觉得很眼熟？我们在开源社区也被要求在提交 issue 的时候尽可能多的提供信息）。 当我们提供了尽可能多的信息的时候，我们才能更好的让工单系统起到作用，才能更好的传递信息，解决我们的问题。
工单引发的全局最优和局部最优的思考
从工单系统出发，我又想到了一个话题 —— 「全局最优和局部最优」。我们常说，要追求全局最优解，而不是局部最优解。就比如腾讯停止某个不那么擅长业务，显然，从局部来看，对于负责对应业务的同学来说，这不是一个最优解。但对于公司层面来看，释放人力去做更有价值的事情才是最优解。
为什么会选择工单？
和语音通话/IM 沟通相比，工单系统的优势在于何处？语音通信和 IM 沟通虽然可以很方便的将信息传递，但对于信息的沉淀和再次利用，并没有什么帮助。实际上用户并不会主动在历史当中搜索。
你会发现，用户并不会主动搜索历史问题，他们更喜欢直接提出问题，然后等待解决。 既然如此，那工单系统所承载的服务，自然也就能够提供不同的和更加强大的能力，帮助 oncall 同学来解决服务的压力。
工单并不完美
当然，现在的工单系统并不能做到想要的最优，比如在我看来，这里还有很多东西是我们没有做到的，比如自动记录用户进入 oncall 页面的 path（这样 oncall 同学可以直接知道用户是在哪个模块出现的问题）、自动记录提示用户选择 service id（这样就不用每次都提醒用户输入 service id）、自动根据用户输入的信息提供可能的回复。
可以看到，这里面其实是有很多的 gap 没有处理好的。也正是这些没有处理好的事情，让现在的 oncall 系统看起来不那么的美好。 但你我都知道，事情总是在演进的，现在不好不意味着他不能让事情变得更好。让工程师直接提供 oncall 固然可以让服务变得更好，但对于业务的可持续性、成本的优化和不断的产品迭代来看，并不能算是一个最优解。
而客服系统其实是一个标品，我们会看到 ZenDesk、Tawk.to、Intercom等等一系列的客服系统，都在提供服务，从某种角度上来看，这验证了客服系统/工单系统的方向的正确性。而一个好的客服系统，应该是让用户很快得到帮助（比如自动帮助用户搜索问题），让工程师可以更加专注（比如把问题的解决更好的总结成经验）。
