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

专业真的很重要!产品总监手把手教写文档,10天训练营,系统学会产品经理必备7大文档能力。了解一下>

围绕工单系统,本文将介绍它的价值、业务背景、用户场景、产品流程、产品设计,向大家分享如何设计一个灵活的工单系统。

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产品设计需要将灵活性放在足够重要的位置,因为灵活性决定场景覆盖范围。在产品设计时,产品经理应该根据现状和未来发展将需求、场景尽量抽象,设计出灵活的产品方案。

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

 

本文由 @万旗 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自 unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 解决工单问题——是否需要更多信息,这步需要在工单系统沟通吗?为什么不能用钉钉/沟通软件沟通,在工单系统沟通的目的是什么?留痕迹吗

    回复
    1. 嗯嗯,漏掉了一条“否”的分支。沟通的场景是问题解决人需要获得更多关于问题的信息才可以解决问题,所以需要基于工单进行“跟帖回复”。而IM是脱离了工单这个流程场景的,无法将工单信息与回复信息关联。

      回复
    2. 我作为一个企业员工,不可能常常登陆工单系统看是不是我的工单有人回复我了。
      做了这个功能,是不是实际场景会是:it小王看到A工单,描述不清楚,回复了工单,A工单的发起人小张5天后想着去看看工单被解决了没有,才看到了这条回复信息。
      整个流程变的很复杂,如果上述场景时长发生,可能功能会废掉(it人员根本不用,直接在钉钉询问下,立刻就能得到问题的答案,立刻就可以解决这个问题)

      回复
    3. 嗯,明白你的意思。所以这种通知至少需要两种渠道:产品内,产品外。产品外可以是短信、邮件等。

      回复
  2. 产品流程图画错了把,是否需要更多信息的否那条线呢?

    回复