Wiki source code of 01 服务台 （已发布）

Version 22.1 by superadmin on 2021/01/29, 21:57
Show last authors
1 (% class="jumbotron" %)
2 (((
3 (% class="container" %)
4 (((
5 = =
6
7
8 需要下载 **ITIL 4服务台实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务台实践”即可。
9
10 [[image:http://itil4hub.cn/bin/download/C%20%E5%AE%9E%E8%B7%B5%E6%8C%87%E5%8D%97/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/WebHome/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20200929154759.png?rev=1.2||alt="微信图片_20200929154759.png"]]
11
12
13 **申明：**
14
15 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
16
17 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
18
19
20 **翻译**：傅盛 **审校**：秦佩君 **审核**：姚凯、严宝龙     
21 )))
22 )))
23
24
25 = 1 关于本文档 =
26
27 [[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=1]]
28
29 本文档提供服务台实践实用指南，分为五个主要部分，涵盖：
30
31 ●本实践的一般信息
32
33 ●本实践相关的流程和活动及其在服务价值链中的作用
34
35 ●参与本实践的组织和人员
36
37 ●支持本实践的信息和技术
38
39 ●对本实践的合作伙伴和供应商的考虑
40
41
42 == 1.1 ITIL 4资格认证计划 ==
43
44 [[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
45
46 本文档中的部分内容可作为以下教学大纲的一部分以供检查：
47
48 ● ITIL专家创建、交付和支持
49
50 ● ITIL专家交付利益干系人价值
51
52 详情请参考各部分教学大纲。
53
54
55 ----
56
57
58 = 2  一般信息 =
59
60 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=1]]
61
62 == ==
63
64 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=2]]
65
66 == 2.1 目的和描述 ==
67
68 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=3]]
69
70 * **关键信息**
71
72 服务台实践的目的是获取事件解决和服务请求的需求。服务台还应该是服务提供者为所有用户提供的接入点和单一联系点。
73
74 注：在一些组织中，服务台实践的主要目的是在服务提供者与用户之间建立有效的沟通界面，事件和服务请求只是沟通的两个主题。在这些组织中，这种实践的目的可能是：与所有用户建立有效的接入点和单一联系点；捕获事件解决和服务请求需求。组织可以并且应根据他们的目标和客观环境调整ITIL各项实践的目的声明和其他建议。
75
76 与其他实践一样，该实践涉及服务管理四维度模型的所有维度：
77
78 |服务管理维度  |服务台实践资源示例
79 |组织和人员|专门小组，有时被称为“服务台”
80 |信息和技术|专用信息系统，有时被称为“服务台”
81 |价值流和流程|与用户沟通的工作流和程序
82 |合作伙伴和供应商|相关第三方，在某些情况下被称为“服务台”
83
84 表2.1 服务管理维度示例
85
86 术语“服务台”可以指各种类型的资源和资源组。例如，许多组织中，服务台被认为是一个职能或一个团队。与任何团队一样，服务台团队可能会参与一些实践活动。这些可能包括服务台、事件管理、服务请求管理、问题管理、服务配置管理、关系管理等实践。
87
88 本实践指南描述服务台实践。当讨论其他团队、软件工具或流程时，这些实践会被明确指出。
89
90 服务台实践涉及服务提供商与用户沟通的所有价值流，其目的是确保这些沟通对所有相关方都是有效和便利的。
91
92
93 == 2.2 术语和概念 ==
94
95 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
96
97 === 2.2.1 沟通渠道 ===
98
99 服务台实践包括在用户和服务提供商之间建立有效、便利的沟通渠道。通常存在多个渠道时，需要进行有效渠道整合提供无缝、便捷的用户体验。
100
101 良好的沟通渠道允许用户和服务提供商以对各方都便利的方式交换信息，并保证信息质量。在这种情况下，术语“便利”的特征如表2.2所述。
102
103 |**“便利”特性**|**解释**
104 |可访问性|沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
105 |保障性|各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
106 |可用性|沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
107 |情境智能化|在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
108 |情感一致性（Emotional Alignment）|在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
109 |熟悉度|熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
110 |整合性|服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
111 |易用性（Usability）|(((
112 所有类型的界面都应该清晰、直观、有用和实用。
113
114
115 )))
116
117 表2.2沟通渠道的便利特性
118
119
120 表2.2中概述的特征与常用于评估和管理信息质量的特征类似，这些特征包括可用性、可靠性、可访问性、及时性、准确性和相关性。需要注意的是，信息质量可能取决于沟通质量；其他信息特征则取决于信息源和相关方。
121
122 多渠道通常用于服务提供者与用户之间的沟通。多渠道沟通可能很便利，但若不进行整合也会带来混乱。多渠道沟通提供无缝体验和信息流，其发展的极致即为全渠道沟通。
123
124 * **定义：全渠道沟通**
125
126 跨多个渠道的统一沟通，基于跨渠道的信息共享，提供无缝的沟通体验。
127
128
129 === 2.2.2 服务同理心 ===
130
131 * **定义：服务同理心**
132
133 通过识别、理解、预测和展现另一方的兴趣、需求、意图和体验，以建立、维护和改进服务关系的能力。
134
135 服务同理心对组织和那些参与服务管理的人很重要。服务支持客服不可能分担用户的沮丧，但他们应认同并理解和表示同情，同时相应地调整自身的行为。
136
137 尽管自动化沟通系统可以通过新兴技术的情感分析能力（基于语言、声音和面部表情）得到增强，但这些系统无法实现同理心。服务同理心通常是通过聊天、视频和语音通话等渠道以及面对面交流的人际互动实现。
138
139 服务同理心是用户满意度提升和服务提供商成功的重要因素。作为一个概念，服务同理心不仅应用于用户支持和相关服务交互的狭窄情景，它适用于所有的服务交互。
140
141
142 === 2.2.3 用户满意度 ===
143
144 服务台作为一种交流界面，对用户满意度、客户满意度提升和服务关系的整体成功具有重要影响。用户满意度的关键因素包括沟通渠道和互动的有效性与便利性。
145
146 * **定义： 决定性时刻（Moment Of Truth）**
147
148 客户或用户与组织的某个方面接触并对其服务质量产生印象的任何一段经历。它是设定和实现客户期望并最终达到客户满意的基础。
149
150 服务关系中的许多决定性时刻发生在用户和服务提供商的沟通过程中，因此在服务台实践中相当常见。总体用户满意度由许多因素决定，事实上通常来说服务质量比沟通便利更重要。
151
152 服务台实践也用于收集关于用户满意度的信息。调查或其他满意度研究工具通常使用这种实践建立的沟通渠道。为了有效地收集这些信息，本实践的沟通渠道应该被用户认为是可信的、有效的和方便的；否则，对调查和其他沟通的反馈可能会受到影响。
153
154
155 == 2.3 范围 ==
156
157 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
158
159 服务台实践的范围包括：
160
161 1. 在服务供应商和用户之间建立和维护沟通渠道和界面
162 1. 授权（enabling）、记录和跟踪服务提供商和用户之间的沟通
163
164 尽管一些活动和责任领域与服务台密切相关，但不包括在服务台实践中。表2.3中列出了这些活动和责任领域，以及对应的实践供参考。重要的是要记住，ITIL实践仅仅是在价值流情景下使用的工具集合，它们应根据情况的需要而组合起来使用。
165
166 |**活动**|**实践指南**
167 |事件解决和管理|事件管理
168 |服务请求的管理和实现|服务请求
169 |用户和服务提供商之间沟通的内容、时机和格式的定义|向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
170 |技术和服务性能监控|监控和事态管理
171 |改进计划的管理|持续改进
172 |服务提供商和利益相关方之间的沟通，而非与用户的沟通|关系管理
173 |维护和改进信息与知识的使用|知识管理
174
175 表2.3其他实践中描述的与服务台实践相关的活动
176
177
178 == 2.4 实践成功因素 ==
179
180 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
181
182 * **定义：实践成功因素（Practice Success Factor，PSF）**
183
184 实践为实现其目的所需的复杂功能性组件。
185
186 实践成功因素（PSF）不仅仅是一项任务或活动，它包括服务管理所有四个维度的组成部分。在一项实践中，PSFs相关的活动和资源的性质可能不同，但这些活动和资源共同确保实践的有效性。
187
188 服务台的实践包括以下PSFs：
189
190 1. 在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进
191 1. 实现用户沟通与价值流的有效整合
192
193 === ===
194
195 === 2.4.1 在服务提供商与用户间实现有效、高效和便利的沟通并持续改进 ===
196
197 用户和客户可用的支持渠道应该高效、有效且便利。通过为用户和客户提供满足其需求的渠道可以达到便利。用户的需求可能会根据地理区域、时间、首选语言和可访问性要求的不同而变化。服务越便利，用户体验越好。
198
199 沟通渠道和界面的选择由多种因素决定，这些因素包括：
200
201 * 服务关系模型
202
203 * 内部或外部
204 * 商业或资助（subsidized）
205 * 大规模、开箱即用或定制
206 * 企业或个人
207
208 * 服务关系类型
209
210 * 基本、合作或伙伴关系
211
212 * 服务用户档案
213
214 * 语言
215 * 年龄
216 * 社交媒体活动
217 * 技术使用模式和偏好
218 * 位置
219 * 文化
220 * 多样性
221
222 * 服务提供商档案
223
224 * 位置和组织架构
225 * 用户满意度战略
226 * 服务组合的规模和可变性
227 * 技术能力和限制
228
229 * 影响服务关系的外部因素，包括政治、经济、社会、技术、法律和环境因素
230
231 交流不仅仅是发送信息。永远不要假设一条信息已经被认可和理解。每位收件人可能会根据个人情况对消息进行不同的解读或理解。发送方应确保其消息达到预期的结果接收方应该检查并确认正确理解了收到的消息。
232
233 在选择和设计服务渠道时，非常重要的是考虑用户对服务使用的准备度以及相关的风险和机会。不同的渠道会带来不同的挑战；组织必须准备好克服这些挑战。表2.4列出了其中的一些挑战。
234
235 | |**渠道**|**挑战示例**|**解决方案示例**
236 |(% rowspan="6" %)(((
237 用
238
239 户
240
241 与
242
243 人
244
245 的
246
247 互
248
249 动
250 )))|语音|(((
251 有限的可扩展性
252
253 主观态度和情绪
254 )))|投资于支持型客服的职业发展、情商、对不同文化的认知和兴趣
255 |实时聊天|主观态度和情绪|将人力支持限制在需要和合理的地方
256 |电子邮件|(((
257 非结构化信息
258
259 主观态度和情绪
260 )))|在适当的情况下，利用可用资源自动记录非结构化信息
261 |走访|(((
262 有限的可扩展性
263
264 主观态度和情绪
265 )))|(% rowspan="3" %)(((
266
267
268 情况合适时推行自助服务以增加接待能力
269
270 提供明确的安全参数，并定期测试其有效性
271 )))
272 |驻场|(((
273 有限的规模和可用性
274
275 主观态度和情绪
276 )))
277 |社交媒体|(((
278 病毒效应，错误和冲突的高曝光率
279
280 主观态度和情绪
281
282 非结构化信息
283
284 安全约束
285 )))
286 |(((
287 用
288
289 户
290
291 与
292
293 技
294
295 术
296
297 的
298
299 互
300
301 动
302 )))|网络门户，（电话）互动语音菜单，移动应用，聊天机器人以及其他|(((
303 用户可以在其安全级别上完成范围有限的任务
304
305 数据不充分、不足够
306
307 用户技术技能不充分、不足够
308
309 缺乏服务同理心和情商
310
311 面对复杂环境的有限适用性
312 )))|(((
313 在实施自助前，评估用户技能和可用的支持操作范围
314
315 使用用户熟悉的渠道和界面
316
317 确保高质量的历史数据和知识支持
318
319 当使用机器学习时，确保数据和算法的高质量
320
321 提供人工备份支持选项
322
323 改进信息质量和导航工具
324
325 确保尽可能容易获得自助工具和行动
326 )))
327
328 表2.4 渠道示例及其挑战
329
330
331 在大多数情况下，服务提供者使用多种渠道。重要的是确保各渠道间有效整合。沟通应是全渠道，而非多渠道。一段无缝的用户旅程，有可能在信息不丢失或损坏的情况下，在不同的渠道间切换，促进积极的用户体验。没有充分整合的多渠道沟通很可能会造成混乱并引发错误。图2.1演示了如何使用多种渠道支持用户。
332
333 (% style="text-align:center" %)
334 [[image:1600929628284-534.png]]
335
336 图2.1多种沟通渠道
337
338
339 在非集成的多渠道沟通中，渠道间会有信息隔阂。例如，电话问询、在移动应用程序中的预约以及与来访工程师的沟通都可能需要重新输入（重新沟通）以触发呼叫支持服务。另一方面，在全渠道沟通中，情景将不断更新，并且可重用的数据将在任何关联的地方都可用。例如，用户在同一登录账号下执行的所有浏览和咨询都会添加到情景中，支持专家都可以看到。用户支持客服和来访工程师都可以获得所有相关数据。
340
341 换而言之，在多渠道沟通中，用户将在每条渠道开始新的旅程。在全渠道沟通中，旅程持续并在不同渠道间便利地切换。
342
343
344 === 2.4.2 实现用户沟通与价值流的有效整合 ===
345
346 作为服务提供商与用户双向沟通的节点，服务台实践的一个关键重点是有效地捕获、记录沟通信息并将其集成到相关的价值流中。像所有实践一样，本实践涉及多条价值流：只要服务提供商和用户之间需要沟通。
347
348 由服务提供者发起的沟通由价值流中涉及的一个或多个其他实践共同定义和执行。例如，关于服务计划变更的沟通由变更支持实践和发布管理实践共同发起和执行。作为服务台实践的一部分，建立和管理沟通渠道，但沟通的内容、格式和时间的定义是价值流情景中变更支持实践和发布管理实践的一部分。
349
350 然而，当用户发起沟通时，并不清楚属于哪条价值流，应该触发哪项ITIL实践活动。服务台实践为所有用户问询（包括咨询、事件、服务请求、投诉和表扬）的有效分类提供沟通界面和程序。当对用户查询进行分类并确定相关的价值流和实践后，将根据各自实践的流程和程序处理查询。有时，这涉及服务台团队资源和/或信息系统。
351
352
353 == 2.5 关键指标 ==
354
355 [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
356
357 应在每个实践所贡献的价值流情境中评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用的情景中评估。然而，在设计和质量上，工具可能有很大的差异。当根据工具的目的使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准、关键绩效指标（Key Performance Indicators， KPIs）和其他有助于实现这一点的技术的进一步指导，请参见度量和报告实践指南。
358
359 服务台实践的关键指标映射到其PSFs上。这些PSFs可以用作价值流情景下的KPIs，评估实践对这些价值流效能和效率的贡献。表2.5给出了一些关键指标的示例。
360
361 |实践成功因素|指标示例
362 |在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(((
363 通过服务台渠道接收的信息的质量，根据商定的信息质量标准衡量
364
365 服务台沟通渠道和界面的便利性，根据商定的便利性标准衡量
366
367 沟通关键利益相关者对信息质量和服务台沟通渠道的便利性的满意度
368 )))
369 |实现用户沟通与价值流的有效整合|(((
370 与价值流的要求相比，通过服务台渠道接收到的信息的质量
371
372 关键利益相关者对通过服务台渠道传达信息的的满意度
373
374 用户查询分类不正确的数量和百分比
375 )))
376
377 表2.5实践成功因素的关键指标示例
378
379
380 将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理以及服务台实践的定期评估和持续改进。对此没有唯一的最佳解决方案。度量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
381
382
383 ----
384
385 = 3 价值流和流程 =
386
387
388 == 3.1价值流贡献 ==
389
390 [[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=3]]
391
392 像任何其他ITIL管理实践一样，服务台实践对多条价值流有帮助。重要的是要记住，价值流从来不是由单一实践形成的。服务台实践与其他实践相结合，为客户提供高质量的服务。这种实践促成的主要价值链活动有：
393
394 ●契动
395
396 ●交付和支持。
397
398 服务台实践对服务价值链的贡献如图3.1所示。
399
400 (% style="text-align:center" %)
401 [[image:1600929812191-791.png]]
402
403 (% class="row" %)
404 (((
405 (% class="col-xs-12 col-sm-4" style="left: 106px; top: 362px;" %)
406 (((
407 图3.1 服务台实践对价值链贡献的热力图
408
409
410 == 3.2过程 ==
411
412 [[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=4]]每个实践可以包括一个或多个流程和活动，这是实现这一实践目的所必需的。
413
414 * **定义：流程**
415
416 将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了操作的顺序及依赖关系。
417
418 服务台活动分为三个流程：
419
420 1. 用户查询处理
421 1. 与用户沟通
422 1. 服务台优化
423
424
425 === 3.2.1 用户查询处理 ===
426
427 该流程确保对用户查询的捕获、验证和分类，以便进一步处理。它包括表3.1中列出的活动，并将输入转化为输出。
428
429 |**关键输入**|**活动**|**关键输出**
430 |用户查询|确认并记录用户的查询|记录并分类用户的查询
431 |服务管理记录，例如，事件记录、变更记录、问题记录等|用户查询的验证|开始处理已分类的用户查询
432 |服务配置信息、IT资产信息以及其它相关信息|对用户查询进行初步处理并启动适当的活动|
433
434 表3.1 用户查询处理流程的输入、活动和输出
435
436
437 图3.2 展示该流程的工作流图
438
439 (% style="text-align:center" %)
440 [[image:1600929854496-543.png]]
441
442
443 图3.2 用户查询处理的工作流
444
445
446 表3.2将用户查询处理过程中每个人工交互和自动化活动进行比较。
447
448 |**活动**|**与服务台团队的人工交互**|**自动化自服务**
449 |确认并记录用户查询|(((
450 当用户出于任何原因访问服务提供者时，期望得到快速的人工响应。
451
452 尽管有越来越多的替代和更有效的方法帮助用户，传统的电话支持、电子邮件和走访习惯不太可能消失。
453
454 在纯技术或B2B服务交付环境中，人工交互也能使人产生同理心和安慰。
455
456 除了自动化支持之外，任何抵达服务台客服的查询都应以礼貌和标准的方式满足，这样用户就可以感受到一定质量级别的服务，表明其查询受到服务提供者的欢迎。
457
458 每个交互都必须记录下来（例如，在查询日志或用户查询管理和工作流工具中唯一标识）。
459
460 需要设计激励机制鼓励服务台客服记录问询信息。保存的记录是服务质量的宝贵数据来源，而自动化是是实现这一点的关键。
461 )))|(((
462 在用户需要人工响应前，可在预处理阶段响应查询，目的是快速解决问题 。这些通常称为自服务工具。
463
464 例如，当用户呼叫服务台电话号码时，可能会有一个预先录制的问候语，这是称为IVR（交互式语音应答）的自动化系统的一部分。IVR的几个更广泛的功能可以帮助呼叫者：
465
466 * 提供用户呼叫原因的分类选项。这既可以自动化查询分类，又可以向调用者建议查询已知解决方案的路径
467 * 发布重要通知，关于正在进行的服务暂停或即将发生的影响用户的变更
468 * 提供自动化参考服务
469 * 提供语音邮件功能
470 * 确认来电者身份
471 )))
472 |验证用户查询|(((
473 服务台客服可以在记录查询时执行查询验证。不同的检查适用于某些类型的查询：
474
475 * 用户是否是他们声称的那个人
476 * 用户及其组织是否有资格使用指定的服务。这在提供商业服务时尤其重要，因为商业服务需要收费，且容易出现欺诈
477 * 呼叫的原因是否与相关服务有关；例如，是否在服务提供者的职责范围内?
478 * 在处理查询过程中是否需要传达任何受保护的信息，如果需要，是否需要进行额外的呼叫者身份检查
479
480 虽然数据源（如服务目录或IAM）支持这些检查，但服务台客服负责验证查询。
481 )))|(((
482 当使用自服务工具自动处理用户与服务提供者间的首次联系时，查询验证的某些方面将实现自动化。
483
484 自动验证可以内置到用户旅程中，进行增强和定制化，并限制用户体验的可变性。
485
486 例如，若用户在自服务门户中通过了授权和身份验证检查，集成的工具集可以根据服务目录匹配其记录，并根据资格、角色、地理位置、可用库存等向其提供适用的服务产品和功能。
487 )))
488 |对用户查询进行出初步处理并启动适当的活动|(((
489 初步处理通常意味着根据对象的特征、紧急程度和处理它们可能带来的收益，对呼入队列进行排序。服务提供者对用户查询初步处理还意味着对查询进行归类，并可以对已知的查询类型使用预定义的活动序列。
490
491 对一些基本的问询初步处理可以使服务台坐席在与用户的首次对话过程中就解决掉问询问题。服务台需要谨慎地平衡其处理问询和进行技术技巧沟通的能力，对于时间密集型任务更是如此。
492
493 然而在通常情况下，初步处理的结果涉及到启动一个特定的价值流。
494
495 因此，服务台实践需要与服务提供的其他实践紧密结合。这些实践将为服务台实践提供有关初步处理特性及其相对重要性的指导。参考//ITIL驱动利益相关者价值//，表8.4（译注：此处为笔误）给出了一个初步处理标准的示例映射，以及满足标准时触发的相关实践。
496
497 最后，即使查询不需要进一步操作（例如“错误号码”的呼叫），服务台客服也必须确保在查询记录中捕获了足够的关于交互的信息，这些信息至少包括时间、持续时长和内容。
498 )))|(((
499 用户查询处理的自动化确保交互的公正记录。对于预估用户支持的总体需求或计算未解决呼叫的比率等基本的改进和优化活动，也是非常有用的。
500
501 基于前面步骤中收集的数据，自动查询分类可以减少人工工作和在初步处理和路由查询上所花费的时间。
502
503 使用自动化后，一些查询类型可在无人工交互的情况下解决（例如，分析查询的情景并向用户建议自助指南或诊断步骤），或者使用最少的人工交互解决。
504
505 后一种方法的一个例子是将新应用的服务的所有查询直接路由到新服务早期支持团队。关于该服务的任何查询都将绕过服务台，直接发送到相应的团队。这确保用户的快速响应体验，并减轻了服务台团队的压力。它也相对容易实施解决方案和消除问题。
506
507 可以引入更复杂的规则，根据查询的参数将查询路由到特定的解决团队。重要的是要平衡问询表单的复杂性和自动化用户界面的简单性。界面设计应该鼓励用户沟通他们的问询，以便服务提供者可捕获最大可能的需求。
508 )))
509
510 表3.2自动化与人工交互比较
511
512
513 === 3.2.2 与用户沟通 ===
514
515 这个过程确保通过适当的渠道将各种类型的信息传达给用户。它包括表3.3所列的活动，并将输入转换成输出。
516
517 |**关键输入**|**活动**|**关键输出**
518 |(((
519 用户沟通需求
520
521 沟通的信息
522
523 以前的沟通记录
524
525 服务管理记录，例如事件记录、变更记录、问题记录等
526
527 服务配置信息、IT资产信息及其他相关信息
528 )))|(((
529 识别并确认目标受众
530
531 识别并确认沟通渠道
532
533 信息打包
534
535 信息发送
536
537 收集和处理接受者的确认和反馈
538 )))|(((
539 沟通消息
540
541 沟通报告
542 )))
543
544 表3.3 与用户沟通过程的输入、活动和输出
545
546
547 服务提供者和用户间的所有沟通都应该包括在此过程中。与用户沟通过程的需求通常由各种实践确定。沟通通常是标准化和自动化的，例如关于事件状态变化的通知。在某些情况下，还需要使用沟通流程将异常或其他重要信息传达给不同的受众。
548
549 图3.3展示该流程的工作流图。
550
551 (% style="text-align:center" %)
552 [[image:1600930001924-317.png]]
553
554 图3.3与用户沟通过程的工作流
555
556
557 表3.4概述了与先前已登记的查询相关的沟通过程活动。
558
559 |**活动**|**针对之前登记的查询进行个性化沟通**|**公众沟通**
560 |识别并确认目标受众|(((
561 无论目标受众数量多少，服务台的每次对外交互都必须符合服务提供者所维护的一致的质量标准。
562
563 问询记录的状态更新也是一种需要仔细设计的对外沟通。根据问询的性质，可以有利益相关者或服务提供者的员工等多个消息接收者。大多数情况下，用户查询管理和工作流工具将跟踪每个用户查询的接收者，服务台实践将提供此项功能设计的输入。
564 )))|(((
565 这可以是重大事件解决通知、与变更相关的即将到来的服务中断、年度用户满意度调查等。
566
567 无论公众沟通的需求来自于哪种实践或过程，服务台实践保证沟通的标准，对传播的内容进行质量控制，并代表服务提供者组织收集反馈。
568
569 服务提供者应该定义一个服务台请求公众沟通的流程。这种沟通的目标受众可以由请求者提出，但应由服务台验证。这是因为服务台最了解用户是谁，用户喜欢何种沟通风格等等。
570
571 集中式用户沟通的另一个重要的文化挑战是确保服务台团队受到重视。
572 )))
573 |识别并确认沟通渠道|(((
574 在全渠道范例中，用户应能决定服务提供者应通过哪个渠道交付信息。
575
576 服务提供者可决定在SLA中包含的用户沟通需求，这时服务台客服应选择适当的渠道。
577 )))|(((
578 定义目标受众后，服务台必须为该受众和消息类型定义适当的沟通渠道。
579
580 一般性通知等沟通可以在自助服务门户或社交媒体上以醒目形式发布。而选定的用户计算机的IT资产核查等其他沟通可能需要保证交付和反馈闭环。
581
582 理想情况下，沟通渠道应通过SLA协商并确定。若非如此，服务台团队应视为最适合的沟通渠道中了解用户受众的专家。
583
584 这不包括为客户和赞助商服务的营销沟通。因为这些受众和消息超出了服务台实践的目的范围。然而，服务台团队可能会参与传递此类消息。
585 )))
586 |信息打包|(((
587 在自动化服务交付环境中，通常用一组模板生成问询记录生命周期中所有的通知类型。
588
589 用户查询管理和工作流工具通常与配置和资产管理工具以及其他数据源集成在一起。应该定期验证标准问询通知模板，这样对链接数据源的变更就不会产生空白项，避免消息显得不专业。商业和大规模服务提供商尤其应该避免使用过于复杂和伪个性化的模板。
590
591 问询记录生命周期更新之外的自定义人工沟通也应以公司模板的形式呈现，并清晰地说明沟通的目的、相关的查询记录和内容。一些服务提供商将企业沟通培训纳入服务台团队发展计划中；其他提供商则由服务台经理或其他管理部门批准服务台客服发起对外沟通的策略。
592 )))|(((
593 服务台应审查和编纂任何请求沟通的实际消息，以便更有可能以用户最了解的术语和样式沟通。
594
595 例如，从用户的角度看，“WEBAPPS_SRV01因为安装核心补丁将在周六晚上暂停服务”和“这周末我们将优化系统。预计网上银行将从周六下午6点到周日下午12点无法提供服务。我们的新手机银行应用程序将照常运行。谢谢你的耐心!”相比，前者远无法让人满意。
596 )))
597 |信息发送|(((
598 通常沟通信息是自动发出的，电子邮件最常用于用户沟通。然而，在一些规范的服务交付环境中，书面沟通或个人访问更为合适。
599
600 根据用户沟通环境的不同，必须向服务台人员提供明确的指导，说明哪种交付格式适合哪种类型的用户和沟通。例如，终止与公用事业提供商服务契约的查询，需要在处理正常的问询记录的同时，通过挂号信服务的方式向客户发送最终帐户余额信息。
601 )))|(((
602 服务台工作人员还可以对用户的文化有第一手了解，这将使他们能够选择适当的沟通和交付方式。
603
604 对于某些类型的通信可以有一个最终的批准程序，通常服务台经理或具有同等权力的角色可以以服务提供者服务台的名义发出这类消息。
605 )))
606 |收集和处理接收者确认和反馈|(((
607 “请不要回复此邮件”可以说是一种不完美的做法，但仍广泛采用。即使消息的内容与他们有关，这一行文字也不鼓励大多数用户回复该消息。
608
609 欢迎来自用户的反馈总是明智的。在全渠道范例中，用户应该能够选择任何合法及合理的渠道，尽可能方便地访问服务提供者。
610
611 收集和处理反馈还伴随着对某些类型的商业沟通的法定要求，要求来自服务用户的响应以进行后续查询，例如接收者的确认或报价的接受。在这些情况下，服务台客户需要有开放式任务跟踪未回复的请求，并通过不同的沟通渠道联系用户。应该控制不成功尝试的阈值，以避免激怒用户。
612 )))|(((
613 每个公众沟通需要有一个明确的参考反馈渠道，用户应该使用这一渠道。这个渠道可能会返回到服务台，与特定公众沟通相关的查询必须被标识、记录和处理（可能由该沟通的发起者进行处理）。
614
615 未能处理的公众沟通反馈可能会导致信誉的急剧下降和用户对来自服务提供商的公众沟通的关注。
616 )))
617
618 表3.4关于先前已登记的查询的沟通过程活动
619
620
621 === 3.2.3 服务台优化 ===
622
623 这一流程确保从管理用户沟通中吸取经验教训，并不断改进这一实践。它包括表3.5中列出的活动，并将输入转化为输出。
624
625 |**关键输入**|**活动**|**关键输出**
626 |(((
627 服务台绩效报告
628
629 满意度调查结果
630
631 技术机遇
632
633 事件和服务请求报告
634 )))|(((
635 服务台回顾
636
637 服务台优化启动
638
639 服务台优化沟通
640 )))|服务台优化沟通
641
642 表3.5 服务台优化流程的输入、活动和输出
643
644
645 图3.4展示服务台优化流程的工作流图
646
647 (% style="text-align:center" %)
648 [[image:1600930052354-753.png]]
649
650 图3.4服务台优化过程的工作流
651
652
653 表3.6概述了服务台优化过程的活动。
654
655 |**活动**|**描述**
656 |服务台回顾|服务台团队经理与其他相关干系人一起回顾各种输入。确定改进这一实践的机会。
657 |服务台优化启动|服务台团队经理记录改进计划。计划将通过引入持续改进实践或启动变更请求进行处理。
658 |服务台优化沟通|如果服务台成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由服务台经理通过沟通过程完成。
659
660 表3.6 服务台优化过程活动
661 )))
662 )))
深圳市艾拓先锋企业管理咨询有限公司