服务台设计方案案例参考材料Word文件下载.docx
《服务台设计方案案例参考材料Word文件下载.docx》由会员分享，可在线阅读，更多相关《服务台设计方案案例参考材料Word文件下载.docx（138页珍藏版）》请在冰点文库上搜索。
下面是服务台管理职能涉及的关键术语。
呼叫。
呼叫是由客户通过一切通信手段（包括电话、电子邮件、语音邮件等）向服务台发出的联络信息。
事故。
事故指不属于标准服务运转范畴并可能导致服务中断或服务质量下降的事件。
重大事故。
重大事故指具有严重影响或可能导致严重影响的事故，通常需要采取超出一般事故的应对措施。
重大事故往往在企业间协作、管理升级、资源机动和联络改进等方面提出更高要求。
服务请求。
服务请求是针对新增或变更服务提出的调用需求。
不同组织机构可能提出不同类型的服务请求，但常规服务请求无外乎变更请求（RFC）、信息请求（RFI）和服务扩展等。
问题。
问题是导致一或多次事故却未经查明的根源。
已知错误。
已知错误是指已查明根源并找到权宜之计或永久替代方案的事故或问题。
业务问题一旦出现，变更请求（RFC）就会产生，但它无论如何都属于已知错误——除非已被某项变更修复。
应对方案。
应对方案是为确保常规服务得到恢复而对特定事故加以排除的已知手段；
当然，这种手段将首先解决引发事故的问题。
解决方案/永久性修复。
解决方案/永久性修复是能够从根本上杜绝某种特定事故或问题的已知手段。
一线支持团队。
一线支持团队是直接提供事故与服务请求受理支持的专门团队。
一线支持团队负责在与客户进行联络的第一时间通过辨别已知应对方案、使用诊断脚本或运用自身知识等手段尝试排除事故。
服务台在大量组织机构中充当着一线支持团队。
解决方案小组。
解决方案小组是负责对一线支持团队无法应付的事故和服务请求加以处置的专家团队。
不同机构具有不同的支持团队组织架构，其中一些采取层次化架构（包括第一层、第二层和第三层……），而另一些则组建面向平台或应用的专门团队（如主机团队、桌面团队、网络团队和数据库团队等）。
服务台结构
我们可通过多种方式在组织机构范围内营造服务台。
我们必须在项目计划阶段内确定所需运用的服务台结构。
（其它相关文档将详细描述服务台构造方法；
鉴于后文中的某些过程设计考量取决于所选结构，因此，我们将对服务台构造做简单介绍。
）
表1服务台结构
服务台类型
要求
工具
优势
集中式
集中式服务台可为广泛分布在不同地理位置的全体企业用户提供支持。
清晰的组织领导脉络和紧密衔接的伺服任务。
注意：
集中式服务台仍需得到解决方案小组的技术支持，而后者则可能处于分散状态且/或与用户同处一地。
允许用户通过单键拨号呼叫服务台的电话系统。
这种工具包括用来接听拨入电话的交互式语音应答（IVR）、自动呼叫分配（ACD）和计算机—电话集成（CTI）等应用技术。
专供服务台接收电子邮件求助呼叫并发送应答信息的电子邮件帐户。
针对服务台操作流程（呼叫记录、监控和报告等）支持工具的访问调用权限。
这还可能包括通往运行上述工具的服务器的网络连接。
用户清楚地知道向哪里请求支持。
有助于精简专业人员队伍，进而压缩培训、装备与设施成本。
从宏观角度促进管理整合。
分散式
分散式服务台拥有广泛分布于不同地理位置的大量子服务台。
在多个位置提出相同需求的情况下，创建为多个位置的共同需求提供伺服的单一服务台将更加有效。
不同站点之间应存在明确清晰的联络渠道——这一点至关重要。
本地化技能应被广而告之，并可供其它服务台站点调用。
这种方式更有助于面向分散在多个不同时区的用户提供伺服。
硬件和软件应具备兼容性。
应采用通行管理报告指标体系。
每个服务台都必须具备针对通用文档/资源库的访问调用权限
。
应具备在服务台之间传递或报送用户请求的能力。
针对呼叫记录、升级和报告任务采取通用操作流程。
为整个服务台（或至少一个共享数据库）采取通用支持工具。
必须围绕影响力、严重性、优先级、状态代码及闭合类型等指标定义通用取值范围。
虽可在不同位置使用不同工具，但我们仍建议所有服务台使用相同的基础工具集，以便在某个位置遭受灾难性破坏时，由应急策略安排另一位置暂时承担相关作业。
为基于特定位置的群组或人员提供定制化支持。
专业人员可针对某一特定位置开发高阶技巧。
如能以当地语言为母语的专业人员充实本地服务台技术团队，便可更加轻松地提供多语支持服务。
每个服务台均可在其它服务台遭遇自然灾害等突发事件的情况下为受到影响的服务台提供备份支持。
将服务台分散部署的方案有助于储备更加丰富的人力资源。
虚拟服务台
虚拟服务台建立在网络性能改进和电信技术优势基础上——物理和地理意义上的服务台并不真正存在。
虚拟服务台是将集中式和分散式服务台组成要素有机结合的产物——用户虽可通过相同路由访问服务台，但其所发出的呼叫却会根据一系列因素（如当日时点、地方公众假日和呼叫容量等）被路由到多个不同位置。
通用呼叫记录与跟踪工具必须可供所有服务台访问。
相同的任务流程和操作程序必须可供所有服务台运用，以确保服务连贯性。
在虚拟服务台环境下，确保这些关键点得以实现具有更加重要的意义——与分散式服务台结构不同，所有服务台均可支持同一用户群体，而求助呼叫则可从一个服务台传递至另一服务台。
确保所有服务台贯彻完全一致的呼叫主权界定标准同样至关重要。
如果虚拟服务台必须面向使用不同语言的多个地区提供伺服，那么，就必须事先约定用以记录呼叫日志的通用语言。
必须配备允许处在不同位置的全体用户使用既定号码呼叫虚拟服务台的电话系统。
这并不意味着所有用户站点均应使用同一电话号码，因为呼叫本地号码往往对用户更加便利。
这个要求的真正含义在于，每当某个服务台接替另一服务台时，用户既不必随之更换服务台联络号码（每个用户均可通过单键拨号呼叫服务台），也无须了解当前呼叫路由。
电话系统必须能够将针对所有本地服务台电话号码的呼叫请求路由到目前处于值勤状态的服务台位置。
此外，电话系统还应具备通过人工操作或根据预设条件（如当日时点）切换目标位置的能力。
如果同一时刻存在不止一个处于开放状态的服务台，那么，电话系统应能根据呼叫源点和呼叫等待队列长度等因素将拨入呼叫路由到最合适的服务台位置。
所有服务台必须使用完全相同的集中式工具。
由任一服务台记入日志的呼叫必须可供其它所有服务台用于参考和更新目的。
这可能需要每个服务台均具备通往运行所需工具之中央数据中心的必要网络连接。
这种结构可支持覆盖24小时的“全日轮勤”方式，即每个服务台仅在本地区正常工日的白班时段内处于执勤状态。
一旦服务台经过了当天的白班执勤时段，所有呼叫就会被路由到处在另一时区的服务台——那里的全体员工刚刚开始一天的工作。
小型支持机构中的服务台
规模较小的组织机构可能只拥有一个相对独立的服务台，而服务台操作过程则可能由负责提供二线支持的人员制定。
集中联络点可能是支持机构约定的单一电话号码和/或电子邮件呼叫地址。
而受理呼叫请求（电话或电子邮件）的任务则由技术支持人员轮班承担。
由于接听来电的人员通常为技术支持专家，因此，很大一部分呼叫可能总是针对第一位联系人。
针对机构规模扩大实施服务台拓展
大型机构通常需要具备全方位覆盖能力的服务台。
提供大型服务台支持可能面临一些特殊挑战，并迎来一些改进效率的机会。
大型服务台既有机会、更有必要提高自身操作运转效率。
这里所说的机会体现为，随着服务台规模的扩大、服务台职能的多样化以及服务台调节自身工作负载能力的不断强化（这是小规模运转方式无法启及的），规模经济效益将变得越来越突出。
而这里所说的必要性则归因于规模扩张导致的效率降低。
在小型服务台中不可避免或无足轻重的低效现象可能伴随服务台规模的扩张迅速演化为成本增长点。
本文后续章节将围绕服务台效率优化问题展开深入研讨（参见“优化服务台”）。
IT机构中的服务台
服务台是客户与IT机构开展联络的焦点。
它不仅是客户与IT职能部门进行沟通的“窗口”，而且是确保IT团队成员在避免不必要干扰的前提下有序完成自身工作的“过滤器”。
服务台还为其它服务管理职能及过程提供了前端焦点。
图1展示了服务台与其它实体进行交互的方式。
图1：
服务台交互方式
查看大图。
范围
如前所述，设立服务台的目标之一就是为IT机构提供单一联络点。
范围问题重点关注访问受理主体和联系人类型。
服务台为哪些人提供支持？
许多机构都为解答客户或用户问题设立了某种形式的集中联络点。
此项职能拥有“技术支持中心”或“呼叫中心”等不同称谓。
下表列示了每种不同称谓，并进行了适当描述：
表2集中联络点
功能
描述
呼叫中心
呼叫中心是一个功能术语。
这种功能主要帮助银行、公用事业部门和邮购公司等企业处理外部客户通过电话发出的大量事务或交易请求。
呼叫中心通常分为两类：
入站式和出站式。
入站式呼叫中心通常接收目标客户针对印刷品、电台或电视广告做出的回应。
出站式呼叫中心一般主动向目标客户发出以产品促销和市场推广为目的的呼叫。
某些呼叫中心兼具以上两种职能，可由业务代表将服务时间人为分配给入站和出站两种活动。
客户热线
客户热线通常负责受理外部客户来电——往往与投诉、产品查询、产品订购、求助和建议等相关。
技术支持中心
技术支持中心主要面向企业内部用户或客户提供支持服务。
技术支持中心专业人员负责对用户疑难问题进行管理和协调，并尽快加以解决。
他们还负责将全部问题记录在案。
服务台
服务台虽以所属企业IT基础架构用户为首要服务对象，却可将服务范围拓展到提供以业务为核心的技术支持。
这就允许企业将业务流程纳入服务管理框架。
服务台不仅负责处理事故、疑难和信息查询请求，而且，还将为客户提供与所有IT处理流程（包括变更请求、采购、服务级别管理和作业调度等在内）实现互动的路由。
服务台所支持的对象既可能是企业IT基础架构内部用户，又可以是需要访问企业IT基础架构的外部客户。
服务台将执行哪些任务？
服务台可为两种联络对象提供支持：
事故和服务请求。
下表对这两种联络对象分别进行了描述：
表3联络对象类型
类型
职能
事故
事故指不属于标准服务组成部分的偶发事件。
事故可能导致常规服务异常中断或服务质量下降。
在这种情况下，服务台的职能体现为尽快恢复向受事故影响的用户提供服务。
服务请求
以下列举了服务请求的典型示例：
变更请求。
信息请求（即查询）。
随需作业请求。
采购请求。
用户与IT部门之间的一切交流沟通（例如投诉、致谢、评价或建议）。
服务台在服务请求方面承担的职责就是保证按照用户满意的方式处理相关请求——既可直接满足用户请求，又可将用户请求转交给适当解决方案小组。
服务台的主要优点
服务台在客户、用户、IT服务和第三方支持机构间提供了至关重要的日常联络点。
对客户来说，服务台是他们领略企业级服务和专业技术水准的唯一窗口，并因此具有特殊重要性。
服务台是架设在用户和服务支持人员之间的桥梁。
服务台的目标就是提供：
确保将变更情况记录在案并围绕疑难领域提供支持的基础架构管理服务。
与IT部门专业胜任能力相关的良好技术服务体验。
实现服务及时提交的前瞻性手段。
有助于避免业务应用功能中断的方法。
得到改进的业务工作效能。
组织机构可通过部署实施服务台获得下列收益：
优化客户服务质量，改善客户对IT部门服务提交能力的感性认识，并提高客户满意程度。
通过单一联络点为客户接触IT部门所司职能创造便利，并在此基础上开辟一条信息沟通渠道。
提高求助响应质量，加快客户请求受理速度。
在IT机构内部和客户与IT机构之间改善团队工作及信息沟通效果。
提高对支持需求的关注程度。
实现具有前瞻性的服务提交手段。
增进对IT服务所支持业务流程的理解，削弱对主营业务活动的消极影响。
提高IT基础架构管理水平，优化IT基础架构开发控制。
优化支持资源运用方式，提高业务人员工作效率。
为准确评估服务台实现的相关收益奠定可靠基础。
服务台可收集内容翔实的管理信息，足以为业务决策过程提供必要支持。
可由服务台提供的信息资料包括：
人力资源使用状况
服务缺陷
服务性能与目标实现情况
客户培训需求
相关成本费用
除上述有形收益外，服务台还将通过下列方式为企业创造价值：
充当辨别并控制IT与支持基础架构成本的战略职能机构。
跨越彼此分散的业务、技术和过程界限为变更集成与管理任务提供支持。
通过提高资源与技术使用效率控制成本费用。
为投资优化与业务支持服务管理活动提供支持。
有助于从长远角度维系客户群体并保持客户满意程度。
有助于准确把握商业机遇。
主要过程
作为一项服务管理职能（SMF），服务台涉及以下重要过程：
服务台操作运转。
服务台业务优化。
服务台操作运转
服务台操作运转过程主要用于规范服务台日常管理任务，具体包括：
表4过程任务
任务
日常资源管理。
对预期呼叫处理容量及相关配置文件实施跟踪监控，以确保专业人员数量和技能符合实际需要。
客户沟通交流。
尽早或及时缔结客户关系。
履行服务台过程。
提供其它SMF所需信息资料及控制手段，并对服务台与其它SMF之间的有效衔接实施管理。
服务台宣传推广。
提倡使用服务台，宣传服务台所蕴含的效能。
成本控制
跟踪记录服务台运转成本，并通过向用户收费弥补相关开支。
监视服务台人员工作业绩。
对资源、进程、工具、第三方及客户满意程度实施监控。
编制报告。
编制管理当局所需各种报告。
图2描绘了必须履行的服务台日常管理任务。
图2：
服务台日常管理任务
管理人员和资源
为确保通过服务台提供高质量服务，完全有必要围绕入站呼叫处理技能开展人员培训。
如果服务台提供跨国服务，则要求工作人员兼具专业、沟通和语言技巧。
人员调度
下表描述了众多人员调度方式中的两种：
表5调度模式
调度类型
调度原则
时限驱动群体
主要用来调配从事软件开发和硬件维护工作的计算机支持人员。
此类群体必须在指定日期或时点提交工作成果或完成相关任务。
人们通常运用项目管理系统设定任务里程碑。
要求准时抵达里程碑，但不强调于特定时点或日期执行相关任务。
需求驱动模式
主要用来编制服务台资源日程计划。
要求对客户需求做出精确预测；
这种预测通常以历史数据、已知事件/问题（如最新发布活动）、正被付诸实现的变更或最新商业动机为依据。
应具备在问题发生时对用户请求做出迅速响应的能力，集中体现为用户使用设备开展正常工作的小时数。
正常工作小时数往往取决于用户发出求助呼叫的具体形式。
尽管用户可能容忍一定数量的自动化前端应答系统，但尽快连通可对其问题做出直接回答人工语音服务对他们来说更加重要。
这种人工语音服务有助于增强用户对服务台抱有的信心，并能缓解用户因事故产生的失望情绪和打败感。
上面介绍的两种方法都需要由人工语音服务人员接听用户呼叫。
如果大多数服务台工作人员不司职守，用户请求长时间无人理睬，那么，服务台的信誉和效用将大打折扣。
灵活、高效且具备亲和力的调度系统对于面向目标客户提交无缝化基础架构服务来说尤为重要。
服务台的创建动机往往体现为通过下列途径降低企业整体运营成本：
最大限度地缩短系统停机时间。
降低最终用户学习强度。
降低对外部支持提供商（如硬件厂商、软件厂商和咨询公司）的依赖程度及由此产生的成本代价。
应建立确保服务台资源在关键工作时段处于可用状态的效率机制，否则，由服务台实现的成本节省效益将可能被其它部门产生的额外成本抵销殆尽。
编制日程计划
应在计划阶段合理确定服务台人员配置规模。
每当为特定工作计划配置人员资源时，均应将以下两方面纳入考虑：
服务台将在哪个时段处于开放状态？
应在开放时段为服务台配置多少工作人员？
确定服务台开放时段具有至关重要的意义。
服务台开放时间既可能跨越正常营业日中的若干时段，又可能处于每周7天、每天24小时的“全天候”开放状态（通常简称为“24/7”）。
我们应在服务台项目计划阶段合理确定上述信息。
只有在确定开放时段的前提下，才可能为轮班值勤制度合理配备人力资源，并照顾到不同工作时段的起码人员需求。
应在制定日程计划时纳入考虑的另一种可能性就是团队成员的个人偏好。
倘若服务台开放时间超出了从早8点到晚5点的正常班时段，便有可能出现各种异常的值班日程，例如：
可能安排个别员工上早班或值夜班。
可能对个别员工执行每周4天、每天10小时的作息制度，而非通常采用的每周5天、每天8小时。
还可能为方便员工个人或所属企业制定其它别具创意的作息计划。
调度模式
调度模式置于多种理论和方法的规范之下。
下表介绍了适合服务台选用的五种不同方法。
放之四海皆准的人员调度方法并不存在；
因此，图3对每种调度模式进行了高度概括。
这种概括性描述可指导我们在计划阶段研讨并确定针对企业服务台选用的适当调度方法。
表6调度方法
关键属性
代表“调度模式概况图”中的列标题，用来对图表中行标题指代的每种调度方法进行详细描述。
人员
将根据服务台所需人员数量划分为三类。
经验
可划分为三种类型：
新近招募或临时选聘的服务台分析人员，普通服务台分析人员，资深或极富经验的服务台分析专家。
支持类型
代表服务台提供的两个层次的支持服务：
第一层提供常规帮助，第二层提供专业支持。
管理时间
指示特定调度方法所需占用的管理时间。
用于实施日程计划的管理时间可被划分为启动阶段（即初始变更阶段）管理时间和变更事项成为标准操作过程后的管理时间。
这虽不是用于制定日程计划的时间，但却由团队成员在日常工作中占用。
图3：
调度模式概况图
后续小节将对每种调度模式分别做详细介绍：
半小时计划
服务台管理人员可能需要以半小时为单位安排团队成员在整个工作日中接听来电的时段。
在以半小时为单位的来电频率已知或可预测的前提下，这种调度模式将有可能实现。
管理人员可针对近期服务需求以半小时为单位合理配置电话接听人员。
他们可根据历史经验和预测信息估计来电频率，进而确定未来30分钟所需配置的接线员数量。
从理论角度来看，这种方法有助于为特定时段部署适量人员。
表7半小时计划
风险
依赖性
团队成员将清楚地知道自己负责受理来电的时间。
这个系统的实现带有较强的时效性。
有关负责人必须为每个服务台群组预先制定日程计划。
管理人员清楚地知道谁应在电话前值班。
这要求日程计划得到不折不扣的遵守，否则服务水平将受到影响。
这种模式仅适用于通过电话提供的直接支持服务。
严谨的预测分析和对日常呼叫形式的准确把握将保证“半小时调度模式”成为极其高效的大容量呼叫队列处理手段。
针对既定日程做出的变更需要配合新计划或其它修正因素接受进一步调整。
这些变更将明显加大制定日程计划的工作强度。
必要时，还应为确保日程计划的顺利履行开展跨站点沟通、协作与策略协调活动。
轮班时间越短，服务台满足服务水平要求的效力越强。
这种方法不允许团队成员未经批准擅自脱离电话值班岗位。
而这种可用性水平只有在所有相关策略和程序都支持上述模式的前提下才能得以维系。
日程计划必须将地方性劳动法规提出的工间休息要求纳入考虑。
建议
该体系在波动性强、处理容量大的需求驱动环境下最为有效——因为在这种环境下，确保服务提交水平具有最高优先级。
它是一种劳动密切型模式，并具有刚性特征，可谓利弊兼备。
它最适用于来电频率和人力配置需求相对可预测且不受复杂轮班计划制约的情形。
对于只需满足较低服务要求的小型团队来说，上述体系并不是最为理想的解决方案——因为这种情形更可能显现出最大限度的需求波动（按百分比计算）——一种有时被称作小队综合症的现象。
我们同样不主张采用被动响应服务提交模式（如电话回拨或电子邮件支持）。
?
自治团队（Pod）
自治团队堪称这份指南中最富挑战和创新特色的组织战略，并且具有最大回报潜力。
每个团队（有时被称作一个pod）通常承担第一层、第二层甚至第三层呼叫支持任务，而团队成员之间还可根据指令开展角色互换。
自治团队要么不采用定岗轮班制度——整个团队都上正常班（例如，从早8点到晚5点）并在午餐后小憩，每当有电话拨入时任何团队成员均有责任立即接听来电，要么根据需求模式和服务级别编制自己的日程计划。
这种模式并不要求服务台工作人员在电话机前值满一定小时数。
这种模式与大多数组织形式背道而驰，而它所折射出的哲学理念变迁更不容低估。
虽然这种模式已在某些机构中被证明行之有效，但它的实现往往需要一支成熟老练的团队作为依托。
表8自治团队
服务台资源调配工作强度将得到明显降低。
在只安排单一班次和午后休息（午后休息同样可自行决定）的前提下，服务台管理任务重心将从时间计划和人员调度转移到工作效率分析之上。
在缺乏义务承诺和抽查监控的情况下，系统将可能遭到不当使用。
该体系依赖于一种服务文化；
在这种文化氛围的感召下，团队成员将自觉开展正当活动。
尽管存在服务提交及其它硬性目标，然而，这些目标的实现将取决于整个团队和每名成员。
引导员工将思维重心从怎样最有助于实现个人业绩评价指标转移至怎样最有利于企业需要付出大量时间和辛劳，并可能涉及对公司薪酬或管理体系的重新评估。
在人员配置得当的前提下，服务台资源将可在更长时段内接听陆续拨入的求助电话，并保证应答次数不受影响
升级会员 