yITIL服务运营之服务台_总服务台人员工作规范

yITIL服务运营之服务台由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“总服务台人员工作规范”。

6.2 服务台

服务台是一个功能单元，由一定数量的专业的员工构成，通过电话、网络接口或自动报告基础架构事件等方式，负责处理各种各样的服务事件。服务台是组织IT部门重要的组成部分，应该为IT用户提供单一的联系点，通常使用特殊的软件工具来记录和管理事件，解决所有的故障和服务请求。

不应该低估有效的服务台的价值。表现良好的服务台通常能够补偿IT组织其他方面的缺失，表现糟糕的服务台（或没有服务台）会给一个有效的IT组织带来糟糕的印象。

所以，服务台拥有合适的员工是非常重要的，IT经理应该尽最大努力使服务台成为一个有吸引力的地方以留住员工。

服务台的性质、类型、大小和位置会因为业务类型、用户数量、地理、电话复杂度、服务范围和其他因素的不同而不同。

为了符合客户和业务要求，IT组织的高级经理应该决定所需服务台的性质（内部建立服务台还是外包给第三方）作为整体IT服务管理战略的一部分（见《服务战略》），还需要制定后续的计划来为服务台功能做准备和进行实施（或者实施一种新功能或者对现存功能做必要的修改--见《服务设计》和《服务转换》）。

6.2.1 服务台存在的理由和角色

今天，服务台的存在基本不需要理由，因为许多组织已经确信到目前为止这是处理一线IT支持最好的方式。唯一的问题是“替换方案是什么”，这使得服务台成为更令人信服的方案。如果需要更多的理由，应该考虑如下的效益：

 改进的客户服务、认知和满意度  通过单一联系点增加的可访问性

 客户或用户请求的更好质量和更快周转  改进的团队合作和沟通

 对服务规定的重点关注和主动处理  减少的负面业务影响

 更好管理的基础架构和控制

 改进的IT支持资源利用和提高的业务人员生产力  为决策支持提供更有意义的管理信息

 实际上，服务台为IT服务管理员工提供入门级的职位。服务台对那些希望从事服务管理职业的员工提供了基础。然而，这对不懂业务或技术的员工也是一种挑战。呼叫服务台的用户希望能够和解决他们需要的人对话，服务台分析员不应该在一年内因为过度压力而精疲力尽。应该谨慎地选择具有熟练技巧的员工，并且他们对业务有很好的理解并得到足够的培训。这样，可以组织由于一线员工知识的不足而导致的支持水平的降低。6.2.2 服务台目标

服务台的主要目标是尽快地为用户恢复“正常服务”，这里指的是最广泛的含义。这可能涉及修复一个技术错误，还可能是满足一个服务请求或为咨询提供答案----以至所有使用户满意地回到工作状态的服务。

具体职责包括：

 记录所有相关的故障/服务请求的细节、进行分类和分配优先级  提供一线调查和诊断

 解决他们能够解决的故障/服务请求

 升级在协议时间内他们不能够解决的故障/服务请求  保持用户了解处理进度

 关闭所有解决的故障、请求和其他的呼叫  执行用户/客户满意度调查

 与用户沟通--保持用户了解故障的处理进度、通知他们可能的变更或中断等等  在配置管理的指示和批准下更新配置管理系统

注意：详见章节4.2 故障管理和章节4.3 请求履行所描述的活动。

6.2.3 服务台组织架构

服务台架构有多种方式，会根据组织的不同而不同。这些方案如下文所述，但是在现实中一个组织可能需要实施这些方案的组合来完全地符合业务需要。

6.2.3.1 本地服务台

这种方式的服务台位于其服务的用户区或者离其服务的用户区很近。这通常有助于沟通并且多是清晰可见的，一些用户喜欢这种方式，但是资源利用可能是低效率的和昂贵的，因为员工忙于处理故障，当呼叫数量和到达率不适应这种方式的时候。

但是，维护一个本地服务台可能是出于一些原因，即使是呼叫量不适应这种方式的时候。原因包括：

 语言、文化或政治差异  不同的时区  专业的用户组

 需要专业知识的定制化或专业服务的存在  VIP或用户的临界状态

6.2.3.2 集中式服务台

可以通过整合多个服务台到某一单一地点来减少服务台的数量（或者只是更少数量的服务台），即通过把员工组织到一个或多个集中式的服务台架构中。更少的员工来处理更高的呼叫量，这通常是高效的和成本效益的，还可以使员工熟悉经常发生的事件来达到更高的技术水平。维持某种形式的“本地服务台”来处理实际的支持需求仍然是必要的，但是可以通过集中式服务台进行控制和部署。

6.2.3.3 虚拟式服务台

通过技术的使用，特别是网络和公司支持工具的使用，可以让人产生一种单一的、集中式服务台的印象，而实际上，员工可能分布在不同数量或类型的地理的或组织架构的位置。可能牵涉到在家办公、二线支持小组、离岸、外包或它们的组合来包含用户的需求。需要注意的是，需要在这些情况中设置保障措施以保证服务质量和文化认同的一致性。

6.2.3.4 7*24服务

一些全球或跨国组织可能希望组合两个或多个不同地理位置的服务台来提供24小时的全天候服务。例如，亚太区服务台在他们标准上班时间处理呼叫，下班时把所有未解决的故障移交给欧洲区服务台，然后下班时移交给美国区服务台，最后交回给亚太区服务台以完成该循环。

这样可以在低成本和不轮班的情况下实现24小时的服务。当然，需要有流程、工具、共享的数据库信息、文化的保障措施来保证这种方式的持续进行，并且还需要得到很好控制的升级和移交流程。

6.2.3.5 服务台专家组

对于一些组织来说，在整个服务台架构中建立专家组是有益的，这样特殊IT服务相关的故障可以直接移交给专家组（通常通过电话选项或基于网络的接口）。通过专业培训，这些故障可以更快地得到解决。

一个电话选项的例子是，“如果您的呼叫是关于X服务，请按1，否则请移交服务台”。不要把这些选项设置得过于复杂，只需要为极少数量的关键服务提供专家组，在某服务呼叫率需要一个独立专家组的时候。

6.2.3.6 环境

应该谨慎选择服务台的坐落环境。如果可能，应该提供以下的功能：

 整体设施位于有足够的自然光和空间的地点----在必要的时候有足够的工位、仓储空间和房间来迁移

 有足够的声音控制的安静的环境，以便电话交谈不被另一个所打扰

 愉快的周边环境和舒适的家具（furniture）来减轻情绪（服务台是一项压力非常巨大的工作，所以每一个改进都会有助于减轻压力）

 分离的休息室和就近的身心爽快的区域以便员工可以短暂的休息而不致于离开太长时间

虚构：一家公司发现在服务台和其他支持团队之间存在“他们和我们”的文化。三线支持团队通常认为自己比服务台更优秀。把服务台置于孤立的房间内只能强化这种文化意识。这公司发现把服务台置于中间的开放式的办公室有益于更紧密的工作和有助于消除这些障碍。6.2.3.7 建立单一联系点

不论这些方案如何组合来构成组织整体的服务台架构，单个用户在需要帮助的时候应该知道联系谁。需要提供和公布单一的电话号码（如果选择分离的服务台模式则需要为每一组提供单一的号码），还需要公布单一的电子邮件联系方式和服务台联系网页。

可以采用一系列的方法来公布服务台电话号码和电子邮件地址，当用户需要它们的时候，可以很容易的找到。方法包括：

 把服务台联系方式印到硬件配置项标签上，贴到用户可能需要打电话的组件上  在电话上提示服务台联系方式  对于台式机和笔记本，使用定制化的带有服务台联系方式的背景和桌面，还要在某一角附带呼叫服务台时所需要系统信息（如IP地址、操作系统内部版本号等等）

 在钢笔、铅笔、杯子、鼠标垫等上面印上服务台联系方式  在服务台内网和外网页面的显著地方展示服务台联系方式  在名片或满意度调查卡片等上面印上服务台联系方式  与客户交互时重复联系方式

 把联系方式置于提示板或用户经常访问的地点，如入口、食堂、茶点区（refreshment area）等等

6.2.4 服务台员工

本章节讨论的是建立恰当员工模式和水平的问题。典型服务台角色和责任的细节见段落6.6.1，包括服务台经理、监督人、分析人员，在一些组织中，还存在提供一线支持的业务用户（超级用户）。

6.2.4.1 员工水平

一个组织必须保证恰当的服务台员工数量在任何时候是可用的以满足业务对服务台的需求。呼叫率是极不稳定的，通常在一天中也会出现呼叫率从很高到很低再到很高的情况。规划新的服务台的组织应该预测呼叫到达率和响应的人员。必须对当前安排下的呼叫到达率进行统计分析，并密切地监控和必要地调整。

许多组织发现呼叫高峰期开始于上班的初始阶段然后迅速回落，可能在下午的开始阶段会有另一次高峰期----很明显这会根据组织业务的不同而不同，却是一个经常发生的规律。在这种情况下，需要利用兼职员工、在家办公人员、二线支持员工或第三方来处理高峰期的呼叫。

决定员工水平时需要考虑如下因素：

 客户服务预期

 业务要求，例如预算、呼叫响应时间等等

 IT基础架构和服务目录的大小、相对年限、设计和复杂度----例如故障的数量和类型、定制软件和标准软件的部署范围等等  需要支持的客户和用户的数量，相关的因素如：

 讲不同语言的客户和用户的数量  技能水平

 故障和服务请求类型（可能还有请求变更类型）：

 呼叫类型所需的持续时间（例如：检查咨询、特殊程序咨询、硬件等） 所需的内部或外部专家

 故障和服务请求的数量和类型  所需的支持时间，基于：

 小时数

 小时之外（out-of-hours）支持要求  时区

 所需支持的地点（特别是服务台员工会进行桌面支持的地点） 地点之间的往返时间

 请求的工作量模式（例如，每天，月结等等） 服务级别目标（响应水平等等） 所需的响应类型：

 电话

 电子邮件、传真、语音邮件、视频  到点支持（physical attendance） 在线访问/控制  所需的培训级别

 可用的支持技术（电话系统、远程支持工具等等） 员工当前技术水平  使用的流程和步骤

在员工水平方面做出决定都需要慎重考虑这些因素，并在文档中有所反映。服务越好，业务用得就越多。

有许多可用工具来帮助服务台确定合适的员工水平。这些工具依赖于组织的知识，如呼叫量、呼叫模式、服务、用户等等。

6.2.4.2 技术水平

一个组织必须确定服务台员工的技能（skill）水平和范围，这样可以保证在需要的时候可以提供这些技能。技能方案的范围是必要的，从“线录音系统”服务开始，员工只需要基本的技术，到技术型的的服务台员工，即技术非常熟练的员工。在第一种情况下，会有很高的接起率但是很低的解决率，第二种情况则相反。

所需技能水平的决定通常由目标解决时间（业务所同意并写入服务级别目标）、所支持的系统复杂度、业务准备付出的代价等等所驱动。

在响应时间和解决成本之间有很强的关联。通常说来，解决时间越短，所需成本越高，因为需要更多的资源。

可能存在一些例子，业务需要的原因，组织内存在高技能水平的服务台员工是必要的，但是最优的和最能体现成本收益的是服务台拥有一线支持，通过快速和有效地升级给更高技能水平的二线和三线支持团队，这样技能员工可以更加集中和有效使用（详见章节4.2 故障管理）。可以为一线员工提供基础知识、诊断技巧、集成支持工具（包含配置管理系统）、不间断的培训等来提高其技能水平，从而使一线员工的解决率逐渐地得到提高。

这也可以在服务台设置二线支持来达到，即建立两层的架构。优势是，在呼叫高峰期，二线支持可以帮助接听呼叫，还可以训练初级员工，通常这能够增加呼叫解决率。但是，二线支持还有服务台之外的职责，这导致管理花名册和重复的二线支持的岗位。另外，解决例行电话可以为更好地为做个更有经验的员工有所贡献。一个潜在的缺点是服务台越来越善于解决呼叫请求，而二线支持则关注于解决问题的根本原因。

服务台员工所需的技能水平另一个考虑因素是支持服务的定制化或专业化水平。标准服务需要较少的专业知识以提供高质量的支持。越专业的服务，一线支持越需要专业的知识。

需要注意的是，可以通过有效的问题管理即减少简单的和重复性的故障来减少一线支持解决率。在这种情况下，虽然解决率显示下降，但是整体的服务质量却通过完全解决了许多故障而得到提高。如果服务台员工是按照一线支持解决率来获得奖金，那么除非对奖金进行回顾（review），否则会对员工士气和流程效果产生灾难性的影响。

降低解决时间或提高解决比率不应该是偶然做出的，而应该作为持续性服务改进计划的一部分（详见《持续性服务改进》）。

一旦确定所需的技能水平，需要有不间断的计划来保证服务台员工拥有必要的技能来进行操作，并在恰当的时候履行职责，从而维护一致性。

这涉及不间断的培训和认知，包括：

 人际交往技巧：电话技巧、沟通技巧、积极倾听、客户关怀培训等  业务认知：对组织业务、驱动、架构、优先级等等的专业知识。 对所有的组织关键IT服务的认知

 技术认知（更深的技术培训以达到恰当的水平，依赖于所要求的解决率） 依赖于所提供的支持水平，一些诊断技巧（例如，Kepner-Tregoe思维法） 支持工具和技术

 新系统和技术的培训和辅导，优先于其简介

 流程和步骤（特别是故障管理、变更管理和配置管理，但是需要对所有的IT服务管理流程和步骤有一个总揽）

 打字技巧（Typing skills）来保证快速和准确地定位故障和服务请求的细节 为了有效地达到技能水平，需要定期地评估并维护培训记录。

需要维护员工轮岗和调度规划以保证在所有的关键运营阶段员工经验和恰当的技能水平之间维持平衡。只有足够数量的值班员工是不够的，还需要有足够的技能水平。

6.2.4.3 培训

在服务台员工上岗前对其进行足够的培训是非常重要的。对所有的新员工应开展正式的适应课程（induction programme），范围依靠新员工的现有技能水平和经验的不同而不同，但是最好包括以上描述的所需技能。

如果必要，需要为新员工提供业务认知课程（busine awarene programme），从短期业务到关键业务领域。

服务台新员工开始上岗的时候，先是作为有经验的员工的“影子”----与他们坐在一起听电话，直到可以提供支持的时候由指导人员指导开始独立地接电话。指导人员开始的时候应该和新员工一起回顾每个电话内容以便吸取教训。回顾的频率也应该随着经验和自信的增加而逐步地减少，但是即使新员工可以独立地接听电话的时候，指导人员仍需要提供持续的支持。

应该对指导人员在“如何指导”方面进行培训。服务台经验和技术技能对指导人员来说并不是唯一要求。有效的知识传递技能和教导能力是同样重要的。

需要一项规划（programme）来保持服务台员工的知识是最新的----保持他们对新升职路径（developments）、服务、技术的意识。这些事件的时间是很关键的，才能不会对正常的职责产生影响。许多的服务台发现在员工需要较少呼叫处理的时候组织短暂的“辅导”是最好的方式。

注意：需要对服务台员工的专业发展进行投资。内部指导和影像二线、三线支持员工都是很好的开始，但是最佳服务台得益于员工开发的正式计划。

对专业发展的组织认同感向员工灌输了成就感和机遇感。这在服务台运营（如专业服务）方面会引发创新，并依次驱动各个支持层面的运营效率。它有助于培养当前的角色所用的技巧，还可以为新角色提供培训准备。在当前角色中开发核心竞争力是重要的，具有明细的职业规划和认可将来的要求和发展需要同样也是重要的。

6.2.4.4 留住员工

非常重要的是，IT经理认识到服务台及服务台员工的重要性并给予特别的关注。员工的流失是具有破坏性的并导致服务不能持续地进行，所以需要做出努力来使服务台成为有吸引力的工作地方。

这些努力包括角色识别和奖励、团队建设活动、员工轮岗制度（到其他项目、二线支持等等）。

服务台通常用于其他技术性角色或监督/管理角色的基石。如果是这样的，必须小心谨慎以保证恰当的继任计划能够进行，保证服务台不会在同一时间流失其所有的关键专家。同样的，良好的文档和岗位轮换培训可以降低这种风险。

6.2.4.5 超级用户

许多组织发现委派一定数量的“超级用户”在服务台和其他IT用户之间进行联络是很有用的。

需要对超级用户进行额外的培训以作为双向沟通的向导。可能会要求他们筛选用户请求和问题（在一些情况下可能是超级用户建立的请求和故障单）----这有助于阻止“故障风暴”，即影响很多用户的关键服务或组件失败的时候，触发的大量故障请求。

可以使用超级用户来关联从服务台到本地用户的信息，从而可以快速传播服务细节到所有用户。

需要注意的是，超级用户应该记录它们处理的所有呼叫，而不仅仅是传递到IT的呼叫。这意味着需要使用故障记录工具。这有助于衡量超级用户的活动并保证他们的职位没有滥用。此外，它还可以保证关于故障和服务质量的有价值的历史记录不会丢失。

超级用户还可能涉及到以下活动：

 对用户在其领域内进行培训

 为减少故障或满足简单的请求提供支持  参与新的发布和首次展示

超级用户没有必要为整个IT提供支持。在许多情况下，超级用户只为具体的应用、模块或业务单元提供支持。作为业务用户，超级用户通常具有关于关键业务流程如何运营和服务在实践中如何进行的深层次的知识。这些有用的知识需要与服务台分享，从而在将来提供更高质量的服务。

要注意的是，需要得到潜在超级用户的坚定承诺，特别是他们的管理方面，这样在选择和培训开始之前他们有时间和兴趣来实现他们的角色。

超级用户，作为业务和服务台的有价值的接口，必须给予其进行恰当的培训、职能和预期。如果他们的角色、责任和管理流程与用户没有清晰地沟通，超级用户可能就会被滥用。重要的是，超级用户不应该视为服务台的替代品或绕过服务台的一种方式。

6.2.5 服务台度量标准

应该建立度量标准以定期地评估服务台的绩效（performance）。重要的是评估健康度、成熟度、效率、效果和其他因素来提供服务台的运营。

服务台绩效的度量标准必须是实际的并且应谨慎选择。这些标准是易于可用的，并能表明绩效，但是，这也可能产生误导。例如，服务台接听的电话数量并不能作为绩效好或坏的指标，实际上可能完全是由服务台控制之外的事件引起的-----例如组织特别繁忙的时期或主要系统的新版本发布的时候。

服务台接听数量的增加表明某一段时间服务的可靠性减少，但是也显示了用户增加了对服务台的信心，服务台是成熟的，用户更加倾向于向服务台寻求帮助而不是独自解决。对于这种度量标准，为了达成可靠的结论，与先前服务台的进一步比较可以得到数量增加的真正原因，这是很有必要的。

所以需要更进一步的分析和更加详细的度量标准并进行一段时间的测验。包含通过电话的呼叫解决率，其他还有：

 一线解决率：不需要升级到其他支持团队的一线呼叫解决百分比。这通常作为服务台绩效的主要衡量方式，并用于与其他服务台进行比较，但是进行比较的时候要细心。为了更加准确和有效的比较，此标准可以分为以下几种：  第一次联系服务台期间解决的呼叫百分比，例如，用户仍在通话来进行呼叫。

 服务台不寻求其他团队支持而自行解决的呼叫百分比。注意：一些服务台会选择把技术熟练的二线支持放到服务台岗位上（详见故障管理）。这种情况下，需要进行分别比较，一是服务台员工独立解决的呼叫百分比，二是一线服务台员工和二线支持一起解决的呼叫百分比。

 解决一个故障的平均时间（由一线解决的故障） 升级一个故障的平均时间（一线不能解决的故障）

 服务台解决一个故障的平均成本，需要考虑两个度量标准：

 服务台的总成本除以呼叫数量。这提供的是一个平均数字，可以用于参考和计划，不能准确地代表不同类型呼叫的相关成本  计算服务台的呼叫持续时间和每一分钟的成本（全部成本除以呼叫持续时间），这可以计算单个呼叫的成本和提供更准确的数字

通过评估不同呼叫持续时间的故障类型，按类型区分的每次呼叫成本更准确地显示出来，并表明哪种故障类型需要花费更多成本来解决并对其改进。

 在目标时间内客户或用户升级的百分比，正如在服务级别协议目标中定义的一样

 回顾和关闭一个已解决呼叫的平均时间  一天和一周中临时故障的呼叫数量，这和平均呼叫时间一起，对决定所需的员工数量是很关键的度量标准的更多细节和它们如何用于改进服务质量的情况，可以参考《持续性服务改进》。6.2.5.1 客户/用户满意度调查

与跟踪服务台绩效的硬指标一样，评估其软指标也是重要的。例如，客户和用户对其呼叫回答的感受如何，服务台员工是否是有礼貌的和专业的，是否给予用户信心等等。

这种衡量类型来自于用户。可以作为覆盖所有IT的客户/用户满意度调查的一部分或者只是单独的服务台考核来完成。

达到单独服务台考核的一种有效方式是电话回访调查，即一个独立的服务台操作人员或监督人员在用户的故障被解决后给其中的一小部分人打电话，问其一些具体的问题。

应该保持最小数量的问题（最多5到6各），这样用户才愿意花费时间进行合作。应该对调查问题进行设计，这样用户或客户才能知道问题相关的领域或主题和他们涉及的是哪个故障或服务。服务台必须对较低的满意度和收到的任何反馈做出反应。

为了有足够的对比数据，应该选择在一段时间内具有相同百分比的呼叫。尽管受到时间压力，这些问题应该严格地执行。

调查是一项负责和专业的领域，需要对统计和调查技术有很好的了解。《服务运营》并不尝试对这些提供一个整体的概览，但是列出了广泛使用的技术和工具的概要，如图6.1所示。

6.2.6 服务台外包

做出外包的决定对高级管理层来说是一个战略问题，详见《服务战略》和《服务设计》。本章节的许多指导并不只是针对服务台的，还适用于其他功能、支持领域或服务的外包选择。

不管外包合同的原因和范围如何，重要的是，组织仍然要对服务台提供的活动和服务负责。组织最终要为决定的结果负责，所以必须决定外包商所提供的服务。

如果选择了外包，需要有保障措施来保证外包的服务台能够与组织的其他IT团队和部门开展有效的工作，保证能够维护端到端的服务管理控制（对那些进行ISO/IEC 20000认证的组织来说，这是特别重要的，因为需要展示整体的管理控制）。一些保障措施如下所述。

6.2.6.1 通用工具和流程

服务台并不为它发起的所有流程和步骤（procedures）负有责任。例如，由服务台接收但是由内部IT运维团队履行的服务请求。

如果服务台是外包的，需要关注组织内的工具与客户组织所使用的工具间的一致性。外包通常视为取代过时的或不适当的工具的机会，却发现在新工具和遗留工具间存在着严重的集成问题。

基于此种原因，重要的是保证签订外包合同前对这些问题进行适当地调研以及覆盖客户要求。服务台工具不仅要支持外包的服务台，还要能够支持客户组织的流程和业务要求。

理想状态下，外包服务台应该使用相同的工具和流程（或者，至少是接口工具和流程）来保证服务台和二线、三线支持团队之间有平滑的流程。

此外，外包服务台还应该能够访问：

 所有的故障记录和信息  问题记录和信息  已知错误数据  变更安排

 内部知识来源（尤其是技术专家或应用专家） 服务知识管理系统（SKMS） 配置管理系统（CMS） 监控工具发出的报警

在不够成熟的组织内集成这些流程和工具通常是一种挑战。一个公认但不正确的假定是一个组织的成熟度在一定意识上可以导致另一个组织更高的成熟度。应该采取积极的活动来保证流程和工具的一致对内部和外部组织之间服务的平稳过渡和持续管理是必要的。实际上，如果没有得到清晰地表述，可能导致合同的失败。

同样不正确的假定是通过在ITIL或ISO/IEC 20000的采购流程中说明（state）要求条件可以保证外包业务伙伴的服务管理质量和成熟度。这些说明可能显示一个潜在的供应商在向客户进行服务交付时使用了ITIL框架或者对于他们的内部实践他们已经达到了标准认证，但是同样重要的是，能够使用相应的技术来展示服务提供商在内部实践中和谐地管理服务和接口的能力。没有标准来遵守以保证这一要求，所以应该在采购活动中包含具体的咨询来满足这一要求。详见《服务设计》。

6.2.6.2 服务级别协议（SLA）目标

整体的故障解决要求和解决时间的服务级别协议目标需要与客户以及所有团队和部门之间达成一致。并且运营级别协议/支撑合同目标应该与单个支持团队进行协调和商定以便支撑和支持服务级别协议目标。

事例详见章节6.2.5。

6.2.6.3 良好沟通

需要在外包服务台和其他支持团队之间达成有效地沟通。以下的方式可能有助于这种沟通：

 近距离的物理位置  定期的联络/回顾会议

 团队和部门之间的交叉培训

 由两个组织的员工组成的服务台合作安排

 在服务级别协议和支撑合同中以一致的方式文档化的沟通计划和绩效目标 在服务台处于离岸的情况下，并不是所有这些方式都是可能有所帮助的。但是，服务台员工的培训和沟通仍然是关键的，特别是在语言和文化差异存在的情况下。

这部分的更多细节需要参阅ITIL的补充书籍，但是，一般说来，提供离岸服务台解决方案的外包公司应该考虑以下因素：

 关注于客户市场的文化的培训课程

 语言技巧----尤其是对客户市场习语的了解，这虽然不能够使服务台员工听起来像客户国家的本地人（客户可以很快地识别出这种情况），但是有助于更好地理解客户和鉴定优先级

 客户组织代表的定期访问来为服务台管理和员工提供培训和恰当的反馈  对客户组织的工作工具和方法的培训。6.2.6.4 数据所有权

必须建立外包服务台收集的数据的清晰的所有权。所有用户、客户、影响配置项、服务、故障、服务请求、变更等相关数据的所有权必须仍在外包此活动的组织之中，两个组织都能够访问它。

外包公司员工绩效的相关数据应为公司的资产，通常不会与客户组织共享。还有一些数据完全用于服务台的内部管理，比如人头数、优化活动、服务台成本信息等等。

关于数据所有权的所有要求条件和问题必须具体化在与提供外包服务的公司签订的支撑合同中。

备注：

UC（underpinning contract）：支撑合同 OLA（operational level agreement）：运营级别协议 Organizational commitment：组织认同感 Mentor：指导人员 Awarene:认知 Programme：课程 Skill：技巧