文档更改服务管理实践 - 01 服务台

由 superadmin 于 2024/12/25, 15:37 最后修改

从版本< 62.1 >

由superadmin编辑
在2022/01/15, 16:41上

到版本

由superadmin编辑
在2022/01/15, 16:40上

< >

修改评论上传新附件1642236047390-499.png

Raw
已渲染

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -80,12
          +80,11 @@
  与其他实践一样，该实践涉及服务管理四维度模型的所有维度：
--(% style="width:445px" %)
--|(% style="width:152px" %)服务管理维度  |(% style="width:290px" %)服务台实践资源示例
--|(% style="width:152px" %)组织和人员|(% style="width:290px" %)专门小组，有时被称为“服务台”
--|(% style="width:152px" %)信息和技术|(% style="width:290px" %)专用信息系统，有时被称为“服务台”
--|(% style="width:152px" %)价值流和流程|(% style="width:290px" %)与用户沟通的工作流和程序
--|(% style="width:152px" %)合作伙伴和供应商|(% style="width:290px" %)相关第三方，在某些情况下被称为“服务台”
++|服务管理维度  |服务台实践资源示例
++|组织和人员|专门小组，有时被称为“服务台”
++|信息和技术|专用信息系统，有时被称为“服务台”
++|价值流和流程|与用户沟通的工作流和程序
++|合作伙伴和供应商|相关第三方，在某些情况下被称为“服务台”
  表2.1 服务管理维度示例
@@ -106,16
          +106,15 @@
  良好的沟通渠道允许用户和服务提供商以对各方都便利的方式交换信息，并保证信息质量。在这种情况下，术语“便利”的特征如表2.2所述。
--(% style="width:572px" %)
--|(% style="width:178px" %)**“便利”特性**|(% style="width:392px" %)**解释**
--|(% style="width:178px" %)可访问性|(% style="width:392px" %)沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
--|(% style="width:178px" %)保障性|(% style="width:392px" %)各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
--|(% style="width:178px" %)可用性|(% style="width:392px" %)沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
--|(% style="width:178px" %)情境智能化|(% style="width:392px" %)在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
--|(% style="width:178px" %)情感一致性（Emotional Alignment）|(% style="width:392px" %)在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
--|(% style="width:178px" %)熟悉度|(% style="width:392px" %)熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
--|(% style="width:178px" %)整合性|(% style="width:392px" %)服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
--|(% style="width:178px" %)易用性（Usability）|(% style="width:392px" %)(((
++|**“便利”特性**|**解释**
++|可访问性|沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
++|保障性|各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
++|可用性|沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
++|情境智能化|在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
++|情感一致性（Emotional Alignment）|在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
++|熟悉度|熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
++|整合性|服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
++|易用性（Usability）|(((
  所有类型的界面都应该清晰、直观、有用和实用。
@@ -170,15
          +170,14 @@
  尽管一些活动和责任领域与服务台密切相关，但不包括在服务台实践中。表2.3中列出了这些活动和责任领域，以及对应的实践供参考。重要的是要记住，ITIL实践仅仅是在价值流情景下使用的工具集合，它们应根据情况的需要而组合起来使用。
--(% style="width:540px" %)
--|(% style="width:217px" %)**活动**|(% style="width:320px" %)**实践指南**
--|(% style="width:217px" %)事件解决和管理|(% style="width:320px" %)事件管理
--|(% style="width:217px" %)服务请求的管理和实现|(% style="width:320px" %)服务请求
--|(% style="width:217px" %)用户和服务提供商之间沟通的内容、时机和格式的定义|(% style="width:320px" %)向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
--|(% style="width:217px" %)技术和服务性能监控|(% style="width:320px" %)监控和事态管理
--|(% style="width:217px" %)改进计划的管理|(% style="width:320px" %)持续改进
--|(% style="width:217px" %)服务提供商和利益相关方之间的沟通，而非与用户的沟通|(% style="width:320px" %)关系管理
--|(% style="width:217px" %)维护和改进信息与知识的使用|(% style="width:320px" %)知识管理
++|**活动**|**实践指南**
++|事件解决和管理|事件管理
++|服务请求的管理和实现|服务请求
++|用户和服务提供商之间沟通的内容、时机和格式的定义|向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
++|技术和服务性能监控|监控和事态管理
++|改进计划的管理|持续改进
++|服务提供商和利益相关方之间的沟通，而非与用户的沟通|关系管理
++|维护和改进信息与知识的使用|知识管理
  表2.3其他实践中描述的与服务台实践相关的活动
@@ -238,10
          +238,99 @@
  在选择和设计服务渠道时，非常重要的是考虑用户对服务使用的准备度以及相关的风险和机会。不同的渠道会带来不同的挑战；组织必须准备好克服这些挑战。表2.4列出了其中的一些挑战。
--[[image:1642235400045-491.png]]
++| |**渠道**|**挑战示例**|**解决方案示例**
++|(% rowspan="6" %)(((
++用
--[[image:1642235424757-755.png]]
++户
++与
++
++人
++
++的
++
++互
++
++动
++)))|语音|(((
++有限的可扩展性
++
++主观态度和情绪
++)))|投资于支持型客服的职业发展、情商、对不同文化的认知和兴趣
++|实时聊天|主观态度和情绪|将人力支持限制在需要和合理的地方
++|电子邮件|(((
++非结构化信息
++
++主观态度和情绪
++)))|在适当的情况下，利用可用资源自动记录非结构化信息
++|走访|(((
++有限的可扩展性
++
++主观态度和情绪
++)))|(% rowspan="3" %)(((
++
++
++情况合适时推行自助服务以增加接待能力
++
++提供明确的安全参数，并定期测试其有效性
++)))
++|驻场|(((
++有限的规模和可用性
++
++主观态度和情绪
++)))
++|社交媒体|(((
++病毒效应，错误和冲突的高曝光率
++
++主观态度和情绪
++
++非结构化信息
++
++安全约束
++)))
++|(((
++用
++
++户
++
++与
++
++技
++
++术
++
++的
++
++互
++
++动
++)))|网络门户，（电话）互动语音菜单，移动应用，聊天机器人以及其他|(((
++用户可以在其安全级别上完成范围有限的任务
++
++数据不充分、不足够
++
++用户技术技能不充分、不足够
++
++缺乏服务同理心和情商
++
++面对复杂环境的有限适用性
++)))|(((
++在实施自助前，评估用户技能和可用的支持操作范围
++
++使用用户熟悉的渠道和界面
++
++确保高质量的历史数据和知识支持
++
++当使用机器学习时，确保数据和算法的高质量
++
++提供人工备份支持选项
++
++改进信息质量和导航工具
++
++确保尽可能容易获得自助工具和行动
++)))
++
  表2.4 渠道示例及其挑战
@@ -275,9
          +275,8 @@
  服务台实践的关键指标映射到其PSFs上。这些PSFs可以用作价值流情景下的KPIs，评估实践对这些价值流效能和效率的贡献。表2.5给出了一些关键指标的示例。
--(% style="width:721px" %)
--|(% style="width:258px" %)实践成功因素|(% style="width:460px" %)指标示例
--|(% style="width:258px" %)在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(% style="width:460px" %)(((
++|实践成功因素|指标示例
++|在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(((
  通过服务台渠道接收的信息的质量，根据商定的信息质量标准衡量
  服务台沟通渠道和界面的便利性，根据商定的便利性标准衡量
@@ -284,7
          +284,7 @@
  沟通关键利益相关者对信息质量和服务台沟通渠道的便利性的满意度
  )))
--|(% style="width:258px" %)实现用户沟通与价值流的有效整合|(% style="width:460px" %)(((
++|实现用户沟通与价值流的有效整合|(((
  与价值流的要求相比，通过服务台渠道接收到的信息的质量
  关键利益相关者对通过服务台渠道传达信息的的满意度
@@ -334,19
          +334,18 @@
  服务台活动分为三个流程：
--* 用户查询处理
--* 与用户沟通
--* 服务台优化
++1. 用户查询处理
++1. 与用户沟通
++1. 服务台优化
  === 3.2.1 用户查询处理 ===
  该流程确保对用户查询的捕获、验证和分类，以便进一步处理。它包括表3.1中列出的活动，并将输入转化为输出。
--(% style="width:594px" %)
--|(% style="width:223px" %)**关键输入**|(% style="width:178px" %)**活动**|(% style="width:191px" %)**关键输出**
--|(% style="width:223px" %)用户查询|(% style="width:178px" %)确认并记录用户的查询|(% style="width:191px" %)记录并分类用户的查询
--|(% style="width:223px" %)服务管理记录，例如，事件记录、变更记录、问题记录等|(% style="width:178px" %)用户查询的验证|(% style="width:191px" %)开始处理已分类的用户查询
--|(% style="width:223px" %)服务配置信息、IT资产信息以及其它相关信息|(% style="width:178px" %)对用户查询进行初步处理并启动适当的活动|(% style="width:191px" %)
++|**关键输入**|**活动**|**关键输出**
++|用户查询|确认并记录用户的查询|记录并分类用户的查询
++|服务管理记录，例如，事件记录、变更记录、问题记录等|用户查询的验证|开始处理已分类的用户查询
++|服务配置信息、IT资产信息以及其它相关信息|对用户查询进行初步处理并启动适当的活动|
  表3.1 用户查询处理流程的输入、活动和输出
@@ -361,10
          +361,68 @@
  表3.2将用户查询处理过程中每个人工交互和自动化活动进行比较。
--[[image:1642235551354-545.png]]
++|**活动**|**与服务台团队的人工交互**|**自动化自服务**
++|确认并记录用户查询|(((
++当用户出于任何原因访问服务提供者时，期望得到快速的人工响应。
--[[image:1642235569989-774.png]]
++尽管有越来越多的替代和更有效的方法帮助用户，传统的电话支持、电子邮件和走访习惯不太可能消失。
++在纯技术或B2B服务交付环境中，人工交互也能使人产生同理心和安慰。
++
++除了自动化支持之外，任何抵达服务台客服的查询都应以礼貌和标准的方式满足，这样用户就可以感受到一定质量级别的服务，表明其查询受到服务提供者的欢迎。
++
++每个交互都必须记录下来（例如，在查询日志或用户查询管理和工作流工具中唯一标识）。
++
++需要设计激励机制鼓励服务台客服记录问询信息。保存的记录是服务质量的宝贵数据来源，而自动化是是实现这一点的关键。
++)))|(((
++在用户需要人工响应前，可在预处理阶段响应查询，目的是快速解决问题 。这些通常称为自服务工具。
++
++例如，当用户呼叫服务台电话号码时，可能会有一个预先录制的问候语，这是称为IVR（交互式语音应答）的自动化系统的一部分。IVR的几个更广泛的功能可以帮助呼叫者：
++
++* 提供用户呼叫原因的分类选项。这既可以自动化查询分类，又可以向调用者建议查询已知解决方案的路径
++* 发布重要通知，关于正在进行的服务暂停或即将发生的影响用户的变更
++* 提供自动化参考服务
++* 提供语音邮件功能
++* 确认来电者身份
++)))
++|验证用户查询|(((
++服务台客服可以在记录查询时执行查询验证。不同的检查适用于某些类型的查询：
++
++* 用户是否是他们声称的那个人
++* 用户及其组织是否有资格使用指定的服务。这在提供商业服务时尤其重要，因为商业服务需要收费，且容易出现欺诈
++* 呼叫的原因是否与相关服务有关；例如，是否在服务提供者的职责范围内?
++* 在处理查询过程中是否需要传达任何受保护的信息，如果需要，是否需要进行额外的呼叫者身份检查
++
++虽然数据源（如服务目录或IAM）支持这些检查，但服务台客服负责验证查询。
++)))|(((
++当使用自服务工具自动处理用户与服务提供者间的首次联系时，查询验证的某些方面将实现自动化。
++
++自动验证可以内置到用户旅程中，进行增强和定制化，并限制用户体验的可变性。
++
++例如，若用户在自服务门户中通过了授权和身份验证检查，集成的工具集可以根据服务目录匹配其记录，并根据资格、角色、地理位置、可用库存等向其提供适用的服务产品和功能。
++)))
++|对用户查询进行出初步处理并启动适当的活动|(((
++初步处理通常意味着根据对象的特征、紧急程度和处理它们可能带来的收益，对呼入队列进行排序。服务提供者对用户查询初步处理还意味着对查询进行归类，并可以对已知的查询类型使用预定义的活动序列。
++
++对一些基本的问询初步处理可以使服务台坐席在与用户的首次对话过程中就解决掉问询问题。服务台需要谨慎地平衡其处理问询和进行技术技巧沟通的能力，对于时间密集型任务更是如此。
++
++然而在通常情况下，初步处理的结果涉及到启动一个特定的价值流。
++
++因此，服务台实践需要与服务提供的其他实践紧密结合。这些实践将为服务台实践提供有关初步处理特性及其相对重要性的指导。参考//ITIL驱动利益相关者价值//，表8.4（译注：此处为笔误）给出了一个初步处理标准的示例映射，以及满足标准时触发的相关实践。
++
++最后，即使查询不需要进一步操作（例如“错误号码”的呼叫），服务台客服也必须确保在查询记录中捕获了足够的关于交互的信息，这些信息至少包括时间、持续时长和内容。
++)))|(((
++用户查询处理的自动化确保交互的公正记录。对于预估用户支持的总体需求或计算未解决呼叫的比率等基本的改进和优化活动，也是非常有用的。
++
++基于前面步骤中收集的数据，自动查询分类可以减少人工工作和在初步处理和路由查询上所花费的时间。
++
++使用自动化后，一些查询类型可在无人工交互的情况下解决（例如，分析查询的情景并向用户建议自助指南或诊断步骤），或者使用最少的人工交互解决。
++
++后一种方法的一个例子是将新应用的服务的所有查询直接路由到新服务早期支持团队。关于该服务的任何查询都将绕过服务台，直接发送到相应的团队。这确保用户的快速响应体验，并减轻了服务台团队的压力。它也相对容易实施解决方案和消除问题。
++
++可以引入更复杂的规则，根据查询的参数将查询路由到特定的解决团队。重要的是要平衡问询表单的复杂性和自动化用户界面的简单性。界面设计应该鼓励用户沟通他们的问询，以便服务提供者可捕获最大可能的需求。
++)))
++
  表3.2自动化与人工交互比较
@@ -372,9
          +372,8 @@
  这个过程确保通过适当的渠道将各种类型的信息传达给用户。它包括表3.3所列的活动，并将输入转换成输出。
--(% style="width:533px" %)
--|(% style="width:199px" %)**关键输入**|(% style="width:219px" %)**活动**|(% style="width:113px" %)**关键输出**
--|(% style="width:199px" %)(((
++|**关键输入**|**活动**|**关键输出**
++|(((
  用户沟通需求
  沟通的信息
@@ -384,7
          +384,7 @@
  服务管理记录，例如事件记录、变更记录、问题记录等
  服务配置信息、IT资产信息及其他相关信息
--)))|(% style="width:219px" %)(((
++)))|(((
  识别并确认目标受众
  识别并确认沟通渠道
@@ -394,7
          +394,7 @@
  信息发送
  收集和处理接受者的确认和反馈
--)))|(% style="width:113px" %)(((
++)))|(((
  沟通消息
  沟通报告
@@ -415,12
          +415,65 @@
  表3.4概述了与先前已登记的查询相关的沟通过程活动。
--[[image:1642235731662-569.png]]
++|**活动**|**针对之前登记的查询进行个性化沟通**|**公众沟通**
++|识别并确认目标受众|(((
++无论目标受众数量多少，服务台的每次对外交互都必须符合服务提供者所维护的一致的质量标准。
--[[image:1642235775142-492.png]]
++问询记录的状态更新也是一种需要仔细设计的对外沟通。根据问询的性质，可以有利益相关者或服务提供者的员工等多个消息接收者。大多数情况下，用户查询管理和工作流工具将跟踪每个用户查询的接收者，服务台实践将提供此项功能设计的输入。
++)))|(((
++这可以是重大事件解决通知、与变更相关的即将到来的服务中断、年度用户满意度调查等。
--[[image:1642235790279-634.png]]
++无论公众沟通的需求来自于哪种实践或过程，服务台实践保证沟通的标准，对传播的内容进行质量控制，并代表服务提供者组织收集反馈。
++服务提供者应该定义一个服务台请求公众沟通的流程。这种沟通的目标受众可以由请求者提出，但应由服务台验证。这是因为服务台最了解用户是谁，用户喜欢何种沟通风格等等。
++
++集中式用户沟通的另一个重要的文化挑战是确保服务台团队受到重视。
++)))
++|识别并确认沟通渠道|(((
++在全渠道范例中，用户应能决定服务提供者应通过哪个渠道交付信息。
++
++服务提供者可决定在SLA中包含的用户沟通需求，这时服务台客服应选择适当的渠道。
++)))|(((
++定义目标受众后，服务台必须为该受众和消息类型定义适当的沟通渠道。
++
++一般性通知等沟通可以在自助服务门户或社交媒体上以醒目形式发布。而选定的用户计算机的IT资产核查等其他沟通可能需要保证交付和反馈闭环。
++
++理想情况下，沟通渠道应通过SLA协商并确定。若非如此，服务台团队应视为最适合的沟通渠道中了解用户受众的专家。
++
++这不包括为客户和赞助商服务的营销沟通。因为这些受众和消息超出了服务台实践的目的范围。然而，服务台团队可能会参与传递此类消息。
++)))
++|信息打包|(((
++在自动化服务交付环境中，通常用一组模板生成问询记录生命周期中所有的通知类型。
++
++用户查询管理和工作流工具通常与配置和资产管理工具以及其他数据源集成在一起。应该定期验证标准问询通知模板，这样对链接数据源的变更就不会产生空白项，避免消息显得不专业。商业和大规模服务提供商尤其应该避免使用过于复杂和伪个性化的模板。
++
++问询记录生命周期更新之外的自定义人工沟通也应以公司模板的形式呈现，并清晰地说明沟通的目的、相关的查询记录和内容。一些服务提供商将企业沟通培训纳入服务台团队发展计划中；其他提供商则由服务台经理或其他管理部门批准服务台客服发起对外沟通的策略。
++)))|(((
++服务台应审查和编纂任何请求沟通的实际消息，以便更有可能以用户最了解的术语和样式沟通。
++
++例如，从用户的角度看，“WEBAPPS_SRV01因为安装核心补丁将在周六晚上暂停服务”和“这周末我们将优化系统。预计网上银行将从周六下午6点到周日下午12点无法提供服务。我们的新手机银行应用程序将照常运行。谢谢你的耐心!”相比，前者远无法让人满意。
++)))
++|信息发送|(((
++通常沟通信息是自动发出的，电子邮件最常用于用户沟通。然而，在一些规范的服务交付环境中，书面沟通或个人访问更为合适。
++
++根据用户沟通环境的不同，必须向服务台人员提供明确的指导，说明哪种交付格式适合哪种类型的用户和沟通。例如，终止与公用事业提供商服务契约的查询，需要在处理正常的问询记录的同时，通过挂号信服务的方式向客户发送最终帐户余额信息。
++)))|(((
++服务台工作人员还可以对用户的文化有第一手了解，这将使他们能够选择适当的沟通和交付方式。
++
++对于某些类型的通信可以有一个最终的批准程序，通常服务台经理或具有同等权力的角色可以以服务提供者服务台的名义发出这类消息。
++)))
++|收集和处理接收者确认和反馈|(((
++“请不要回复此邮件”可以说是一种不完美的做法，但仍广泛采用。即使消息的内容与他们有关，这一行文字也不鼓励大多数用户回复该消息。
++
++欢迎来自用户的反馈总是明智的。在全渠道范例中，用户应该能够选择任何合法及合理的渠道，尽可能方便地访问服务提供者。
++
++收集和处理反馈还伴随着对某些类型的商业沟通的法定要求，要求来自服务用户的响应以进行后续查询，例如接收者的确认或报价的接受。在这些情况下，服务台客户需要有开放式任务跟踪未回复的请求，并通过不同的沟通渠道联系用户。应该控制不成功尝试的阈值，以避免激怒用户。
++)))|(((
++每个公众沟通需要有一个明确的参考反馈渠道，用户应该使用这一渠道。这个渠道可能会返回到服务台，与特定公众沟通相关的查询必须被标识、记录和处理（可能由该沟通的发起者进行处理）。
++
++未能处理的公众沟通反馈可能会导致信誉的急剧下降和用户对来自服务提供商的公众沟通的关注。
++)))
++
  表3.4关于先前已登记的查询的沟通过程活动
@@ -428,9
          +428,8 @@
  这一流程确保从管理用户沟通中吸取经验教训，并不断改进这一实践。它包括表3.5中列出的活动，并将输入转化为输出。
--(% style="width:427px" %)
--|(% style="width:156px" %)**关键输入**|(% style="width:132px" %)**活动**|(% style="width:137px" %)**关键输出**
--|(% style="width:156px" %)(((
++|**关键输入**|**活动**|**关键输出**
++|(((
  服务台绩效报告
  满意度调查结果
@@ -438,13
          +438,13 @@
  技术机遇
  事件和服务请求报告
--)))|(% style="width:132px" %)(((
++)))|(((
  服务台回顾
  服务台优化启动
  服务台优化沟通
--)))|(% style="width:137px" %)服务台优化沟通
++)))|服务台优化沟通
  表3.5 服务台优化流程的输入、活动和输出
@@ -459,11
          +459,10 @@
  表3.6概述了服务台优化过程的活动。
--(% style="width:510px" %)
--|(% style="width:128px" %)**活动**|(% style="width:379px" %)**描述**
--|(% style="width:128px" %)服务台回顾|(% style="width:379px" %)服务台团队经理与其他相关干系人一起回顾各种输入。确定改进这一实践的机会。
--|(% style="width:128px" %)服务台优化启动|(% style="width:379px" %)服务台团队经理记录改进计划。计划将通过引入持续改进实践或启动变更请求进行处理。
--|(% style="width:128px" %)服务台优化沟通|(% style="width:379px" %)如果服务台成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由服务台经理通过沟通过程完成。
++|**活动**|**描述**
++|服务台回顾|服务台团队经理与其他相关干系人一起回顾各种输入。确定改进这一实践的机会。
++|服务台优化启动|服务台团队经理记录改进计划。计划将通过引入持续改进实践或启动变更请求进行处理。
++|服务台优化沟通|如果服务台成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由服务台经理通过沟通过程完成。
  表3.6 服务台优化过程活动
@@ -499,11
          +499,33 @@
  表4.2列出了服务台实践中可能涉及的其他角色示例，以及相关的能力类型和特定技能。
--[[image:1642235912449-908.png]]
++|**活动**|**负责角色**|**能力类型**|**特定技能**
++|(% colspan="4" %)用户问询处理
++|确认和记录用户问询|服务台客服|CA|沟通、书写、业务、服务意识以及某一层次的技术技能
++|验证用户问询|服务台客服|CM|理解用户验证的方法
++|初步处理用户问询并启动合适的活动|服务台客服|MATC|理解需求并基于过程规则分类
++|(% colspan="4" %)与用户沟通
++|识别并确认目标受众|服务台客服|CM|理解消息和沟通需求
++|识别并确认沟通渠道|服务台客服|CTM|理解用户沟通需求
++|信息打包|服务台客服|CMT|(((
++沟通和写作技能
--[[image:1642235925791-414.png]]
++渠道技术专长
++)))
++|信息发送|服务台经理|AMT|渠道技术专长
++|收集和处理接收者确认和反馈|(((
++服务台客服
++服务台经理
++)))|CMA|(((
++反馈工具
++技术专长
++)))
++|(% colspan="4" %)服务台优化
++|服务台回顾|服务台经理|LM|决策制定，监管其他活动，以及评价产出
++|启动服务台优化|服务台经理|MA|与持续改进过程相关的知识
++|服务台优化沟通|服务台经理|CT|沟通技巧，运用可用沟通工具的技术技巧
  == 4.2 组织架构和团队 ==
@@ -531,13
          +531,13 @@
  这样做的优点是：
--* 团队内部和服务提供商组织之间快速高效的沟通。服务台团队应尽可能物理上与其他服务提供商团队在一起，以便能够快速了解信息和变化。
--* 易于人与人之间的接触。服务台团队创建信任，并将服务提供者呈现为可访问资源。
++1. 团队内部和服务提供商组织之间快速高效的沟通。服务台团队应尽可能物理上与其他服务提供商团队在一起，以便能够快速了解信息和变化。
++1. 易于人与人之间的接触。服务台团队创建信任，并将服务提供者呈现为可访问资源。
  这方面的挑战是：
--* 集中式联合团队倾向于较少使用查询自动化工具。工作是透明的，人们不理解为什么查询需要被记录。同样，流程和指南也是口头传达和更新的。这可能导致缺乏对用户沟通的控制。
--* 物理上的邻近会导致对特定个人，而非特定角色的依赖。这种风险应该通过流程控制减轻，但个人关系可能会形成“走后门式”的支持，并且在这些人离开后对服务提供造成干扰。
++1. 集中式联合团队倾向于较少使用查询自动化工具。工作是透明的，人们不理解为什么查询需要被记录。同样，流程和指南也是口头传达和更新的。这可能导致缺乏对用户沟通的控制。
++1. 物理上的邻近会导致对特定个人，而非特定角色的依赖。这种风险应该通过流程控制减轻，但个人关系可能会形成“走后门式”的支持，并且在这些人离开后对服务提供造成干扰。
  **4.2.1.2 分布式服务台团队**
@@ -545,13
          +545,13 @@
  这样做的优点是：
--* 能够随着客户组织或客户数量的增长而扩展服务提供者的存在，保证了存在和沟通标准。服务行为是任何服务提供的重要组成部分；确保服务行为可见很重要，可以保持积极和合作的声誉。
--* 对用户查询的快速反应。分布式服务台组织对用户最有益之处在于用户在所有地点的服务查询都能得到一致和快速的响应。
++1. 能够随着客户组织或客户数量的增长而扩展服务提供者的存在，保证了存在和沟通标准。服务行为是任何服务提供的重要组成部分；确保服务行为可见很重要，可以保持积极和合作的声誉。
++1. 对用户查询的快速反应。分布式服务台组织对用户最有益之处在于用户在所有地点的服务查询都能得到一致和快速的响应。
  这方面的挑战是：
--* 协调和自动化。由于团队是分布式的，因此需要通过一致的协作环境理解当前组织的事态。所有团队都需要类似的、一致的培训和控制。一些服务提供商采用单一的分布式团队名册管理需求波动并减轻职责，以适应工作场所的通勤时间（例如，所有团队成员都在同一个都市圈内）。
--* 不管如何自动协调，分布式服务台导致重复的专业知识和管理开销。一般来说，服务台工作人员处理的非沟通任务越多(处理模式化事件、IMAC请求或为用户提供支持)，团队之间的重复工作就会越多。服务提供者应该严格考查分布式服务台的价值（例如，面对面的交互），应对冗余安排造成的协调问题和共享成本。
++1. 协调和自动化。由于团队是分布式的，因此需要通过一致的协作环境理解当前组织的事态。所有团队都需要类似的、一致的培训和控制。一些服务提供商采用单一的分布式团队名册管理需求波动并减轻职责，以适应工作场所的通勤时间（例如，所有团队成员都在同一个都市圈内）。
++1. 不管如何自动协调，分布式服务台导致重复的专业知识和管理开销。一般来说，服务台工作人员处理的非沟通任务越多(处理模式化事件、IMAC请求或为用户提供支持)，团队之间的重复工作就会越多。服务提供者应该严格考查分布式服务台的价值（例如，面对面的交互），应对冗余安排造成的协调问题和共享成本。
  **4.2.1.3 虚拟服务台团队**
@@ -563,12
          +563,12 @@
  优点是：
--* 团队压力较小（当信息技术服务不完善时，压力可能会很大）。技术屏障界限有助于创造节奏，减少双方不适当的沟通。
--* 降低每次问询的成本。除了使用电话支持，其他大多数沟通渠道都是不连续的。每一方向另一方发送信息都有一个时间差。此外，服务台人员可以在电子邮件或在线聊天问询之间切换，但是电话对话需要服务台人员持续投入注意力。
++1. 团队压力较小（当信息技术服务不完善时，压力可能会很大）。技术屏障界限有助于创造节奏，减少双方不适当的沟通。
++1. 降低每次问询的成本。除了使用电话支持，其他大多数沟通渠道都是不连续的。每一方向另一方发送信息都有一个时间差。此外，服务台人员可以在电子邮件或在线聊天问询之间切换，但是电话对话需要服务台人员持续投入注意力。
  挑战是：
--* 服务提供者必须承诺在工具的设计和实现方面进行广泛和持续的投资，支持各种沟通渠道和记录管理。自动化工具（在5.2节中描述）可确保客户能够快速、方便地提交查询并轻松地找到并与相关的服务提供者沟通。应向寻求真人互动的用户提供各种便利且非常容易获取的工具，如在线聊天、电子邮件或电话。服务提供商必须仔细分析每种技术的价值和成本。
++1. 服务提供者必须承诺在工具的设计和实现方面进行广泛和持续的投资，支持各种沟通渠道和记录管理。自动化工具（在5.2节中描述）可确保客户能够快速、方便地提交查询并轻松地找到并与相关的服务提供者沟通。应向寻求真人互动的用户提供各种便利且非常容易获取的工具，如在线聊天、电子邮件或电话。服务提供商必须仔细分析每种技术的价值和成本。
  **4.2.1.4 混合式服务台组织**
@@ -586,11
          +586,11 @@
  可以从影响工作量关键因素的简单思维图开始分析。这些因素包括：
--* 服务台组织类型
--* 排队理论或厄兰变量（Erlang Variables, 查询呼入率、可接受的等待时间、掉线率、队列长度等）
--* 服务台团队因其他实践（典型事件，IMAC请求，调查等）而产生的额外工作量
--* 用户和客户服务水平期望
--* 预期员工流失率
++1. 服务台组织类型
++1. 排队理论或厄兰变量（Erlang Variables, 查询呼入率、可接受的等待时间、掉线率、队列长度等）
++1. 服务台团队因其他实践（典型事件，IMAC请求，调查等）而产生的额外工作量
++1. 用户和客户服务水平期望
++1. 预期员工流失率
  **4.2.2.1 扁平vs垂直**
@@ -640,13
          +640,12 @@
  服务台实践的有效性取决于所用信息的质量。这些信息包括但不限于以下信息：
--* 用户
--* 服务，包括服务目录、服务请求目录，以及服务级别
--* 知识管理系统
--* 计划和执行的变更、变更时间表以及变更的可能影响
--* 合作伙伴和供应商，包括关于其提供服务的信息
--* 规范服务提供的策略和要求
--
++1. 用户
++1. 服务，包括服务目录、服务请求目录，以及服务级别
++1. 知识管理系统
++1. 计划和执行的变更、变更时间表以及变更的可能影响
++1. 合作伙伴和供应商，包括关于其提供服务的信息
++1. 规范服务提供的策略和要求
 . 利益相关方对实践的满意度
  信息可有多种形式。实践的关键输入和输出在第3节中列出。
@@ -658,10
          +658,35 @@
  在许多情况下，服务台的工作可从自动化中获得很大好处。在可行且有效的情况下，它可能涉及表5.1中概述的解决方案。
--[[image:1642236032706-313.png]]
++|**过程活动**|**自动化方式**|**关键功能**|**对实践有效性的影响**
++|(% colspan="4" %)人工处理用户查询
++|收集初始需求|用户查询管理和工作流工具、协作工具|事件的早期发现和关联，启动事件管理，启动服务请求管理和其他服务记录类型|高
++|验证用户身份|用户查询管理和工作流工具|辅助多因素用户识别|高
++|获取授权|用户查询管理和工作流工具|获得授权|高
++|需求分类以进行后续处理|用户查询管理和工作流工具、协作工具、配置管理工工具、基于机器学习的分类引擎|快速和准确的分类并分配用户查询|非常高，尤其当查询量大时
++|(% colspan="4" %)用户沟通
++|识别并确认目标受众|用户查询管理和工作流工具|检测位置和语言首选项，选择解决团队路由|高
++|识别并确认沟通渠道|用户查询管理和工作流工具|检测适用于该类型沟通的常规沟通场景|中
++|信息打包|用户查询管理和工作流工具|(((
++信息格式化
--[[image:1642236047390-499.png]]
++固定响应模板管理
++)))|中
++|信息发送|用户查询管理和工作流工具、协作工具|沟通审批|中
++|收集和处理接收者确认和反馈|用户查询管理和工作流工具、协作工具|实时服务体验数据|高
++|(% colspan="4" %)服务台优化
++|服务台回顾|(((
++协作系统
++分析和报告系统
++)))|(((
++远程协作
++
++服务台数据分析
++)))|中到高，尤其是事件数多时
++|服务台优化启动|工单和工作流系统，待办项管理工具|优化的正式登记|低到中
++|服务台优化沟通|沟通工具、协作工具|与受影响团队沟通更新|中到高，尤其当组织较大、更新较多时
++
  表5.1服务台活动的自动化解决方案

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司