工单系统的状态设计为何屡遭用户吐槽？从只有进行中和已完成两种状态的简陋逻辑，到多角色协同下的状态流转难题，本文深入剖析工单系统设计的核心痛点，揭示状态流设计如何影响任务监管效率，并提供兼顾通用性与易用性的解决方案。

上周跟同事聊天，说到我们公司目前的工单系统，他抱怨说：“这个工单系统的状态设计的太不合理了，只有进行中和已完成两种状态，用户在追踪进展的时候根本无法了解更详细的内容，害的我们在项目中经常被客户质疑，经常被要求做定制化需求……”

这里先说一下我们公司工单产品的设计背景，我们部门设计输出的工单产品其实是基于多个不同的项目需求提取出来的通用化需求，为了满足不同项目上的不同的定制化需求，往上提取聚合，形成了一套满足大部分项目需求的一套解决方案，但由此产生的问题也显而易见，那就是逻辑太抽象，用户一时理解不了；或者就是易用性太差，看似满足了大部分项目需求，实际使用起来，非常难用。

同事反馈的问题，就是由此忽略了任务监管者一个最重要的业务场景，就是任务进度的查看和跟踪，这在任务跟进的过程中是一个核心的业务需求，“当前任务到哪一步了？”“卡在哪里？负责人是谁？是否需要进行催办等”，因此对于任务的监管者来说，状态流的详细展示就是一个很重要的信息要素来帮助用户识别具体的任务执行进度以及是否有必要进行进一步的催办协调。

当然这里同时还隐藏着一个隐含的逻辑，那就是是否有超时机制，正常来说，任何一个任务的完成都有明确的时间要求，除非特殊情况，否则不会一直卡在一个环境不动。因此，若当任务即将超时或已超时时，任务负责人是需要进行相关的催办、协调等一系列操作来帮助任务的正常流程的。

很多团队在设计工单状态时，常常都会陷入以下误区：

• 状态太少：只有进行中和已完成两种状态，当一条工单任务下发下去之后，作为监督者进行进度跟踪和把控时，无从下手，进行到哪一步了？卡在哪一步了？无从知晓，也无法进行相针对的催办措施。
• 状态太多且混乱：设计了太多的状态：待分配、已分配、待处理、待验证、已验证…，客户无法区分不同状态的含义。

首先，工单系统通常来说分为几个大的核心流程：

下发任务–审核任务（可选）–处理任务—验证结果—结束

在不同项目中，不同流程节点具体的任务操作可有不同，比如说，审核流程可有可无，可多人审核，也可单人审核；处理任务节点，一般情况而言，处置人为同一团队的一名或多名用户，若存在多层级的组织架构，那么任务的处置可能涉及不同层级的用户操作。下发任务和验证结果流程节点也是同理，随着项目的不同，详细的流程节点随之变化。因此，在通用化的工单系统设计中，业务节点的流转是必不可少的配置环节。

同时还要补充说明的是，在业务流转时，有时候一个父任务需要多个不同部门/角色的人分别同时执行，这种情况下就需要考虑多条子任务状态与父任务状态之间的对应关系了。比如，单个子任务的状态进展不同，如何映射到父任务，父任务的状态变更机制依据什么样的子任务状态进行变更。不同子任务的状态是否需要分类统计和展示。举个栗子，一个任务同时给多个客服下发，要求反馈自己的工作报告，那么每个客服收到都相当于是一个子任务，每个任务的进展和状态都是独立的，那么我们在为任务发起人做进度展示时，首先需要考虑的是父任务整体的进展展示，其次才是不同子任务的具体执行进展，而所有子任务的执行进展则会反向影响到父任务的进度，因此可遵循金字塔信息结构，先展示总体的进展，其中可包含整体的进度统计，其次再对不同的子任务状态进行归类，相同进展状态的可统计为一类，这样用户可看到进一步的子任务的执行情况，若用户想针对性的查看某一类状态下都有哪些人为执行，可点击卡片查看详细的人员列表。

其次，在工单系统中，最重要的一个信息要素，就是角色，不同角色的用户负责不同的流程节点，也就是说不同类型的角色，可能对应有不同的状态流，比如说审核者的状态只有待审核和已审核；执行者的状态只有待处理和已处理两种状态；而对于任务的发起者或者监督者，就需要有全部的整体的状态流转，从待下发、待审核、待处理、待验证、待归档等。若不区分不同角色，就将状态混为一谈，就会造成“线路不清晰、流程无法追溯”等多种问题了。

再者，针对状态的变更触发机制，一般而言需要依据不同用户角色所负责流程节点，由不同角色的用户手动进行触发，例如审核者审核之后，状态需要由待审核变更为已审核；执行者执行完成之后，则状态则需要由待执行变更为已执行。但若存在多条子任务的情况，则需要考虑父任务的变更机制，不再是人员触发那么简单，而是由系统监测自动触发辨认，例如当多条子任务都是待执行时，则父任务也应为待执行状态；而当所有子任务的状态都变更为待验证时，则夫人吴状态也应该变更为待验证状态。

最后，针对上面提到的超时机制，若任务临期或超期了，则需要有手动或自动的报警机制。

总而言之，状态的设计首先需要遵循客户的实际业务流程，满足用户对任务过程的管理和管控需求，要能够对用户透明化、简单化，能够让用户在跟踪过程中有条不紊、心中有数。其次需要考虑多角色的业务流以及不同的业务场景的支持。

你在设计内部工单系统时，都有哪些头疼的问题呢？欢迎在评论区交流。