帮助台软件：打造经得起考验的工单流程

帮助台软件只有在支持清晰的工作方式时，才能发挥最大的作用。购买工具并不能决定谁负责处理请求、工单何时应当等待，或什么情况才算解决。你的团队必须先做出这些决定。

本指南将向你展示如何围绕现有的支持邮箱设计实用的工单工作流。重点是运营模式，而不是功能对比。如果你想了解电子邮件、分配、状态、优先级、标签、备注和工单历史如何在同一款产品中协同运作，请在完成以下步骤的过程中查看 Deskhero 的共享收件箱和工单功能。

从客户请求应当遵循的路径开始

在进行任何配置之前，先画出从请求到达直到解决的正常路径。一个实用的初始版本可以很简单：消息到达，有人进行审核，合适的人接手负责，团队完成工作，客户收到最终答复。

然后列出那些经常打破这一路径的例外情况。账单问题可能需要另一个团队处理。技术问题可能需要调查。客户可能不再回复。两条消息可能描述的是同一个问题。这些情况会告诉你工作流需要哪些状态、交接环节和保障措施。

让流程图围绕决策展开。对于每个阶段，回答以下问题：

• 谁负责下一步行动？
• 工单继续推进前，必须具备哪些信息？
• 负责人无法处理时应当怎么办？
• 其他 User 无需询问摘要，如何才能了解当前状态？
• 什么事件意味着请求真正完成？

当任何 User 打开一张工单后，都能知道发生了什么、接下来会发生什么，以及下一步由谁负责时，这个工作流就是健康的。

使用一组精简且含义明确的状态

状态名称看起来往往很直观，但不同团队的理解可能并不一致。根据谁需要采取下一步行动来定义每个状态。仅这一条规则，就能避免许多工单停滞。

避免为每个部门、主题或紧急程度创建一个状态。使用分配或群组来表示负责人，使用标签来表示主题，使用优先级来表示紧急程度。当每个字段只有一种用途时，User 就能以一致的方式理解队列。

区分负责人、优先级和分类

这三个概念回答的是不同的问题。负责人表示谁应当采取行动。优先级表示需要多快得到关注。分类表示请求属于哪一类。将它们混在一起，会造成含义模糊的队列和不可靠的报告。

让一位 User 或一个群组承担责任

每张未关闭的工单都应当有明确的负责人。共同负责很容易变成无人负责。群组可以接收新工作，但工作开始后，应当由具体的 User 接手。为人员缺席定义备用规则，并在所需专业知识发生变化时制定交接规则。

根据可观察的条件定义优先级

用简单明了的语言编写优先级规则。例如，影响大量客户的中断问题，其优先级应高于一般咨询。不要让优先级变成将每个缺乏耐心的请求标记为紧急的方式。简短的书面定义可以让 User 有据可依，并保持一致的判断。

让标签服务于未来的行动，而不是装饰

只有当标签能够帮助团队分派工作、查找有用的细分群体，或回答反复出现的问题时，才创建该标签。定期检查标签并合并含义相近的标签。更精简的词汇体系能够带来更清晰的视图和更值得信赖的分析。

设计能够保留上下文的交接流程

交接应当转移责任，而不应迫使下一位 User 重新还原整个案例。将客户回复和内部备注保留在工单时间线中。重新分配前，补充当前发现、尚未解决的问题，以及下一步预期行动。

对于不应发送给客户的协作内容，使用内部备注。当你需要确认已收到请求、索取信息或解释延迟时，使用客户回复。这样的区分可以让对话保持清晰，也能为同事提供所需的上下文。

当两张工单涉及同一个问题时，决定哪条记录作为事实来源。将重复工单合并到主工单中，然后从一个地方继续处理。并行记录容易导致答复相互冲突，并使历史记录分散。

在工作流稳定后再添加服务目标

目标无法修复负责人不明确的问题。首先确保新工作会得到审核、分配情况清晰可见，并且等待中的工单有明确的跟进路径。然后根据团队实际工作的时间，定义响应和解决预期。

关注那些即将达到目标的工单，而不仅仅是已经错过目标的工单。目标是在仍有时间时促进行动。Deskhero 的SLA 政策支持首次回复和解决目标、工作时间安排、筛选器、提醒以及仪表板视图。

用真实场景测试工作流

在正式推行流程之前，先演练具有代表性的请求。包括一个直接的问题、一项需要更换负责人的请求、一宗等待客户回复的案例、一张重复工单，以及一段重新打开的对话。对于每个场景，检查下一步行动和负责人是否始终明确。

让没有参与设计工作流的 User 进行测试。如果他们需要口头指导，说明规则或字段名称还不够清晰。调整流程，然后重新执行这些场景。

在推行期间，保留一份简短的例外情况记录。记录 User 不知道应选择哪种状态、负责人或优先级的情况。定期查看这份记录，并且只有在出现重复模式时才修改工作流。这样可以避免系统不断积累一次性规则。

衡量流程，而不是为了活动量而衡量活动量

有用的报告应当揭示客户在哪里等待，以及工作在哪里卡住。先从工单量、首次响应时间、解决时间、积压工单的存续时间和重新打开的请求开始。关注趋势和细分情况，而不要把某一个平均值当成全部情况。

将每项指标与一个决策结合起来。不断增加的旧工单积压，可能需要更明确的负责人或更多处理能力。首次回复缓慢，可能说明接收请求的覆盖不足。频繁重新打开，可能意味着解决方案不完整或答复令人困惑。如需更深入的衡量方案，请参阅我们的帮助台报告指标指南。

当证据显示存在反复出现的瓶颈时，检查工作流。不要仅仅因为软件允许，就添加字段或步骤。最佳的帮助台设置，是在可靠地让负责人、上下文和下一步行动清晰可见的前提下，尽可能精简的设置。

实用的推行检查清单

1. 绘制正常请求路径以及常见例外情况。
2. 根据下一步行动由谁负责，定义每个状态。
3. 区分负责人、紧急程度和主题分类。
4. 记录一次完整交接必须包含的内容。
5. 使用符合实际的支持场景测试工作流。
6. 在分派和负责人机制可靠后，再添加服务目标。
7. 选择一组与运营决策相关的少量指标。
8. 检查例外情况，并简化 User 执行不一致的规则。

一旦这些决定被记录下来，配置就会容易得多。你的工具应当让已达成共识的流程清晰可见并且可以重复执行，同时为特殊情况保留足够的灵活性。