Last modified by superadmin on 2026/02/20, 07:06
Hide last authors
superadmin 1.1 1 很多组织的服务目录，看起来很“齐全”，点进去却让人头大：
2
superadmin 5.1 3 一堆名词、几十个分类、各种缩写，用户根本不知道该点哪个。 好不容易选了一个，表单长得像报税，填到一半还要问同事“这个字段怎么写”。 最后用户干脆不走目录了，直接找熟人、直接私聊支持、直接在群里@人。
superadmin 1.1 4
5
6 然后支持团队就开始抱怨：“你们为什么不走流程？”
7
8 用户也开始抱怨：“你们的流程为什么这么难用？”
9
10
superadmin 5.1 11 这种矛盾很常见，但我想说一句实话：很多服务目录并不是“服务目录”，更像“内部仓库清单”。 它满足了管理的整齐，却没满足用户的顺手。 你把入口做得别扭，用户自然会绕开；用户一绕开，支持就会更乱；支持越乱，你越想加规则，最后就是恶性循环。
superadmin 1.1 12
13
superadmin 5.1 14 ITIL 第5版之所以值得你重新看服务目录与服务请求，是因为它把管理对象扩展到数字产品与数字服务，并强调体验优先。 换句话说，第5版很像在提醒你：目录和请求不是后台管理功能，它们就是你的“产品门面”。 门面不好用，再好的后台也救不了。
superadmin 1.1 15
16
17 == 一、为什么目录与请求在第5版里更像“产品化能力” ==
18
19
20 ITIL 第5版相对 ITIL 4 的核心升级要点如下：
21
22 • 管理对象从服务扩展到数字产品与数字服务
23
24 • 价值链演进为八个阶段活动的全生命周期：发现、设计、获取、构建、转换、运营、交付、支持
25
26 • 体验被写入价值定义，强调可感知的结果与信任
27
28 • 治理更强调责任、选择与纠偏，而不是统一模板
29
30 • AI 与自动化纳入体系，强调能力分层与治理边界
31
superadmin 5.1 32 服务目录与服务请求落在哪？它们直接影响交付与支持，也影响体验。 更关键的是，它们会把组织的边界、承诺、标准化程度暴露给用户。 目录做得清，用户预期就稳；请求履约做得顺，支持就会轻。
superadmin 1.1 33
34
35 == 二、服务目录到底是什么：不是清单，是承诺与预期管理 ==
36
37
superadmin 5.1 38 很多团队做服务目录，思路是“把我们能提供的都列出来”。 这听起来很合理，但用户真正想知道的通常是：
superadmin 1.1 39
40 • 我该找谁
41
42 • 我能得到什么
43
44 • 要多久
45
46 • 需要我准备什么
47
48 • 出问题怎么办
49
superadmin 5.1 50 这就是目录真正的价值：它是一份承诺的说明书，也是预期管理的工具。 你目录里如果只写“账号开通、权限申请、VPN申请”，但不写清楚“多长时间、需要什么信息、哪些情况会被拒绝、审批路径是什么”，用户就会自行脑补预期，脑补出来的预期往往比你能做到的更高。 后面体验差、投诉多，其实是预期没管住。
superadmin 1.1 51
52
superadmin 5.1 53 (% style="text-align:center" %)
54 [[image:3.jpg||height="283" width="549"]]
superadmin 1.1 55
56 所以服务目录要做得像产品：信息要让用户一眼看懂，承诺要能兑现，边界要明确。
57
58
59 == 三、服务请求为什么会变成工单堆：因为你把“标准化履约”做成了“人工处理” ==
60
61
superadmin 5.1 62 服务请求的本质，是标准化履约。 比如开通账号、申请权限、发放设备、创建项目空间、恢复访问、重置密码。 这些事情如果每次都靠支持人工判断、人工沟通、人工推进，那你越做越累是必然的。
superadmin 1.1 63
64
65 ITIL 第5版强调价值链全生命周期和治理，从请求视角看就是：
66
67 • 你要把高频请求变成标准件
68
69 • 标准件要有固定输入、固定输出、固定时效
70
71 • 能自动化的尽量自动化，但边界要清楚
72
73 • 请求履约要能被度量和持续改进
74
superadmin 5.1 75 把请求做顺，支持压力会明显下降；支持压力下降，体验反而会上来。 很多人觉得这矛盾，其实不矛盾——支持最累的时候，体验往往最差。
superadmin 1.1 76
77
78 == 四、用八个阶段活动把目录与请求做“端到端”：别只在支持端修修补补 ==
79
80
superadmin 5.1 81 你如果只在支持端优化目录和请求，比如改表单、改分类、加入口，很容易治标不治本。 ITIL 第5版的八个阶段活动给你一个更完整的视角：目录和请求从发现开始就应该被设计。
superadmin 1.1 82
83
superadmin 5.1 84 (% style="text-align:center" %)
85 [[image:d4aeb615-48e4-46cf-87ef-1a6687d8fb93.jpg||height="101" width="490"]]
superadmin 1.1 86
87
88 1. (((
superadmin 5.1 89 **发现**：先搞清楚用户为什么来找你 很多目录失败是因为分类按内部组织结构来，而不是按用户目的来。 用户不是来找“基础架构部服务”的，用户是来“快速开通能用的东西”的。 发现阶段要做的是识别用户意图：他们最常要什么、最焦虑什么、最怕填什么、最讨厌等多久。
superadmin 1.1 90 )))
91 1. (((
92 **设计**：把请求设计成“最小输入、最大确定性” 设计阶段要决定： • 用户必须填哪些信息才能完成履约 • 哪些信息可以自动获取、自动填充 • 哪些审批是必要的，哪些是历史遗留 • 哪些异常情况必须提前告知用户 设计不做好，支持就会在后端反复补信息，来回问用户，体验一定差。
93 )))
94 1. (((
superadmin 5.1 95 **获取**：能力与工具要准备好 比如身份系统、审批系统、资产系统、自动化编排能力、知识库、通知通道。 获取阶段如果没准备好能力，支持就只能靠手工和人情推进。
superadmin 1.1 96 )))
97 1. (((
98 **构建**：把高频请求做成标准流程与自动化 构建阶段不是写流程图，而是把标准件做出来： • 表单字段合理 • 校验规则明确 • 自动化动作可回滚 • 通知与状态更新有节奏
99 )))
100 1. (((
superadmin 5.1 101 **转换**：上线前把口径和支持准备好 目录和请求也会变更。 转换阶段要做的事很朴素： • 变更公告与说明 • 已知问题与应对 • 支持话术与升级路径 否则目录一改，用户一头雾水，支持就被打爆。
superadmin 1.1 102 )))
103 1. (((
104 **运营与支持**：用数据把目录越做越轻 运营与支持阶段要关注的是： • 哪些请求量最大 • 哪些请求最容易卡住 • 哪些字段经常填错 • 哪些审批最慢 这些就是持续改进的抓手。
105 )))
106
107 === 五、目录怎么做才“像产品”：先砍掉一半再说 ===
108
109
superadmin 5.1 110 服务目录最常见的问题不是不全，而是太全。 太全的本质是：你没有做取舍。 用户一旦需要在几十个选项里做选择，体验就已经输了一半。
superadmin 1.1 111
112
113 我建议你从这几件事入手，效果很快：
114
115 • 把入口按用户目的来组织，而不是按部门组织
116
117 • 把Top 20请求做成“首页直达”，别让用户翻目录
118
119 • 每个请求页面写清楚三件事：需要什么、要多久、会给什么
120
121 • 把“常见误填点”写成提示，不要让支持人员反复问
122
123 • 对低频、模糊、不可标准化的内容，宁愿不放进目录，而是引导走咨询入口
124
125 目录不是越大越好，目录的核心指标是：用户能不能一次选对、一次提交就能走完。
126
127
128 == 六、请求履约怎么做才“顺”：让用户看到进度，比让他等更重要 ==
129
130
superadmin 5.1 131 体验差往往发生在等待阶段。 用户不是不能等，他不能接受的是“等得没谱”。 所以请求履约最值钱的改造，往往不是把处理时间从2小时变成1小时，而是把进度透明起来。
superadmin 1.1 132
133
134 你可以做得很简单：
135
136 • 提交后立刻告诉用户：已收到、预计多久
137
138 • 每到关键节点就更新：已审批、已分派、处理中、已完成
139
140 • 发生异常就解释：缺什么信息、需要你做什么、预计多久恢复
141
142 这套节奏一旦跑起来，投诉会明显下降。
143
144
145 == 七、AI与自动化怎么用在目录与请求：先做“整理和沟通”，再做“协调” ==
146
147
superadmin 5.1 148 ITIL 第5版强调AI治理，放到目录与请求场景里，其实非常实用。 但要记住顺序：先把信息一致性和标准化做起来，再谈更深的自动协调。
superadmin 1.1 149
150
superadmin 5.1 151 (% style="text-align:center" %)
152 [[image:2.jpg||height="282" width="288"]]
superadmin 1.1 153
154 更稳的用法包括：
155
156 • **整理**：把请求聚类，识别高频与痛点，优化目录结构
157
superadmin 5.1 158 •** 生成：**生成请求说明的草稿、提示语草稿、知识条目草稿
superadmin 1.1 159
160 • **沟通**：生成状态更新文案，提高一致性，但必须审核
161
162 • **洞察：**预测请求量峰值，优化排班与资源
163
164 权限类请求尤其要有边界和审计，否则效率提高了，风险也会被放大。
165
166
167 我建议你选一件非常具体的事：
168
169 把Top 10高频请求做成样板，目标只有两个：
170
171 • 用户一次提交就能走完
172
173 • 支持不需要反复补信息
174
superadmin 5.1 175 你只要把这十个请求做顺，支持压力会明显下降，用户体验也会明显提升。 之后再扩展到Top 20、Top 30，就很自然了。
superadmin 1.1 176
177
178 2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
179
superadmin 5.1 180
181
superadmin 1.1 182 欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。
深圳市艾拓先锋企业管理咨询有限公司