工单系统要如何搭建设计策略，才可以使系统更好地落地，并给到使用者足够好的系统使用体验？也许你需要在功能架构维度上多下功夫。本篇文章里，作者便针对工单系统功能架构中的几个支撑性模块，做了设计理念、设计策略上的拆解，一起来看。
【资料图】
前言
本文继续阐述工单系统-高效的功能架构，中篇的5个支撑性的模块分别为：工单管理、工单工作台、工单时效、工单通知、工单监控，主要解决的是工单系统的使用体验是否足够好的问题。工单系统在体验上的优化大部分优化以及小部分在效率上的优化会通过这五个功能模块来完成。
同时这五个功能模块的设计理念也紧密围绕高效协同和灵活适配，在这五个模块中仍然能够看到大量为了更高效、更灵活做出的功能架构设计。
一、工单管理
工单管理主要聚焦“一个工单，创建—>处理—>关单的流程”中都需的要素，以及每个角色能够在对应的环节中做些什么。主要分为工单创建配置、工单处理配置、工单关单配置三个部分来阐述。
1. 工单创建配置
首先我们来说工单创建的部分，工单创建配置主要是两部分，工单渠道配置和工单建单信息。
1）工单渠道配置
工单可以来自于多个渠道，越优秀的工单系统的渠道也会越多；例如：
将创建工单的入口嵌入在APP中，鼓励用户自助建单； 在智能客服中嵌入工单模块，帮助用户智能建单； 给供应商提供系统接口，帮助供应商建单； 客服系统、售后维修系统、门店系统等自身业务系统中的建单渠道等等。越多的渠道和入口也就代表了工单体系的生态就越好，有更多的参与方能够一起参与进来，也有更多的场景能够被覆盖；这里要注意不同的渠道能够创建的工单是有差别的，因此需要根据渠道配置不同的工单分类。
2）工单建单信息
其次是工单的建单信息，工单建单信息一般包括两类：
一是能够被标准化的用户信息例如身份证号、手机号、用户姓名等、及能够被标准化的商品SKU、商品名称、所属供应商等商品或订单编号、下单时间等订单这些业务信息和工单本身的一些信息。 二是无法被标准化的配置类信息，这种信息一般都具有很强的业务属性，会根据业务的发展阶段，不断变化。因此我们会提供标准模版，并且支持业务人员加入自定义配置的业务所需要的信息和字段。通常在功能架构的设计中第一类信息会被设计成系统可以帮助用户自动抓取的形式，来减少工单创建的工作量，提高用户体验和建单效率。
2. 工单处理配置
工单处理主要聚焦用户如何处理和协助处理工单，其中包含“当前处理人”和“第三方协助人”两个部分。
1）当前处理人
工单的当前处理人在处理工单过程中可以进行的操作主要有：处理记录、发起任务（前文中子流程的概念）、流转、上传附件、关单。在设计理念中，工单处理人对工单有完全控制权限，因此工单当前处理人拥有这个工单的最高权限。这里我们重点阐述一下处理记录和发起任务两个功能：
处理记录：工单会在处理人手中进行综合处理，在这个过程中，工单需要记录下来处理人的每一步动作，因此我们会给处理人一个处理记录的功能，以时间线为主维度将处理人的每一步处理都记录下来，来保证工单进行回溯或者数据分析时的数据完整。 发起任务：在前文中我们给工单设计了子流程的逻辑，这里的发起任务主要用于当处理人判断该工单需要其他的第三方进行协助时，可以通过发起任务功能，选择发起一个或多个子流程，寻求其他的协同方一同处理当前工单。2）第三方协助人
第三方的协同人可以对工单进行的操作一般包括评论、备注、加急、回复任务等功能。
这里重点关注下备注，我们为第三方设计的无论是评论还是备注或者是加急，其实本质上都是在工单本身信息之外的其他补充性的信息预留的功能设计。将工单主动性交给处理人。
例如原本和维修师傅定的是早上10点去维修，但客户突然联系客服说晚上6点才有时间，这时候我们可以在备注中对维修工单进备注。或者原本投诉部门准备下午3点回访用户，但是用户找客服要求现在就要回复，客服可以对工单进行加急。
第三方主要做的是协助处理的工作，将需要告知处理人的信息告知处理人即可，并不能对工单做进度调整、内容修改等其他操作。当然系统可以针对一些动作做处理，例如客服加急之后，可以提高这个工单的优先级，工单被评论后，会在待办列表中置顶展示等等。
3. 工单关单配置
工单的关单配置主要包含两个部分：关单权限配置和关单信息。
1）关单权限配置
工单在流程中会配置某一个流程节点的处理人是不是可以作废、关闭当前的工单。
例如一个升级逻辑的流程，客服-客服组长-部门经理。如果客服组长已经解决了用户的问题，那么其实无需到经理节点，组长就可以直接关单了。这些在主流程中的逻辑配置是工单处理层也需要关注的。
2）关单信息
关单信息的重点一般在关单类型，常见的关单类型有客户满意关单、未达成一致关单、联系不上关单这三种类型，这三种类型分别对应最常见的三种处理结果：
客户满意关单：工单处理完成后处理结果客户很满意，没有其他问题，关单结束； 未达成一致关单：和客户根本达不成一致，诉求满足不了，多次沟通未果，关单结束； 联系不上关单：压根没联系上客户，关单结束。其他需要关注的还有需要配置在关单流程中需要客服补充填写的关单信息，因此也需要在关单环节对关单填充信息进行配置。
4. 小结一下
工单管理模块中的功能主要关注在工单本身的功能上，包括需要在哪个流程为哪些角色提供哪些具体的功能。这些具体到工单的功能设计对用户体验的影响是非常重要的，大多数用户感知比较强的功能优化也集中在这个模块，因此要警惕不要因为这个模块做起来很有成就感就顾此失彼，忘记对核心模块的改造才是提升效率的重点。
二、工单工作台
业务工作台是业务人员的主要工作台。在这里需要的就是把业务人员手中的工单，帮助他们进行分类整理，便于业务人查找和处理，减轻业务人员在处理工单之外的工作任务。主要包含以下三个模块：
1. 已处理工单
用来存放业务人员已经处理过的工单，一般存个7天内就够用了，比如业务人员创建的工单，可能会担心工单是否创建错误了，或者担心刚刚需要创建的工单是不是已经创建过了，也可以用来在工作即将结束的时候对自己这一天的工作进行复盘，工单是否都正确创建和处理，有没有漏单的情况等。
2. 待处理工单
用来存放当前并不需要处理的工单，例如维修时间不是今天的工单、回访时间不是今天的工单、已经发了任务，要等子流程回复的工单等等，暂时不需要处理的工单。这个模块的工单是可以在触发一定条件后转移到处理中的工单列表中，例如被加急、任务被回复、被评论等情况。
3. 处理中工单
用来存放当前需要处理的工单，一般会按照处理时间排序，因此这个列表需要进行优先级的设计。把处理时间、紧急程度、工单类型进行综合评估，给出合适的优先排序，工作人员只需要关注工单本身，根据优先级挨个处理工单即可。
4. 小结一下
工单工作台是工单业务人员主要的工作台，尤其是作为B端工具，用完即走真的是它的核心逻辑，不要让业务浪费太多时间在工单的处理等等其他事务性的工作上。因此工作台要做的就是帮助业务人员集中精力在工单本身的处理上，将排序、思考、复盘等能帮助业务人员解决的问题都一一解决，这对于用户体验的提升是非常大的。
三、工单时效
在讲工单通知和工单监控模块之前需要先将工单时效配置的功能模块穿插进来，它是通知和监控的基准。
通知和监控都需要有一个比较合理的标准，而对于工单系统来说，也需要这样一个标准来不断推动和指引工单系统的不断进步。
工单时效配置就是这样一个功能，它是工单监控模块的基础功能，也是整体工单系统设计中的画龙点睛之笔，它将藏在工单系统深处的设计目标以最直接最明确的数据形式展示在业务人员、运营人员和管理层面前。
1. 工单时效设计
工单时效的设计会贯穿整个工单的处理流程，最重要的四个时效有：回复时效、处理时效、流转时效、关单时效，这四个时效是涵盖一个工单整体生命周期的基础时效。
回复时效：指的是创建工单后第一次回访用户的时效； 处理时效：指的是业务人员每一次处理工单的间隔时效； 流转时效：指的是工单工单每个节点的处理时长； 关单时效：指的是工单整体的关单时长。 2. 工单时效配置同时，不同的业务部门、不同的业务场景、不同的工单流程，处理时效也是需要根据具体的工单分类设计情况进行设计。因此设计该功能的作用是针对不同的工单配置不同的回复效率、处理时效等等，为后续的工单监控和工单提醒提供标准支撑。
因此对于工单来说时效的配置必须是画龙点睛的功能点，能够和敢于把工单时效概念提出来，正视工单处理时效的业务部门，才会真正花费力气再不断地提升工单的处理时效上，不断地提高工单处理效率。
3. 小结一下
工单时效的关键在于业务部门，这里需要和业务部门进行充分沟通和论证，在业务部门的支持下进行工单时效的设计。主要原因在于时效设计不能单单只是一个时效设计，设计本身并不困难，但是这个时效的作用是给到业务部门的运营和管理人员关注，通过持续不断的优化，提升工单的各个时效，从而提高工单的处理效率。
如果做的好，工单系统的效率能提升一倍，如果做不好工单系统也只成功了一半，所以它是画龙点睛的一笔。
四、工单通知
工单系统涉及的业务部门和协作方非常多，专注于协作的工单系统，必然需要为使用系统的人员提供更及时的系统通知，因此工单的通知模块就显得尤为重要。
1. 通知触发配置
工单触发主要通过时效部分配置，以及一些监控设置，在到底一定阈值的情况下，会触发通知提醒，提醒的设计会在工单监控模块重点阐述，这里主要是说明一个工单的提醒其实是两个模块共同作用的结果，需要做好联动设计，防止后续返工在产品设计和开发上面增加不必要的工作量。
2. 通知渠道配置
在上文中用户能够从哪个渠道发起工单，理论上通知的渠道就要能够触达到哪里。甚至在实际的工作场景中，我们通知的设计会更加的深入。这个设计主要是方便将工单的处理状态及时的同步到关注工单的各个部分，当然最重要的通知是当前处理人。
例如有其他协助方回复工单的时候，如果处理人没有关注工单系统，我们可以通过企业内部的IM系统（例如飞书或者钉钉等）通知用户，这样用户才可以第一时间收到通知去处理工单，对于更高级别的例如投诉工单下发的任务到达协助方之后，我们甚至会下发短信或智能外呼去及时通知用户，以提高工单的处理速度，快速解决问题，防止工单事态的进一步升级。
3. 小结一下
工单的通知模块可以理解为工单的消息中心，和所有业务系统的消息中心一样，它是工单系统的传声器。这一个部分的关键在于消息分级；不同等级的消息提醒，触达渠道不一样、触达方式也不一样。例如最高级的投诉通知，可能就需要通过短信直接发送到业务人员的手机上；而最低级的新工单提醒，只需要在工单系统弹出提醒一下，看不看都不会影响业务人员的处理。
五、工单监控
监控模块主要是协助业务管理者以及工单系统的运营人员能够及时关注工单整体的处理情况，及时发现工单积压、工单超时等问题，通过人员调度、资源协调、智能调整等手段对进行调控。保证工单整体，及时有序的处理完成。并且工单监控也能够提供工单处理人某些工单需要及时处理，某些工单已经超时需要尽快处理等。工单监控部分分为三个部分，工单监控看板、工单监控提醒、工单预警监控。
1. 工单监控看板
工单监控看板的主要作用是通过一系列的工单数据看板，展示工单整体的运营情况。它就是管理者和运营人员的眼睛，辅助他们了解工单整体的状况，对工单处理、人员情况、运作状态做到心中有数。工单看板重点关注两个部分：
1）工单处理情况
以不同工单分类为维度展示的工单创建量、工单处理量、工单回复效率、工单关单时长，工单超时任务量等指标，对每个场景下的工单处理情况进行监控，确保能够及时发现工单处理中的问题；
2）人员处理情况
包括处理组的在岗人数、正在岗时长、工单未处理量、待处理量、已处理量、工单回复效率、工单回复时长等看板等数据，以及处理人今日已处理、当前未处理、平均关单时长、即将超时工单量等等；
因此工单监控看板对实时性的要求非常高，要的就是实时数据，数据刷新要求一般在2s以内。当然不同公司、不同管理者之间也有误差，有些不那么关注的10s他也能接受，那就没有必要设计的那么实时，这些需要产品经理现场把握了。
只要能够从各场景工单处理情况、各处理组处理情况、各处理人处理情况三个大的维度整体考虑，对工单系统的生态运营情况进行监控，保证工单体系的运营流畅即可。
2. 工单监控提醒
这个模块的主要目的在于提醒， 设定一定阈值对工单运行情况进行监控，并及时通知业务人员、管理者以及运营人员。提醒的重点在于督促被提醒人马上做出改变。
例如工单即将超时提醒，这个监控的被提醒人就是工单处理人，提醒的目的就是让业务人员尽快去处理这个工单，不然这个工单马上就要超时了。而例如工单超时未处理提醒，就是让处理人立刻、马上去处理该工单。
这个模块会和工单通知模块进行联动，对工单监控中的提醒确认好提醒的等级，并且配置不同的触达渠道和触达方式，来达到提醒的作用和目的。
这里也能看出监控看板和监控提醒两个功能的侧重点不同、面向角色不同、想要达到的效果也不相同。
3. 工单监控预警
预警的重点在于对即将发生的风险进行提前干预，防止没有及时干预导致的投诉等其他风险，因此预警的重点在于提前发现问题。
例如关键词预警，配置某些工单关键词例如提及投诉、报警、诈骗等敏感词，在命中规则后会自动将工单升级到投诉部门进行及时回访，避免可能引起的投诉、诈骗问题。当然在实际的业务场景中，一般工单监控预警是多命中规则合并的更加复杂的处理逻辑，仅凭借单一逻辑判断，无效命中或者误命中的概率很高。
根据真实的实践经验工单监控预警这一部分设计起来的复杂度和难度简直赶得上工单系统的设计难度。
但一定要相信这条路一定是能走的通，如果不顺畅可能只是需要换个现实一点的目标或者熬过这段痛苦的过程。
也可以考虑加入更加强大的人工智能工具，例如GPT，加入进去说不定能找到更快、更准、更好的实现方案。
4. 小结一下
工单监控模块对于提高工单处理效率的重要性，是这五个支撑模块中最直接、最重要的。但是这一块也是最不好做、最容易出现问题的地方，当然也就代表了做好是最出彩的。
我们在实际处理中需要关注以下两个点，就能大大提高成功的可能：
第一点在于监控的准确性，最好是我们能够说服业务部门在工单时效模块投入精力，这样有准绳的监控才能做的更准确。 第二个问题这些都是数据性的工作，想要真正提效需要业务部门有对应的运营手段，例如大部分被提醒的场景都是业务人员已经在努力做了，但是仍然不能做完，这时候你提醒再多也没有作用，最需要做的其实是和运营人员联合做一些功能优化或者加入一些智能手段去调控工单。 六、总结从工单管理到工单监控，从用户体验到工单效率，其实这五个支撑性的模块作用一点也不弱于上一篇的核心模块，支撑性的模块是功能架构的基础，没有基础核心设计的再好也没有用武之地。无论是基础还是核心，都是工单系统需要关注的重点，他们是相辅相成的关系。下一篇我们会对工单架构篇做个总结，中篇的五个模块到这里就先结束。
本文由@zxx 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
责任编辑：
