这是问题：
我负责一家大公司的新服务器应用程序的用户支持热线。 该应用程序不是很好，我们从用户那里得到很多电话和电子邮件。 到目前为止，我们正在使用问题跟踪工具（Jira），以便pipe理来自用户的所有查询。
我们的支持团队首先处理最高优先级的票据。 我们总是有大约50张开门票。 因此，我们可能需要几天时间才能分析和解决低优先级的票证。 因此，门票的好分类是必要的。
我们不断地改进应用程序和文档，但这需要一些时间。
约束
我们必须在详细的技术分析之前决定优先权。 电话中的那个人不是一个深度的技术专家。 每个用户声称他/她的问题是一个威胁生命的表演塞。 我们的用户必须能够理解为什么某张票有一定的优先权。 因此将在我们的文档中发布标准。
给你的问题：
我们应该如何决定票的优先权？ 有没有人知道这个问题的一套成熟的标准？
开始尝试定义像这样的东西：
以这两个维度作为matrix，交叉点是优先级。 如果影响=最大（每个人的影响）和严重性=最大（应用程序是closures），这是一个优先级1.其他一切都将在一定程度上较低的优先级。 如何细化你想得到的是一个商业决策。
/编辑 – 作为一个旁白，阅读SLA，SLO以及所有与此相关的术语是值得的。 ITIL可能是很好的背景。 我获得了ITIL v2 Foundation的authentication，这是对如何提供和支持IT服务的很好的描述性概述。 不要规定地阅读它 – 把它作为你可以用来适应你的情况的知识。 ITIL v3，我不太了解，除了似乎已经变得更加复杂。
/另一个编辑 – 确保你的开发人员和/或工程团队善于与前线人员沟通。 如果前线人员得到了如何处理公开问题的信息，他们应该能够对新的调用者说：“是的，这个错误是一个已知的问题，我们希望下周有一次修复通过QA“等。
我知道没有这样成熟的标准。
也就是说，我确实知道我在IT供应商支持部门遇到了什么问题，这提示了一个好的标准可能是什么样子。 一个这样的优先级评级看起来类似于：
显然，这是一个衡量多less工作受到影响的标准。 对于普通的帮助台，大多数问题将是低/中等，具有重要的健康发酵。
我知道一些帮助台可以按照预期的解决时间优先考虑优先级。 MS-Office中的一个用户发现的错误正在等待Microsoft修复，所以它获得了较低的次优先级。 一个用户的打印驱动程序问题的报告看起来也影响了一堆其他人，他们还没有注意到，所以这个问题得到更高的次优先。 那种事。
侧节点：
这些“信息”问题可以有相当的善意附加在他们身上。 有人来到咨询台寻求专家build议，并且可以通过及时回复交友。 如果可以迅速回答，肯定是这样做的。
这是我的意见，基于我们的服务台（我没有参与）的观察：
严重性/高优先级 – 用户/公司故障：阻止用户以任何方式，forms或forms使用您的应用程序的任何问题。 这意味着他们大概无法从事任何工作（如果他们的工作依赖于您的应用）。
中等严重性/正常优先级：能够以降低的function性或性能级别使用您的应用程序的用户：这些问题给用户带来不便，但是不妨碍他们使用应用程序和所需的function他们的工作。
低严重性/低优先级：这些问题不妨碍用户使用您的应用程序和所需的function。 一个例子可能是需要知道如何在应用程序中设置特定选项或设置的用户。
每个用户都应该在您所说的SLA时间窗口内接到电话或电子邮件，通知他们他们的通信/问题已经logging下来，他们会在规定的SLA时间窗口内收到您的回复。 电话/电子邮件的目的不是为了解决问题，而是为了方便您和客户之间的沟通。 没有什么比让客户等待电话/电子邮件确认他们的问题已经被收到并且正在被处理的更糟。
尽量不要太疯狂地执行各种级别的影响，范围，严重程度等，因为你会花费更多的时间来“pipe理”系统/程序，而不是你将要处理的问题。 保持简单，并根据需要进行调整。 我们的技术支持人员使用3级严重级别，并配有3级优先级：关键/高，中/正常和低/低。
从我的支持经验来看，我们有两个标准： 优先级和严重性 。