来源：https://advisera.com/20000academy/knowledgebase/incident-classification/
服务台的第一个任务是“记录所有相关的事件/服务请求细节，分配分类和优先级代码（categorization and prioritization codes）。”(ITIL服务操作:服务台目标)
一、为什么它如此重要?
服务台需要捕获票证数据，以便进行适当的人员分配、改进/启用问题管理、授权管理部门创建更好的决策并帮助建立有用的知识库。
二、优先级（Priority）
ITIL说，优先级应该是影响/紧急矩阵的产品。ISO/IEC 20000与8.1中的事件和服务请求管理一致。
按照惯例，优先级有4到5个级别，用数字1-4或1-5标记，其中“1”是最高的，“5”是最低的优先级。它也可以由字母ABCD或ABCDE标记，A是最高优先级。
最常用的优先级矩阵是这样的:
影响（Impact）—— 停机时间对业务的重要性。通常，它是由受影响用户的数量来衡量的。如果一个或多个服务宕机，则可以从CMDB数据或服务目录确定停机数量。
紧迫感（Urgency）——它通常在SLA中为特定的it服务定义。如果有多个服务受到影响，则将考虑更紧急服务的参数。
客户是否有权决定优先级?一般来说,没有。如果定义了SLA参数，那么对于服务台来说，这应该是一项简单的工作。通常会在这个等式中加入噪音的两类客户是:
在大计划中过高估计问题重要性的最终用户:应该向他们保证，根据他们的服务水平协议，他们的票据将在最大努力的基础上得到照顾。
VIP客户用户试图提高他们的优先级的原因不包括在他们的SLA。如果有可用的资源，好的做法是接受它们的请求，并按照请求的优先级处理票据，并在下一次SLA定期会议中提到这个问题。
应该避免在事件生命周期中更改优先级，因为大多数ITSM工具在重新计算升级时间和SLA参数时都存在问题。降低优先级尤其如此。例如，在服务恢复之后将事件优先级从1降低到4，以便监视基础设施并执行根本原因分析。这里的良好实践是在恢复后立即解决票证问题，并打开相关的问题票证。通过这种方式，可以更容易地监视商定的服务水平，并避免报告问题。
三、类别
我们为什么要分类?主要原因是问题管理流程的输入和供应商管理中的授权决策。ITIL在事件分类方面不是很具体。ISO20k，更少。
大多数情况下，必须依赖票务工具的能力，并根据业务需求进行自定义。我所见过的一些高德纳象限的工具在定制方面更加严格。它们有三到四层。不过，这对于创建一个有用的类别树应该足够了。
根据组织服务管理的范围，下面是一些类别树的例子:
类别树的深度应该定期修改，并根据组织的需要进行修改。我知道有些客户有5个或6个类别的层，其中很少使用超过3个层，但是树没有得到维护。因此，当一项新技术的票价被提高时，它将获得“杂项”这一类别。一个好主意是打开一个“旧的”类别，把所有过时的技术放在那里。这样，数据库完整性是完整的，不会影响报告。
一些行业旗舰工具执行固定的层，如:Category:Subcategory:ProductType:ProblemType，或Category:Type:Item。这些都是很好的技术模式，可以对它们进行很好的有意义的分类，即使对于技术含量较低的业务客户也是如此。
我看到过一些严肃的票务应用程序将服务合并到分类中。我对此感到非常消极。在选择受影响的配置项时，应该指出一个或多个受影响的服务。如果某个网络段或服务器宕机，那么来自服务目录或至少配置管理数据库关系的信息应该指示哪些服务受到了影响，并且应该为SLA指标启动每个服务的停机记录。当以这种方式选择受影响的服务时，将自动选择服务的分配组或工程师队列。
另一件事是，由于最初缺乏数据，最初的类别常常是不准确的。因此，该工具应该能够在票据的生命周期中更改类别。
四、解析代码
还有另一种类型的票证类别，处理票证解析。解析票证可以通过一个小的、有意义的类别数量来分类，也可以通过一个复杂的类别树来进行要求更高的分析/报告。
通常有成功的解决指标(帮助ISO 20000要求，谢谢)，旁边是一个“不成功”的代码，当然;然后你需要一个“超出范围”的代码和一个“由设计引起的问题”的代码，意思是“这不是一个bug，而是一个特性”。“你可以走了。如果构建合理，这组类别很少需要修改。
对服务台的基本任务进行分类和排序，因此在实施和维护服务台应用程序时需要给予足够的关注，并对员工进行适当的教育。
如果可能的话，如果读者能留下一些反馈，我将不胜感激。例如:读了这篇文章后，你觉得你公司的市场经理笔记本上的邮件客户端故障问题应该按照优先级进行分类?
