问题如下：
我负责一家大型公司新服务器应用程序的用户支持热线。该应用程序不太好，我们接到了很多来自用户的电话和电子邮件。到目前为止，我们正在使用问题跟踪工具 (Jira) 来管理来自用户的所有咨询。
我们的支持团队首先处理优先级最高的工单。我们经常有大约 50 张未结工单。因此，我们可能需要几天时间才能分析和解决低优先级的工单。因此，对工单进行良好的分类是必要的。
我们正在不断改进应用程序和文档，但这需要一些时间。
约束
在进行详细的技术分析之前，我们必须确定优先级。接电话的人并不是深厚的技术专家。每个用户都声称自己的问题是一个危及生命的大问题。我们的用户必须能够理解为什么某个工单具有特定的优先级。因此，我们将在我们的文档中发布标准。
您的问题是：
我们应该如何确定票证的优先级？有谁知道一套经过充分验证的标准来解决这个问题吗？
答案1
首先尝试定义如下内容：
- 影响 - 有多少人受到影响？只有一个人、一群人还是所有人？如果只有 1 个人，他们是 VIP 还是您想留住的已经生气的客户？
- 严重程度 - 受影响程度有多严重？应用程序是否停止运行，或者只是整体运行缓慢，还是某个功能无法正常工作？是否有可用的解决方法？
用这些作为两个维度创建一个矩阵，交点就是优先级。如果影响=最大（每个人都受到影响）且严重性=最大（应用程序已关闭），则优先级为 1。其他所有优先级都会降低一些。您想要获得多精细的优先级是一个业务决策。
/编辑 - 顺便说一句，阅读 SLA、SLO 以及与之相关的所有其他术语是值得的。ITIL 可能是很好的背景知识。我获得了 ITIL v2 Foundation 认证，这是一份关于如何交付和支持 IT 服务的很好的描述性概述。不要以规定的方式阅读它 - 将其视为可用于适应您情况的知识。ITIL v3，我不太了解，只是它似乎变得更加复杂了。
/另一项修改 - 确保您的开发和/或工程团队善于与一线人员沟通。如果一线人员获得了有关如何处理未解决问题的信息，他们应该能够对新来电者说：“是的，该错误是一个已知问题，我们希望在下周通过 QA 后修复”，等等。
答案2
我不知道有任何此类经过充分验证的标准。
尽管如此，我确实知道我在 IT 供应商支持台遇到的情况，这确实为一套好的标准提供了一些提示。其中一个优先级评级类似于以下内容：
- 信息性——用户对某事感到好奇，或正在规划未来。对正常运行时间/最终用户没有影响。
- 低——用户感到烦恼，但可以正常工作
- 中度——一名用户的工作受到影响
- 重要提示——一个用户根本无法工作
- 紧急——许多用户根本无法工作，或严重退化
- 严重——整个部门/办公室/公司无法工作，或严重受损
显然，这是根据工作受影响程度来定义的等级。对于普通的服务台来说，大多数问题都是低/中等，但重要性较高。
我知道有些帮助台会根据预期解决时间进一步在优先级评级中确定优先级。用户发现的 MS-Office 中的一个错误正在等待 Microsoft 修复，因此它的子优先级较低。某个用户报告的打印驱动程序问题似乎也会影响到其他许多人，但他们尚未注意到，因此该问题会获得更高的子优先级。诸如此类。
侧节点：
这些“信息性”问题可能会带来很多善意。有人来服务台寻求专家建议，您可以通过及时回复来结交朋友。如果可以快速回答，一定要这样做。
答案3
这是我根据对我们的服务台（我没有参与）的观察得出的观点：
严重程度/高优先级 - 用户/公司瘫痪：任何导致用户无法以任何方式、形式使用您的应用程序的问题。这意味着他们可能完全无法完成工作（如果他们的工作依赖于使用您的应用程序）。
中等严重程度/正常优先级：用户能够以较低的功能或性能使用您的应用程序：这些问题给用户带来不便，但不会阻止他们使用该应用程序和完成工作所需的功能。
低严重性/低优先级：这些问题不会妨碍用户使用您的应用程序和所需的功能。例如，用户可能需要知道如何在应用程序中设置特定选项或设置。
每位用户都应在您规定的 SLA 时间范围内接到电话或电子邮件，告知他们他们的通信/问题已被记录，并且他们将在规定的 SLA 时间范围内收到您的回复。电话/电子邮件的目的不是解决问题，而是促进您与客户之间的沟通。没有什么比让客户等待电话/电子邮件确认他们的问题已收到并正在处理更糟糕的了。
尽量不要过于疯狂地实施各种影响、范围、严重性等级别，因为您最终会花更多的时间来“管理”系统/程序，而不是处理问题。一开始保持简单，然后根据需要进行调整。我们的帮助台使用 3 个严重性级别和 3 个优先级级别：严重/高、中/正常和低/低。
答案4
根据我从事支持工作的经验，我们二标准：优先事项和严重程度。
优先事项
- 可以由提交者设置（毕竟这是他们的环境）
严重程度
- 仅根据案件的技术情况决定
相互作用磷和年代级别
- 当所有具有给定严重程度的案例都可用时，首先选择优先级最高的案例
- 来自特定客户，根据严重程度排列问题，或者告诉他们需要选择哪个实际上他们的“首要任务”——他们不能全部成为引人注目的人物
例子
- 客户遇到非宕机问题（无法弄清楚如何配置X），但很重要给他们（老板的严厉监管、紧迫的最后期限等）
- 客户致电并打开紧急 1 级案件
- 支持人员根据以下情况确定其严重程度为 3 级或 4 级技术的优点
- 确定特定客户“有多重要”（所有公司都有其更需要和不太需要的客户，以及更重要和不太重要的客户）——可能会随之调整严重程度
- 客户只看到它是 P-1，因为这是他们的视角
- 支持人员会考虑这两种价值，并根据内部升级/偏好政策处理案件