工单系统——传动器的顶层设计

本文主要阐述了工单系统的设计思路，从2个方面，6个角度对工单系统的设计思路进行了拆解，希望能让你从顶层设计更加系统地理解工单系统。

本文主要阐述工单系统的设计思路。在前文中我们与大家一起回顾了工单系统的前世今生，本文我们将继续从2个方面，6个角度拆解工单系统的设计思路，让大家能够从顶层设计更加深刻地理解工单系统。

01 两个理念

工单系统设计的两个核心：高效协同和灵活适配。

1. 高效的协同方式

举个例子：

一天，客户小美找315投诉你们公司的维修员大壮，在修理空调的时候把家里的空调遥控器按坏了。

315将这个投诉单转给你们公司，你们需要复盘当时的维修工单，并且要求维修部门给出回复。

你们发现维修工单是两个月前，记录客户追评认为大壮修得很好；

你们拿到了维修部门的回复，大壮解释当时他发现了遥控器有点接触不良，但是没有在意；

最终经过向上级请示，你们给商城及仓库发了工单，要求给客户寄出一个新的遥控器。

你们在短短2天时间内解决了这个问题，客户机消协都惊讶于你们的处理速度。

小结一下：

在这里，2天解决这个问题和5天解决这个问题、以及7天解决这个问题，所需要花费人力、时间、损耗成本都是不一样的。

工单系统是现代企业管理的重要工具之一，其主要功能是为企业内部的不同职能部门、团队、员工之间协调和分配各项工作任务，以确保业务在高效、协调、有序的状态下运行。其中协同作为工单系统建设的核心，工单系统的建立让团队成员之间能够在一个共享的平台上便捷地交换信息、处理同一个问题，从而能更好地协调各项工作和提升工作效率。

此外，工单系统的特点也让他能够追踪所有的工单历史和状态，因此它能够传递大量的信息，包括工作任务的进度、工单的详细内容、客户反馈以及员工的评价等等。这些信息通过工单系统来实现分发和协调，确保各个职能部门之间能够调度适当的资源和负责相应的任务。

因此，工单系统从诞生起便带有信息传递的这种基因，注重在集中化的信息平台上优化企业内部的工作流程和协同，不断的优化自己的协同能力，从而使企业实现更高效、更顺畅的运营。

2. 灵活的业务适配

举个例子：

上文例子中，我们已经发现了维修工单、投诉工单，它们需要的工单信息、协调的处理团队都不相同。

现实中还有：合作方咨询工单、客户咨询工单、退换货工单等更多的工单类型。

这些业务场景中的处理流程还会随组织的发展而调整，例如架构调整导致流程变更、产品调整导致信息增加。

如果工单系统是一个需要产品甚至科技才能调整流程，那么每一次调整都需要花费时间、人员、财务成本；

但如果将流程、信息等做成业务人员可以直接调整的配置，那才能提高对于业务的适配性。

市场、业务的发展不会说等待系统建设好了再进行调整，工具如果制约了业务，只会被抛弃。

小结一下：

工单系统需要抽象出来业务流程，使用更灵活的设计思路，才能给它广阔的成长空间，可以让工单系统能够随着公司业务发展不断进步。

在功能设计上，遵循这个思路，工单系统会提供灵活的模板和配置选项，可以根据业务的具体需求进行自定义配置。由于它的这种灵活性，我们可以满足不同部门的在不同场景下的不同需求，在各种场景中都能为它们提供高效的业务流程和信息管理方案。

此外，工单系统的灵活性也意味着它可以随着业务的发展而不断进步。随着业务的不断演变和变化，工单系统的功能和性能也能够不断的优化和改进。

工单系统的灵活性是其最重要的两个特征之一，也是它能够成为现代企业管理工具的核心原因。这种灵活性赋予了工单系统广泛的应用和扩展能力，使得它可以与不断变化的业务发展一起进步，并提供越来越多的创新和高效的技术解决方案，从而帮助公司提升业务问题处理的效率。

02 四个思路

在工单的设计思路中，除了上述2个核心理念，还有4个工单系统在设计时需要遵循的设计思路。

1. 全面的场景覆盖

举个例子：

在上述场景中，如果工单系统仅仅只覆盖了客服一个部门，那么在仓库、维修、门店其他部门的衔接上就会脱节，工单处理的速度就会大打折扣；

如果工单系统仅仅只覆盖了投诉工单，那么就无法去查询维修工单，甚至无法了解维修时间、维修内容、维修结果，也就无法准确具体的给出合适的解决方案，更谈不上高效的协同方式。

小结一下：

综上，公司业务分散在各个不同的部门之中，做好全面的场景覆盖是工单系统设计时需要考虑的一个非常重要的问题。作为公司业务的主要协同工具，对场景的覆盖量决定了传动器的承载量，我们需要能够满足用户在不同场景的使用需要。假使只能承载一个或两个场景，那对于整个公司的业务可能不会有太大的帮助。

因此越早的能够统筹公司级别的业务协作系统，就更有机会面向更多的业务场景。同时工单系统在设计时也需要先梳理清楚企业内部大大小小的业务场景、协作角色，而不是从一开始就扎入客服、商城、门店、合作方、维修等各个部门的细分业务之中，这对产品经理也提出了更高的要求。

2. 及时的提醒通知

举个例子：

在投诉工单的场景下，投诉团队本身要处理日常的投诉工作，而如果不知道新增了这个工单，就没办法及时联系各方处理；

客服在咨询维修部门时，维修人员或部门运营也有自己的业务工作，并不是时时刻刻都盯在工单上；

最后商城和仓库也要承担自己日常的订单和发货任务，对于工单可能只是每天定时的查看和回复一次。

对于这里的各个角色：无论是客服、店员、维修员，都有自己的业务工作，在这种场景下，工单系统需要提供强大的提醒和通知功能。

每个环节的业务人员都能够及时发现和处理业务问题，用户也能及时地收到反馈，不再没有头绪地干等。

小结一下：

基于工单更高的时效要求，因此，在设计工单系统时，需要考虑如何让工单更加及时地被处理，以及如何让工单的处理进度更加透明。为此，需要在工单系统中设置提醒机制及时效监控，比如当工单处理进度发生变化时，系统会发出提醒，让协同方能够及时了解工单的处理情况。此外，系统还可以提供工单的统计功能，让协同方可以更好地了解工单的处理情况，以便更好地掌控工单的处理进度。

及时的把工单状态及处理进度同步各个协同方是非常重要的设计理念，不仅是为了给大家提供更好的协作体验，更重要的原因是能够大大提高协同效率，对于协同效率的追求是刻在工单系统的每一个设计思路之中。

3. 丰富的接入方式

举个例子：

在处理投诉的过程中，各个协作方其实使用的是各自的专业管理系统，例如：

• 客服们为了联系用户方便，使用的是能够呼入呼出的客服系统；
• 维修部门使用的是能够与订单、维修单、维修师傅关联的维修系统；
• 门店、商城、仓库也使用的各自的专业的管理系统；
• 用户也只能在前端APP和小程序中查看和咨询工单进度；
• 消保、合作方等外部更是有着自己的内部系统；

同时为了降低各个协作方的接入门槛，工单必须根据不同的系统要求，提供不同的接入方式。

小结一下：

面对内外部多角色的协同，工单必须提供丰富的接入方式，才能让它能够更灵活的嵌入不同的载体之中。

API接入是工单系统最常用的接入方式，它可以让业务部门更快捷地将工单系统嵌入到自身的业务系统当中，实现对工单的发布、查询、处理等操作，从而更好地管理工单。此外，页面嵌入也是一种常用的接入方式，它可以让工单系统的功能被嵌入到网页或者APP中，用户可以在网页或APP上访问、查看、处理工单，更加便捷。另外，H5也是一种常用的接入方式，它可以让工单系统的功能被嵌入到H5页面中，用户可以在H5页面上访问、查看、处理工单，更加便捷。

丰富而又灵活的接入方式，不仅降低了各个协作方的接入门槛和接入成本，也能让电脑、手机、群聊、邮件、业务系统等不同维度的载体都集合在同一业务场景下，进一步扩大业务场景的覆盖面。因此，工单系统最好是能够提供API、页面嵌入、H5等多种形态的接入方式，让业务部门灵活选用。

4. 全量的信息留存

举个例子：

在这次投诉处理的过程中，每个团队对信息的需要都是不同的。

投诉处理部门需要关注的是用户主要的投诉点以及需要希望解决的问题、和整体投诉处理时效；

维修部门需要关注的是上一个维修单的维修结果、维修人员是否有操作问题；

商城和仓库需要关注需要邮寄的商品、邮寄的时间、用户的电话、地址。

小结一下：

在上述例子中可以看到，为了达到高效协同的目标，工单本身也承担大量的沟通任务，而信息的全面记录才能保证各个协作部门对任务内容及各自需处理的事件理解一致，才能为沟通提供认知基础。

其次为了保证任务详情、任务流转原因，处理人处理记录等信息的及时同步，也对工单系统的信息记录提出了更高的要求。

综上，只有将任务中的创建内容、处理结果、各方需要协助的事项、整体的解决方案、其他方的咨询等业务处理过程中的业务日志信息完整的保存在工单任务中，才能做到让每个协助方都能在第一时间清楚的知道发生了什么？自己需要做什么？并且能够记录各个方面以及整体工单最终的执行情况，为后续可能发生的二次处理、数据分析提供准确的信息。

03 总结

整体的工单系统设计需要围绕高效协同和灵活适配2个核心的设计理念，以及关注全面的场景覆盖、及时的通知提醒、丰富的接入方式、全量的信息留存4个设计思路进行系统功能的设计。

下一篇我们将真正进入工单系统的功能架构。

​Read More