服务请求是什么
服务请求是用户发起的预定义、可重复的请求，例如权限申请、软件安装、密码重置、设备领用与使用咨询。它与事件的区别在于性质：事件意味着“服务意外不可用”，请求意味着“按已知流程交付某样东西”。两者必须分开建单、分开统计，否则恢复速度与交付效率的指标会互相污染，排队规则也会互相挤占资源。ITIL 4 把服务请求管理放在服务管理实践中，落地载体是服务目录条目加请求工作流。
基本信息
| 典型例子 | 权限、设备、软件、咨询 |
|---|---|
| 载体 | 服务目录条目 + 请求工作流 |
| 指标 | 请求解决时长、按期完成率、满意度、自助完成率 |
| 与事件的区别 | 请求可预约可批量，事件需即时恢复 |
| 常见门槛 | 审批链与前置条件 |
| 关联实践 | 服务目录管理、服务台、知识管理 |
典型使用场景
- 账号与权限：开通、调整、回收，常与离职流程联动
- 软件与工具申请：按目录条目走审批，写明交付方式
- 硬件与设备：笔记本、外设、工位设备，涉及库存与资产记录
- 环境与资源申请：测试环境、云资源、域名与证书，需要成本归属
- 咨询类请求：使用咨询与操作指导，能用知识库消化就转自助
- 批量计划性交付：新员工入职包、部门统一升级，按批次一次处理
服务请求模板要素
服务请求模板要素
请求名称 / 适用对象 / 前置条件
审批链（如需要）/ 目标时限 / 服务时段
交付步骤 / 交付验证 / 表单必填字段
自助化判断：能否用脚本或平台自动完成
到期与回收：有期限的权限要写明失效方式请求与事件的差别
| 维度 | 服务请求 | 事件 |
|---|---|---|
| 触发 | 用户主动申请 | 服务异常或用户报障 |
| 目标 | 按约定时限交付 | 尽快恢复可用 |
| 可否计划 | 可预约、可批量 | 不可预约，需即时响应 |
| 优先级依据 | 业务需求与影响范围 | 业务影响与紧急度 |
| 核心指标 | 解决时长、按期完成率 | MTTR、恢复时长 |
| 队列 | 请求队列 | 事件队列 |
请求与事件混在同一队列统计，两组指标会同时失真；分流规则要写进服务台作业手册，而不是靠一线临场判断。
审批链要按风险分级：低风险请求（标准软件安装）免审批或自动审批，高风险请求（生产权限、数据导出）才走多级审批。
有期限的权限应自动到期：把失效时间写进请求单并由系统执行回收，比事后审计发现长期闲置权限更有效。
自助化改造思路
- 先挑高频且规则明确的请求做自动化，例如密码重置与标准软件安装
- 把审批条件写成规则，符合条件的自动通过，只让例外进入人工流程
- 交付结果自动回填工单并通知申请人，减少口头跟催
- 统计自助完成率与人工占比，按季度挑选下一批改造对象
请求量下降不一定说明需求减少：也可能是员工找不到入口而私下找人代办，自助率与工单量要一起看。
请求队列治理要点
- 按服务目录条目分类统计，识别高频项与长尾项
- 为每个条目设定目标时限并对外公开，减少催单
- 每日巡查长账龄请求，避免被新工单淹没后遗忘
- 关闭后做回访，从评价里找流程断点而不是追责