服务目录别再像仓库清单：ITIL v5 这次更像在教你把“请求”做成一条顺路

很多组织的服务目录，看起来很“齐全”，点进去却让人头大：

一堆名词、几十个分类、各种缩写，用户根本不知道该点哪个。好不容易选了一个，表单长得像报税，填到一半还要问同事“这个字段怎么写”。最后用户干脆不走目录了，直接找熟人、直接私聊支持、直接在群里@人。

然后支持团队就开始抱怨：“你们为什么不走流程？”

用户也开始抱怨：“你们的流程为什么这么难用？”

这种矛盾很常见，但我想说一句实话：很多服务目录并不是“服务目录”，更像“内部仓库清单”。它满足了管理的整齐，却没满足用户的顺手。你把入口做得别扭，用户自然会绕开；用户一绕开，支持就会更乱；支持越乱，你越想加规则，最后就是恶性循环。

ITIL 第5版之所以值得你重新看服务目录与服务请求，是因为它把管理对象扩展到数字产品与数字服务，并强调体验优先。换句话说，第5版很像在提醒你：目录和请求不是后台管理功能，它们就是你的“产品门面”。门面不好用，再好的后台也救不了。

一、为什么目录与请求在第5版里更像“产品化能力”

ITIL 第5版相对 ITIL 4 的核心升级要点如下：

• 管理对象从服务扩展到数字产品与数字服务

• 价值链演进为八个阶段活动的全生命周期：发现、设计、获取、构建、转换、运营、交付、支持

• 体验被写入价值定义，强调可感知的结果与信任

• 治理更强调责任、选择与纠偏，而不是统一模板

• AI 与自动化纳入体系，强调能力分层与治理边界

服务目录与服务请求落在哪？它们直接影响交付与支持，也影响体验。更关键的是，它们会把组织的边界、承诺、标准化程度暴露给用户。目录做得清，用户预期就稳；请求履约做得顺，支持就会轻。

二、服务目录到底是什么：不是清单，是承诺与预期管理

很多团队做服务目录，思路是“把我们能提供的都列出来”。这听起来很合理，但用户真正想知道的通常是：

• 我该找谁

• 我能得到什么

• 要多久

• 需要我准备什么

• 出问题怎么办

这就是目录真正的价值：它是一份承诺的说明书，也是预期管理的工具。你目录里如果只写“账号开通、权限申请、VPN申请”，但不写清楚“多长时间、需要什么信息、哪些情况会被拒绝、审批路径是什么”，用户就会自行脑补预期，脑补出来的预期往往比你能做到的更高。后面体验差、投诉多，其实是预期没管住。

所以服务目录要做得像产品：信息要让用户一眼看懂，承诺要能兑现，边界要明确。

三、服务请求为什么会变成工单堆：因为你把“标准化履约”做成了“人工处理”

服务请求的本质，是标准化履约。比如开通账号、申请权限、发放设备、创建项目空间、恢复访问、重置密码。这些事情如果每次都靠支持人工判断、人工沟通、人工推进，那你越做越累是必然的。

ITIL 第5版强调价值链全生命周期和治理，从请求视角看就是：

• 你要把高频请求变成标准件

• 标准件要有固定输入、固定输出、固定时效

• 能自动化的尽量自动化，但边界要清楚

• 请求履约要能被度量和持续改进

把请求做顺，支持压力会明显下降；支持压力下降，体验反而会上来。很多人觉得这矛盾，其实不矛盾——支持最累的时候，体验往往最差。

四、用八个阶段活动把目录与请求做“端到端”：别只在支持端修修补补

你如果只在支持端优化目录和请求，比如改表单、改分类、加入口，很容易治标不治本。ITIL 第5版的八个阶段活动给你一个更完整的视角：目录和请求从发现开始就应该被设计。

1. 发现：先搞清楚用户为什么来找你 很多目录失败是因为分类按内部组织结构来，而不是按用户目的来。用户不是来找“基础架构部服务”的，用户是来“快速开通能用的东西”的。发现阶段要做的是识别用户意图：他们最常要什么、最焦虑什么、最怕填什么、最讨厌等多久。

2. 设计：把请求设计成“最小输入、最大确定性” 设计阶段要决定： • 用户必须填哪些信息才能完成履约 • 哪些信息可以自动获取、自动填充 • 哪些审批是必要的，哪些是历史遗留 • 哪些异常情况必须提前告知用户 设计不做好，支持就会在后端反复补信息，来回问用户，体验一定差。

3. 获取：能力与工具要准备好 比如身份系统、审批系统、资产系统、自动化编排能力、知识库、通知通道。获取阶段如果没准备好能力，支持就只能靠手工和人情推进。

4. 构建：把高频请求做成标准流程与自动化 构建阶段不是写流程图，而是把标准件做出来： • 表单字段合理 • 校验规则明确 • 自动化动作可回滚 • 通知与状态更新有节奏

5. 转换：上线前把口径和支持准备好 目录和请求也会变更。转换阶段要做的事很朴素： • 变更公告与说明 • 已知问题与应对 • 支持话术与升级路径 否则目录一改，用户一头雾水，支持就被打爆。

6. 运营与支持：用数据把目录越做越轻 运营与支持阶段要关注的是： • 哪些请求量最大 • 哪些请求最容易卡住 • 哪些字段经常填错 • 哪些审批最慢 这些就是持续改进的抓手。

五、目录怎么做才“像产品”：先砍掉一半再说

服务目录最常见的问题不是不全，而是太全。太全的本质是：你没有做取舍。用户一旦需要在几十个选项里做选择，体验就已经输了一半。

我建议你从这几件事入手，效果很快：

• 把入口按用户目的来组织，而不是按部门组织

• 把Top 20请求做成“首页直达”，别让用户翻目录

• 每个请求页面写清楚三件事：需要什么、要多久、会给什么

• 把“常见误填点”写成提示，不要让支持人员反复问

• 对低频、模糊、不可标准化的内容，宁愿不放进目录，而是引导走咨询入口

目录不是越大越好，目录的核心指标是：用户能不能一次选对、一次提交就能走完。

六、请求履约怎么做才“顺”：让用户看到进度，比让他等更重要

体验差往往发生在等待阶段。用户不是不能等，他不能接受的是“等得没谱”。所以请求履约最值钱的改造，往往不是把处理时间从2小时变成1小时，而是把进度透明起来。

你可以做得很简单：

• 提交后立刻告诉用户：已收到、预计多久

• 每到关键节点就更新：已审批、已分派、处理中、已完成

• 发生异常就解释：缺什么信息、需要你做什么、预计多久恢复

这套节奏一旦跑起来，投诉会明显下降。

七、AI与自动化怎么用在目录与请求：先做“整理和沟通”，再做“协调”

ITIL 第5版强调AI治理，放到目录与请求场景里，其实非常实用。但要记住顺序：先把信息一致性和标准化做起来，再谈更深的自动协调。

更稳的用法包括：

• 整理：把请求聚类，识别高频与痛点，优化目录结构

• 生成：生成请求说明的草稿、提示语草稿、知识条目草稿

• 沟通：生成状态更新文案，提高一致性，但必须审核

• 洞察：预测请求量峰值，优化排班与资源

权限类请求尤其要有边界和审计，否则效率提高了，风险也会被放大。

我建议你选一件非常具体的事：

把Top 10高频请求做成样板，目标只有两个：

• 用户一次提交就能走完

• 支持不需要反复补信息

你只要把这十个请求做顺，支持压力会明显下降，用户体验也会明显提升。之后再扩展到Top 20、Top 30，就很自然了。

2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。

欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。