如何设计出一款灵活的工单系统？

Part1 核心价值

工单系统的核心价值是什么？

通过上图我们发现，当发现问题和解决问题不是同一人的时候，这里面就会涉及到信息传递的效率问题。

Part2 业务背景

如果你是发现问题的人，可以试着问自己以下几个问题：

• 我应该如何描述我的问题？
• 我的问题应该找谁处理？
• 我希望这个问题尽快解决吗？

如果你是解决问题的人，可以试着问自己以下几个问题：

• 这个问题的描述清晰吗？
• 如果不清晰我该如何让这个问题变得清晰？
• 我应该在什么时间前解决这个问题？
• 这个问题我解决不了怎么办？
• 现在有100个问题要解决，我应该先解决哪个？

等等。

可以看到，发现问题和解答问题之间有一个巨大的信息鸿沟需要解决。而解决的办法就是工单系统。

Part3 用户场景

我们首先梳理一下工单系统的典型用户：

• 工单提交者简称Q：客服、消费者
• 工单解决者简称S：运维、业务部门
• 工单监控者简称M：客服管理者、业务管理者

再来看一下他们的用户故事：

• 作为Q，我想要将消费者提出的问题记录下来，以便于查询或者转交给S解决
• 作为Q，我想要知道问题应该找谁解决，以便于问题可以快速定位并解决
• 作为Q， 我想要将问题转交给到相应的S，以便于S可以根据我记录的信息解决问题
• 作为Q，我想要根据S的要求提供更多信息，以便于S解决问题
• 作为S，我想要知道问题的详细信息包括问题描述、优先级、解决时间要求等结构化信息，以便于快速定位、解决问题
• 作为S，我想要在缺少部分信息的情况下询问Q获得更全面的信息，以便于解决问题
• 作为S，我想要在我解决不了这个问题的时候将问题交给其他S，以便于解决问题
• 作为M，我想要知道整体的问题处理情况，以便于了解服务质量
• 作为M，我想要知道Q和S的工作量情况，以便于及时发现工作量的问题并做调整

Part4 产品流程

根据以上用户故事，画出工单系统的核心流程：

Part5 产品设计

根据系统流程，我们可以总结出工单系统需要具有以下核心功能：

• 工单类型
• 表单模板

工单系统的高度灵活，也就是组成工单系统的功能模块的高度灵活，那上述核心模块如何做到高度灵活呢？

1. 工单类型

在设计工单类型的时候，我们可能会依据产品线、问题发生阶段、后果等维度来细分工单类型，为了实现高度灵活，我们就需要将工单类型的设置工作完全交给用户。

从数据存储的角度讲，每一个工单类型都是一条记录，在这条记录中，需要设计以下字段信息：

• 名称
• 层级
• 父类型
• 顺序

在表现形式上，可以使用多级菜单的模式：

需要注意的是层级、类型数量的边界设定，同时对于新增类型、层级内展示顺序、删除高层及类型的操作要想好产品逻辑。

2. 表单模板

工单表单是问题的结构化表达，我们在设计工单表单的时候应该尽量将问题的信息结构化，便于S获得全面信息及数据分析。而模板是为了应对不同的业务场景需要，不同的场景对应不同的模板。

为了达到结构化和高度灵活这两个目的，表单模板需要具有以下特性：

• 模板与表单一一对应
• 模板依据工单类型划分
• 字段可以增减（必填字段除外）
• 可以增加自定义字段
• 字段顺序可以调整

表单模板原型图如下：

在设计模板字段的时候，我们可以默认添加工单中可能用到的字段，但为了覆盖尽可能多的场景，还需要设计添加自定义字段的功能，包括字段名称、字段类型等。

除了工单类型和表单模板，工单的流转、消息通知、回复、操作记录等并没有提及，我认为这些是标准功能，并无设计高度灵活的必要性，暂不列出。

Part6 总结

由于B端业务的多样性，我认为SaaS产品设计需要将灵活性放在足够重要的位置，因为灵活性决定场景覆盖范围。在产品设计时，产品经理应该根据现状和未来发展将需求、场景尽量抽象，设计出灵活的产品方案。

灵活性必然带来开发工作量的增加，二者如何取舍？我们可以聊一聊。

本文作者 @万旗 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！