很多 IT 团队在概念上知道“服务请求不是事件”，但实际面向用户时仍会把两者混在一起处理。服务请求履行（Service Request Fulfillment）的核心，不是新增一个流程名称，而是让稳定、可重复、低风险的标准服务交付变得可预期、可度量。对服务经理和 IT 运营负责人来说，最务实的起点是先把边界和闭环定义清楚。

先厘清边界：服务请求履行不是事件管理，也不是变更管理

服务请求履行是指用户通过服务台、自助门户或其他渠道提交标准服务申请后，IT 组织按照预先定义的流程完成分类、审批、执行、交付和关闭的一组活动。它强调的是稳定、可重复、低风险的服务交付。

要理解服务请求履行，一个实用的判断不是看“用户有没有提出要求”，而是看“用户需要的是恢复服务，还是获得一组预授权的服务或信息”。如果服务已经中断或性能明显下降，需要恢复到正常状态，这属于事件管理；如果用户申请的是标准软件、权限、设备或信息，则属于服务请求履行。

可以从四个维度快速判断：

• 起点：事件通常源于服务异常或用户报告故障；服务请求通常由用户主动发起，用于获得标准交付。

• 目的：事件要恢复约定的服务级别；服务请求要交付一项明确的服务或物品。

• 风险：事件处理可能包含应急措施和临时恢复；服务请求履行通常风险较低、影响范围可控。

• 可重复性：服务请求应能通过服务目录和标准流程反复交付；事件则更依赖诊断和恢复能力。

常见的服务请求包括：申请应用系统账号或权限、申请标准软件安装、申请笔记本电脑或外设、申请 VPN 访问、提交新员工入职所需的 IT 资源、申请共享文件夹权限、获取标准报表或信息等。这些请求的共同点，是服务台或 IT 运营团队应当提前定义好交付方式和 SLA，而不是等到用户提交后再临时判断。

与此同时，如果用户的根本问题是服务器宕机、核心系统无法访问、网络中断，应走事件管理；如果请求会改变生产环境基线、引入新的架构组件、需要风险评估和窗口计划，则应走变更管理；如果是新系统建设或跨部门项目，则不应作为服务请求履行。边界不清，通常不是工具问题，而是缺乏分类标准和请求目录。

从分类到关闭：服务请求履行的四个关键步骤

服务请求履行必须是一个闭环。如果只做到接收和转发，后续没有明确的分类、审批、执行和关闭标准，就会产生责任不清、重复处理和无法度量的问题。

1. 请求分类与标准化

组织需要先建立服务请求目录，而不是让用户用自由文本描述需求。服务请求可以被归为权限类、资产类、软件类、信息类、入职类、离职类等。每类请求应明确：

• 适用用户范围和前提条件

• 负责团队或履行责任人

• 标准交付方式和所需时长

• 是否需要审批，以及审批路径

• 交付后由谁验证、如何关闭

有了这些定义，服务台就可以在受理阶段快速识别该请求是否标准、能否直接履行，或者是否需要转交事件、变更和其他流程。

2. 审批与授权

审批应被设计成一个前置环节，而不是在工单已经流转后才临时增加。合理的审批通常涉及两类：一类是业务审批，例如部门负责人确认成本归属；另一类是安全或技术审批，例如 VPN 权限、生产数据访问、高权限账号申请等。

需要避免的误区是“所有请求都审批”。标准软件安装如果已有可用许可和合规基线，可以自动批准；员工申请标准外设如果已经计入部门预算，也可以由服务台直接执行。审批只应存在于风险、成本或合规要求真正需要控制的地方，否则审批会变成流程延时的主要来源。

3. 执行与交付

执行环节是服务请求履行最核心的工作。对于高频、标准化的请求，应尽量通过自动化或自助服务完成；对于需要人工操作的请求，也应提供清晰的执行手册或检查清单。执行完成后，不应直接关闭工单，而应先完成交付验证，例如确认权限已生效、软件已安装、设备已发放或数据已可访问。

如果请求在执行过程中发现底层问题，例如账号无法创建是因为身份源故障，或者软件安装失败暴露出终端管理问题，应当转为事件处理，而不是继续在请求流程中反复尝试。

4. 关闭与确认

关闭不等于“处理人认为已经做完”。一个合格的服务请求履行闭环，应包括交付确认、用户反馈和记录更新。对于用户无法及时确认的情况，可以设定确认时限，但不应为了追求工单清空而提前关闭。关闭时还应检查是否产生了可复用的知识或操作记录，以便后续同类请求处理得更快。这些知识可以沉淀到 Confluence 团队知识库中，形成标准操作手册，而不是只留在单个工单里。

ITIL 3 与 ITIL 4 中的服务请求履行有什么不同

在 ITIL v3 中，服务请求履行被明确列为服务运营阶段的一个流程，与事件管理、问题管理、访问管理并列。ITIL v3 更强调流程之间的分解和职责边界，因此很多组织会设立专门的服务请求履行流程负责人，并围绕分类、审批、执行和关闭建立标准操作程序。

ITIL 4 不再把“服务请求履行”作为单一的正式流程名称，而是将其整合为“服务请求管理”实践。ITIL 4 更关注价值流和用户体验，强调服务请求应通过服务目录、自助服务、自动化和持续改进来交付，而不是只靠服务台逐单处理。对于已经习惯 ITIL v3 术语的团队，可以把“服务请求履行”理解为服务请求管理实践中的执行与交付部分，但它不能脱离请求目录、SLA 和反馈机制独立存在。

常见落地误区与判断标准

实际落地中，服务请求履行常见的误区集中在分类、审批和关闭三个环节：

• 把服务中断当作服务请求，导致用户等待时间被低估，错过事件 SLA。

• 把所有用户申请都当作服务请求，没有识别出潜在的变更或项目需求。

• 没有服务目录和请求模型，服务台只能根据个人经验判断，交付结果不一致。

• 审批链路过长，所有请求都要求多级批准，造成请求积压。

• 只关注“是否完成”，不关注交付时间、首次解决率和用户确认情况。

• 关闭标准缺失，工单被提前关闭，用户问题实际未解决。

• 忽视自动化机会，高频简单请求仍依赖人工处理。

当面对一个模糊的用户申请时，可以按以下顺序判断：

1. 服务是否中断或性能下降？如果是，进入事件管理。

2. 用户是否在申请一项已定义的标准服务或信息？如果是，进入服务请求履行。

3. 是否会改变生产环境、引入新风险或需要重大资源投入？如果是，进入变更管理或项目评估。

4. 是否属于常规权限申请但涉及敏感数据？如果是，在履行流程中增加安全审批，而不是改走变更。

用可落地的指标持续改进

服务请求履行是否健康，不应只看处理了多少个请求。建议从效率、质量和体验三个维度观察：

• 请求分类覆盖率：能够被标准化目录覆盖的请求占比。

• 平均履行时间：从用户提交到交付完成的时长。

• SLA 达成率：各类请求在约定时间内完成的比例。

• 自助服务成功率：用户通过自助门户成功提交并解决的比例。

• 升级为事件的比率：哪些请求在执行中暴露了服务健康问题。

• 重新开启率：交付后用户再次提出同类问题或工单被重新打开的比例。

• 用户确认率：交付后获得用户明确确认或未在确认期内提出异议的比例。

不要孤立优化某一项指标。例如，只压缩平均履行时间可能导致关闭过快；只追求自助服务成功率可能忽略复杂请求的体验。好的服务请求履行，是在标准交付、合理审批和用户确认之间找到平衡。在 Jira Service Management 等 ITSM 工具中，这些指标应尽可能从服务目录、请求队列和自动化规则中直接获取，而不是依赖手工统计。

结语：先定义目录、SLA 和关闭标准

服务请求履行之所以值得被独立讨论，是因为它决定了 IT 组织是否能以可预期、可度量的方式响应用户的日常需求。它的关键不在于新增一个流程名称，而在于把“恢复服务”和“交付服务”区分开，把分类、审批、执行和关闭连成闭环。对服务经理和 IT 运营负责人来说，最务实的起点不是先上一套复杂系统，而是先定义好服务请求目录、SLA 和关闭标准，再从高频请求开始推动自动化。

需要进一步评估服务请求履行流程？

如果你正在梳理服务目录、审批机制或 ITSM 度量指标，可以联系我们进一步交流。

常见问题

什么是服务请求履行？

服务请求履行是用户通过服务台、自助门户等渠道提交标准服务申请后，IT 组织按预先定义的流程完成分类、审批、执行、交付和关闭的一组活动。它主要用于稳定、可重复、低风险的标准交付。

服务请求履行和事件管理有什么区别？

事件管理的目标是恢复已中断或性能下降的服务；服务请求履行则是交付一项已定义的标准化服务或信息。判断的关键不是用户是否提出了要求，而是用户需要恢复服务还是获得标准交付。

服务请求履行的关键步骤有哪些？

核心步骤包括请求分类与标准化、审批与授权、执行与交付、关闭与确认。四个步骤需要形成闭环，否则容易产生责任不清、重复处理和提前关闭等问题。

ITIL 4 中还有服务请求履行吗？

ITIL 4 不再将其作为单一正式流程名称，而是整合为“服务请求管理”实践。可以把“服务请求履行”理解为该实践中的执行与交付部分，但仍需服务目录、SLA 和反馈机制支撑。

哪些请求应走变更管理而不是服务请求履行？

如果请求会改变生产环境基线、引入新风险、涉及新的架构组件，或需要重大资源投入与窗口计划，应进入变更管理或项目评估，而不是作为标准服务请求处理。

服务请求履行应该关注哪些指标？

可关注请求分类覆盖率、平均履行时间、SLA 达成率、自助服务成功率、升级为事件的比率、重新开启率和用户确认率，从效率、质量和体验三个维度持续改进。