服务台设计方案案例参考材料.docx

服务台设计方案案例参考材料.docx

《服务台设计方案案例参考材料.docx》由会员分享，可在线阅读，更多相关《服务台设计方案案例参考材料.docx（124页珍藏版）》请在冰豆网上搜索。

服务台设计方案案例参考材料

服务台概述

服务台的一大优势表现为，它是目标客户与技术服务专家进行联络的单一接合点。

它为世界各地的繁忙人群提供了一个快捷有效的解决方案，而一些不起眼的事情往往关乎企业成败。

服务台为遭遇IT基础架构疑难问题的客户提供了交流园地、信息资料和解决方案。

困扰商务企业的某些问题可能包括：

•

缺乏现成可用的结构化客户支持机制。

•

客户对IT部门缺乏信心。

•

组织机构的规模扩张超出了支持体系的承受能力。

•

支持资源受到严格管控。

•

支持资源持续被琐事困扰或不断解决相同问题。

•

支持资源根据服务中断故障排除需求进行配置。

•

过度依赖关键技术人员。

•

IT部门无法集中力量从事当前研发项目。

•

发生未经协调和/或未经记录的变化。

•

企业领导和/或工作人员无法应对所面临的改变。

•

人力资源和成本控制需求不明确。

•

求助响应质量和响应时间缺乏连贯性。

•

缺乏基本决策管理信息。

定义支持过程（包括定义角色与职责）并对用户支持途径加以整合有助于克服上述问题，并提高企业获得成功的机率。

目的与目标

明确界定服务台的用途和目标并将其记录在案具有至关重要的意义。

编制任务说明或明确界定支持提供途径属于实现上述目标的一种方法。

在计划阶段及早明确项目意图可确保全体团队成员围绕公司既定目标开展密切协同。

考虑到企业希望通过服务台提供的服务类型各不相同，因此，上述目标可能取决于组织机构规模和服务台既定职能范畴等众多因素。

现举例说明某些服务目标：

•

在用户与IT部门之间提供单一、集中联络点。

•

为用户提供通往其它服务管理职能（如变更管理、问题管理、配置管理和发布管理等）的切入点。

•

提交实现业务目标所需高质量支持服务。

•

辨别并压缩IT服务总体拥有成本（TCO）。

•

跨越业务、技术和过程界限为变更提供支持。

•

提高客户满意程度。

•

保持客户忠实度。

•

发现更多商业机遇。

关键定义

下面是服务台管理职能涉及的关键术语。

•

呼叫。

呼叫是由客户通过一切通信手段（包括电话、电子邮件、语音邮件等）向服务台发出的联络信息。

•

事故。

事故指不属于标准服务运转范畴并可能导致服务中断或服务质量下降的事件。

•

重大事故。

重大事故指具有严重影响或可能导致严重影响的事故，通常需要采取超出一般事故的应对措施。

重大事故往往在企业间协作、管理升级、资源机动和联络改进等方面提出更高要求。

•

服务请求。

服务请求是针对新增或变更服务提出的调用需求。

不同组织机构可能提出不同类型的服务请求，但常规服务请求无外乎变更请求（RFC）、信息请求（RFI）和服务扩展等。

•

问题。

问题是导致一或多次事故却未经查明的根源。

•

已知错误。

已知错误是指已查明根源并找到权宜之计或永久替代方案的事故或问题。

业务问题一旦出现，变更请求（RFC）就会产生，但它无论如何都属于已知错误——除非已被某项变更修复。

•

应对方案。

应对方案是为确保常规服务得到恢复而对特定事故加以排除的已知手段；当然，这种手段将首先解决引发事故的问题。

•

解决方案/永久性修复。

解决方案/永久性修复是能够从根本上杜绝某种特定事故或问题的已知手段。

•

一线支持团队。

一线支持团队是直接提供事故与服务请求受理支持的专门团队。

一线支持团队负责在与客户进行联络的第一时间通过辨别已知应对方案、使用诊断脚本或运用自身知识等手段尝试排除事故。

服务台在大量组织机构中充当着一线支持团队。

•

解决方案小组。

解决方案小组是负责对一线支持团队无法应付的事故和服务请求加以处置的专家团队。

不同机构具有不同的支持团队组织架构，其中一些采取层次化架构（包括第一层、第二层和第三层……），而另一些则组建面向平台或应用的专门团队（如主机团队、桌面团队、网络团队和数据库团队等）。

服务台结构

我们可通过多种方式在组织机构范围内营造服务台。

我们必须在项目计划阶段内确定所需运用的服务台结构。

（其它相关文档将详细描述服务台构造方法；鉴于后文中的某些过程设计考量取决于所选结构，因此，我们将对服务台构造做简单介绍。

）

表1服务台结构

服务台类型

要求

工具

优势

集中式

集中式服务台可为广泛分布在不同地理位置的全体企业用户提供支持。

清晰的组织领导脉络和紧密衔接的伺服任务。

注意：

集中式服务台仍需得到解决方案小组的技术支持，而后者则可能处于分散状态且/或与用户同处一地。

允许用户通过单键拨号呼叫服务台的电话系统。

这种工具包括用来接听拨入电话的交互式语音应答（IVR）、自动呼叫分配（ACD）和计算机—电话集成（CTI）等应用技术。

专供服务台接收电子邮件求助呼叫并发送应答信息的电子邮件帐户。

用户清楚地知道向哪里请求支持。

有助于精简专业人员队伍，进而压缩培训、装备与设施成本。

从宏观角度促进管理整合。

服务台类型

要求

工具

优势

针对服务台操作流程（呼叫记录、监控和报告等）支持工具的访问调用权限。

这还可能包括通往运行上述工具的服务器的网络连接。

分散式

分散式服务台拥有广泛分布于不同地理位置的大量子服务台。

在多个位置提出相同需求的情况下，创建为多个位置的共同需求提供伺服的单一服务台将更加有效。

不同站点之间应存在明确清晰的联络渠道——这一点至关重要。

本地化技能应被广而告之，并可供其它服务台站点调用。

这种方式更有助于面向分散在多个不同时区的用户提供伺服。

虽可在不同位置使用不同工具，但我们仍建议所有服务台使用相同的基础工具集，以便在某个位置遭受灾难性破坏时，由应急策略安排另一位置暂时承担相关作业。

为基于特定位置的群组或人员提供定制化支持。

专业人员可针对某一特定位置开发高阶技巧。

如能以当地语言为母语的专业人员充实本地服务台技术团队，便可更加轻松地提供多语支持服务。

每个服务台均可在其它服务台遭遇自然灾害等突发事件的情况下为受到影响的服务台提供备份支持。

服务台类型

要求

工具

优势

硬件和软件应具备兼容性。

应采用通行管理报告指标体系。

每个服务台都必须具备针对通用文档/资源库的访问调用权限

。

应具备在服务台之间传递或报送用户请求的能力。

针对呼叫记录、升级和报告任务采取通用操作流程。

为整个服务台（或至少一个共享数据库）采取通用支持工具。

必须围绕影响力、严重性、优先级、状态代码及闭合类型等指标定义通用取值范围。

将服务台分散部署的方案有助于储备更加丰富的人力资源。

虚拟服务台

虚拟服务台建立在网络性能改进和电信技术优势基础上

通用呼叫记录与跟踪工具必须可供所有服务台访问。

必须配备允许处在不同位置的全体用户使用既定号码呼叫虚拟服务台的电话系统。

这种结构可支持覆盖24小时的“全日轮勤”方式，即每个服务台仅在本地区正常工日的白班时段内处于执勤状态。

服务台类型

要求

工具

优势

——物理和地理意义上的服务台并不真正存在。

虚拟服务台是将集中式和分散式服务台组成要素有机结合的产物——用户虽可通过相同路由访问服务台，但其所发出的呼叫却会根据一系列因素（如当日时点、地方公众假日和呼叫容量等）被路由到多个不同位置。

相同的任务流程和操作程序必须可供所有服务台运用，以确保服务连贯性。

在虚拟服务台环境下，确保这些关键点得以实现具有更加重要的意义——与分散式服务台结构不同，所有服务台均可支持同一用户群体，而求助呼叫则可从一个服务台传递至另一服务台。

确保所有服务台贯彻完全一致的呼叫主权界定标准同样至关重要。

如果虚拟服务台必须面向使用不同语言的多个地区提供伺服，那么，就必须事先约定用以记录呼叫日志的通用语言。

注意：

这并不意味着所有用户站点均应使用同一电话号码，因为呼叫本地号码往往对用户更加便利。

这个要求的真正含义在于，每当某个服务台接替另一服务台时，用户既不必随之更换服务台联络号码（每个用户均可通过单键拨号呼叫服务台），也无须了解当前呼叫路由。

电话系统必须能够将针对所有本地服务台电话号码的呼叫请求路由到目前处于值勤状态的服务台位置。

此外，电话系统还应具备通过人工操作或根据预设条件（如当日时点）切换目标位置的能力。

一旦服务台经过了当天的白班执勤时段，所有呼叫就会被路由到处在另一时区的服务台——那里的全体员工刚刚开始一天的工作。

服务台类型

要求

工具

优势

如果同一时刻存在不止一个处于开放状态的服务台，那么，电话系统应能根据呼叫源点和呼叫等待队列长度等因素将拨入呼叫路由到最合适的服务台位置。

所有服务台必须使用完全相同的集中式工具。

由任一服务台记入日志的呼叫必须可供其它所有服务台用于参考和更新目的。

这可能需要每个服务台均具备通往运行所需工具之中央数据中心的必要网络连接。

小型支持机构中的服务台

规模较小的组织机构可能只拥有一个相对独立的服务台，而服务台操作过程则可能由负责提供二线支持的人员制定。

集中联络点可能是支持机构约定的单一电话号码和/或电子邮件呼叫地址。

而受理呼叫请求（电话或电子邮件）的任务则由技术支持人员轮班承担。

由于接听来电的人员通常为技术支持专家，因此，很大一部分呼叫可能总是针对第一位联系人。

针对机构规模扩大实施服务台拓展

大型机构通常需要具备全方位覆盖能力的服务台。

提供大型服务台支持可能面临一些特殊挑战，并迎来一些改进效率的机会。

大型服务台既有机会、更有必要提高自身操作运转效率。

这里所说的机会体现为，随着服务台规模的扩大、服务台职能的多样化以及服务台调节自身工作负载能力的不断强化（这是小规模运转方式无法启及的），规模经济效益将变得越来越突出。

而这里所说的必要性则归因于规模扩张导致的效率降低。

在小型服务台中不可避免或无足轻重的低效现象可能伴随服务台规模的扩张迅速演化为成本增长点。

本文后续章节将围绕服务台效率优化问题展开深入研讨（参见“优化服务台”）。

IT机构中的服务台

服务台是客户与IT机构开展联络的焦点。

它不仅是客户与IT职能部门进行沟通的“窗口”，而且是确保IT团队成员在避免不必要干扰的前提下有序完成自身工作的“过滤器”。

服务台还为其它服务管理职能及过程提供了前端焦点。

图1展示了服务台与其它实体进行交互的方式。

图1：

服务台交互方式

查看大图。

范围

如前所述，设立服务台的目标之一就是为IT机构提供单一联络点。

范围问题重点关注访问受理主体和联系人类型。

服务台为哪些人提供支持？

许多机构都为解答客户或用户问题设立了某种形式的集中联络点。

此项职能拥有“技术支持中心”或“呼叫中心”等不同称谓。

下表列示了每种不同称谓，并进行了适当描述：

表2集中联络点

功能

描述

呼叫中心

呼叫中心是一个功能术语。

这种功能主要帮助银行、公用事业部门和邮购公司等企业处理外部客户通过电话发出的大量事务或交易请求。

呼叫中心通常分为两类：

入站式和出站式。

入站式呼叫中心通常接收目标客户针对印刷品、电台或电视广告做出的回应。

出站式呼叫中心一般主动向目标客户发出以产品促销和市场推广为目的的呼叫。

功能

描述

某些呼叫中心兼具以上两种职能，可由业务代表将服务时间人为分配给入站和出站两种活动。

客户热线

客户热线通常负责受理外部客户来电——往往与投诉、产品查询、产品订购、求助和建议等相关。

技术支持中心

技术支持中心主要面向企业内部用户或客户提供支持服务。

技术支持中心专业人员负责对用户疑难问题进行管理和协调，并尽快加以解决。

他们还负责将全部问题记录在案。

服务台

服务台虽以所属企业IT基础架构用户为首要服务对象，却可将服务范围拓展到提供以业务为核心的技术