服务请求和事件怎么区分：三个判断问题加 20 个分类示例

简短回答：事件是原本能用、现在坏了或变差的东西。服务请求是用户向你要一项服务目录里已经有的、可重复的标准服务。事件的目标是尽快恢复服务；请求的目标是按约定的时间交付约定的内容，通常带审批。拿不准时，按下面三个问题的顺序问一遍。

本文写给服务台负责人、IT 经理，以及要配置工单系统的人。读完后，你可以在一分钟内把任意一张工单归到正确类型，用 20 个示例培训新同事，并建立两套不同的处理流程，让日常请求不再被当成紧急故障。

服务请求和事件有什么区别？

ITIL 4 术语表把服务请求定义为：用户或其授权代表提出的、启动一项已被约定为正常服务交付一部分的服务动作的请求。事件则是服务的计划外中断，或服务质量的下降（2026 年 10 月 28 日核对）。

说得直白一点：

• 事件：“原来能用，现在不能用了，或者比以前差了。”
• 服务请求：“我需要一样东西，你们已经有标准的给法。”

区分的意义在于两者的度量和处理方式不同。事件的计时看服务多快恢复；请求的计时看是否在约定日期前交付。混在一起，真正的故障会淹没在日常工作里，日常工作又会被当成救火。

三个判断问题

按顺序问，遇到第一个“是”就停。

1. 原来正常的东西，现在坏了、变慢或不稳定吗？是，就是事件，即使用户的措辞像请求（“请帮我修一下邮箱”）。
2. 没有东西坏的话，用户要的东西在服务目录里，或有标准流程吗？是，就是服务请求。包括权限、新设备、软件安装、账号变更和“怎么操作”类问题。
3. 都不是的话，它是对环境的改动或新事物吗？那是变更请求（或项目），开工前要评估。如果同类事件反复出现而原因不明，另开问题记录，并与相关事件关联。

两条处理边缘情况的原则：

• 看用户需要什么，不看他怎么说。“我打不开财务共享文件夹”可能是权限从来没开过（请求），也可能是共享挂了（事件）。先查这位用户以前能不能打开。
• 按最初的需要分类。请求在交付过程中失败，请求继续保留，并针对失败另开事件。不要悄悄把一种改成另一种。

20 个分类示例

事件（8 个）

1. Outlook 从今早起连不上：昨天还能用，服务中断。
2. 共享打印机打印出空白页：原本正常的服务质量下降。
3. 会议室 Wi-Fi 每隔几分钟掉线：服务降级。重复报障要关联到同一个主事件。
4. 笔记本开机蓝屏：硬件或操作系统故障。
5. VPN 能连上但内部文件共享打不开：服务的一部分中断。
6. 某位用户的 Teams 通话没有声音：对该用户服务中断。如果影响很多人，就升为更高优先级的事件。
7. 内部网页应用显示错误页：所有使用者都受到影响的服务中断。
8. 昨晚的备份任务失败：服务失败，用户可能还没发现，但它仍是事件。

服务请求（8 个）

1. 新员工需要账号、笔记本和邮箱：标准入职项目。
2. 把某人加入共享邮箱：标准的权限变更，一般由邮箱所有者批准。
3. 安装已批准的软件：有成熟流程的目录项目。
4. 申请某个 SharePoint 站点的权限：由站点所有者审批的请求。
5. 更换磨损的键盘或鼠标：标准硬件请求。
6. 提高邮箱或 OneDrive 配额：在约定限额内的标准变更。
7. 离职：停用账号并回收设备：标准离职请求，常由人事触发。
8. “手机上怎么设置公司邮箱？”：信息类请求。回答之后，把答案补进知识库。

边界情况（4 个）

1. 忘记密码：标准重置能成功时是服务请求；重置流程本身出错，或很多人同时无法重置，就是事件。
2. 账号被锁定：解锁一次是请求；反复锁定又找不到原因是事件，通常还要开问题记录（例如手机上存着旧密码）。
3. “我的笔记本很慢”：比以前慢了是事件；用户想换一台比标准配置更快的机器，则是需要审批的例外申请。
4. 软件安装报错：安装本身是请求，报错是挂在它名下的事件，这样两个计时都准确。

两套处理流程有什么不同

写文档时两套流程用同样的条目顺序，方便员工对照。

事件流程

• 触发：东西坏了或变差了。
• 目标：恢复服务，临时绕过方案也算恢复。
• 优先级：由影响和紧急程度决定。见严重程度和优先级的区别和IT 支持 SLA 优先级 P1 到 P4。
• 审批：开始处理不需要审批。用于修复的紧急变更按变更规则走。
• 时限：按优先级设响应和解决时间。
• 升级：按支持层级向上，再到供应商；影响面大时转入重大事件处理（见重大事件管理流程）。
• 关闭：用户确认服务已恢复。重复出现的事件交给问题管理。

服务请求流程

• 触发：用户从目录里选一项，或提交标准表单。
• 目标：按约定交付该项内容。
• 优先级：通常每个目录项目有一个约定的交付时间，而不是影响和紧急程度的评分。特殊加急由经理决定，不由用户自己勾“高”。
• 审批：按项目规定（经理、数据所有者、安全）。无需审批应是例外，而不是默认。
• 时限：每个项目一个交付时间，例如“新员工的设备在入职前一天准备好”。
• 升级：只在审批或交付延误时才升级。
• 关闭：项目交付，用户确认，审批和操作都有记录。

在工单系统里怎么设置

1. 把工单类型设为必填，三个取值：事件、服务请求、变更请求。问题是与事件关联的单独记录，不是表单上的第四个选项。
2. 用服务目录生成请求表单，带上必填字段（谁、要什么、开始日期、审批人），减少反复追问。
3. 每个目录项目指定负责人、审批人和交付时间。
4. 跑两种 SLA 计时：事件看恢复时间，请求看交付时间。L1、L2、L3 支持层级可以共用一个队列，但计时必须不同。
5. 允许重新分类，但要写明原因并保留历史。不要删掉工单再重建。
6. 把上面 20 个示例放进知识库，让服务台每次都按同一个标准分类。

常见错误

• 所有工单都当事件处理。日常请求获得紧急优先级，真正的故障反而被淹没。解决：分开类型，分开计时。
• 让用户在请求表单里自选优先级。人人都选“高”。解决：交付时间来自目录项目，特殊情况由经理决定。
• 因为用户说了“请”，就把坏掉的东西当请求。解决：每次先问第一个判断问题。
• 没有审批路径。权限请求变成谁先看到谁就办。解决：每个项目指定审批人。
• 用自由输入框代替表单。第一次回复全花在追问缺失的信息上。解决：每个项目设必填字段。
• 悄悄改类型。统计失真，用户也困惑。解决：改类型时写明原因并告知用户。

怎样验证做对了

1. 每月随机抽 20 张已关闭的工单，对每张重新问一遍三个问题，与记录的类型比较。
2. 统计被重新分类的工单数量。数量偏高说明表单或示例需要改进。
3. 确认每张已关闭的请求都写明了目录项目，需要审批的也有审批人。
4. 按项目查看交付时间。总是延误的项目需要重新定目标或增加人手，而不是多发催办。
5. 在请求工单里搜索“不能用”“报错”“挂了”之类的词。每个命中都可能是被误分类的事件。

常见问题

在 ServiceNow 里，服务请求和事件有什么区别？

在 ServiceNow 里，和在任何工单工具里一样，判断方法相同：原本能用的服务坏了或变差，就开事件；用户要的是目录里的项目，就开请求。两者用不同的记录类型，也用不同的 SLA 计时。

重置密码算服务请求还是事件？

正常的密码重置是服务请求，因为这是用户有权获得的标准操作。如果重置流程本身坏了，或很多人同时被锁，那就是事件。

服务请求和变更请求有什么区别？

服务请求要的是目录里已有、流程成熟的东西，比如权限或标准安装。变更请求要修改环境，比如新增防火墙规则或新系统，开工前要评估和审批。

服务请求的 SLA 是多少？

通常是每个目录项目事先约定的交付时间，而不是按影响程度定的恢复时间。目标怎么写，见IT 支持里的 SLA 是什么意思。

能给一些事件和服务请求的例子吗？

可以。上面的 20 个示例包含故障（事件）、标准需求（服务请求）和四个边界情况。

如果你想要一个已经把事件和请求分开管理、并分别出报告的服务台，请了解我们的7x24 服务台 IT 支持。