...p; 科索路咨询 钱晨 对于IT组织而言，服务台是直接和用户交互的接口，用户在此体验到的服务会直接影响用户对整体服务的满意度。因此，如何提高服务台的服务质量是每位cio都应该认真考虑的问题。 通过提供一个集中和唯一的服务联络点，服务台促进了IT组织业务流程与服务管理基础架构的集成，主要包含以下职能： ...
这两星期与IT服务台经理一起，根据目前企业的组织架构，IT的现状和用户的行为习惯，大致将IT服务台的职能定位为以下几点：1 IT用户的支持和问题解决（最常见的IT服务台功能）2 门店营业系统的每天日常批处理操作（如：每天开店前系统检查，每晚数据传输监控，每晚日结传输等）3 全国IT项目部署支持（支持总部IT项目的全国部署工作，并做好日后支持的准备）4 开新店的IT准备（与总部IT的各系统职能负责人，供应商， 新店负责人协调各项准备事宜）接下来的事情是准备根据当前IT服务台存在的问题和工作职能对IT服务台的8个leader分别制定08年的工作目标和绩效考核计划。...
载于http://cio.ciw.com.cn/cio02/20080421110702.shtml8：50 我准时出现在公司门口。打卡、上楼梯、打开电脑。按以往的惯例我上班之前都要去服务台转转，了解最新的服务受理情况。但现在习惯变了，不是第一时间走到服务台了解服务受理，而是第一时间打开电脑查看ITSM系统的记录。通过ITSM系统，我可以及时了解最新的服务受理情况及其处理进度。即使我不在服务台也能够对IT服务做到心中有数。 昨晚至今早的服务受理基本正常。只有一个客户投诉、几个事件的处理超时和部分客户出现数据通讯故障需要进一步关注。“今天的开头不错。”我带着愉悦心情，迈着轻松的步子去服务台了解这些事件。路走了一半，经过服务总监办公室门口时我被叫了进去。“昨晚试点发布新版本的客户在今早进行数据通讯时出故障了。...
作者：钱晨 文章来源：中计在线 更新时间：2006-12-4 15:34:21 服务台的层次结构示意图 典型的二维优先级定义表 通过提供一个集中和唯一的服务联络点，服务台促进了IT组织业务流程与服务管理基础架构的集成，主要包含以下职能： ·响应用户的请求，尝试解决或者将其指派给合适的人加以解决，满足服务级别协议。 ·根据服务级别协议的规定监控突发事件并进行事件处理的升级管理。 ·根据实际情况，就服务级别协议的任何变动及时与用户进行沟通。 ·协调二线人员和第三方支持组织。 ·安排用户的培训和教育计划。 下面，让我们来看看怎么样具体建立起最适合的服务台。 选择合适的服务台结构 分布式服务台、集中式服务台和虚拟式服务台是在企业或者IT...
在日常工作中业务部门经常会提到IT服务台的客户满意度怎么样，我们大部分的精力也花在如何提高客户满意度方面，但是IT服务台的建设和考核还需要关注到其他的哪些方面呢？最近在看一本HDI出版的《Implementing Service and Support Management Process：A Practical Guide》，其中在第一章就提到了从财务和营运的角度看IT服务台的管理关注点，或者说IT服务台平衡记分卡的四个方面即：客户满意度，员工满意度，成本/生产力，组织成熟度。目前我们的IT服务台还只是主要关注在客户满意度方面，但是真的要建设一个perfect的IT服务台的话，我们在其他的三方面还需要做很大量的工作。需要更多的关注并提升员工的满意度；加强IT服务台的各种培训，形成完善的培训体系；进行IT服务财务管理，进行服务的成本核算，根据业务的需求增长对IT服务台的成本做到良好的预算；...
今天在ITIL群中有人问了一个问题：事件经服务台转入2线后，作为服务台是否有必要加入到事件的进度推进中？如果加入，那么服务台扮演什么角色？如果在服务台不介入的情况下，有什么办法可以使2线自觉推进事件进度?因为当时有事没真正地参与到讨论中。只说了一句话：“服务台是事件的主人”如果能够理解服务台是事件主人这句话，那上面的问题就能很好地回答了。服务台是否有必要介入到事件的进度推进，我们反过来想，服务台在受理了客户报修之后不再跟踪事件的进度，等到事件处理完毕之后得到一个最终结果。要么服务台对客户做一个满意度的回访，要么就等着客户的投诉。为什么这么讲呢？在不考虑积极改善服务水平的情况下，服务台根本不需要跟踪事件的进度。但是要做好主动服务，服务台的跟踪必须要有，而且还要积极。服务台对事件进程了如指掌的话，就会发现事件处理在时间和过程中的异常。各位都会有一个体验，就是等人。约好了...
上午讨论高温防雷呼出计划的脚本，原本是通过服务台人工为客户提供一次预防性的呼出。但后来决定采用系统具备的短消息功能，以文本的方式发送到门店。这样，不仅可以节省成本，而且也减少了服务台的工作负荷。短消息的字数有限制，250字节，125个汉字。如何在这百字之内将我们此次呼出目的涵盖？为此上午专门开了个小会。大家在讨论呼出脚本时，从高温和雷击两个方面总结出两点注意事项。 保持良好通风，尽量避免阳光直射和覆盖。雷雨时和非营业时段可暂时关闭设备，拔去电源和电话线。基于以上两点，开始考虑如何在百字之内控制好表达。在讨论脚本表达时，我提出一点意见：由于面对的客户文化水平差异较大，在写脚本时不能写的过于精炼和专业，该罗唆的地方还是需要罗唆。可是这么一来又会引出字数限制的问题。这个脚本如何写得即通俗又易懂呢？讨论中，我突然想到用一种琅琅上口的顺口溜方式来写脚本会不会达到以上的效果呢？于是谈了自己的...
...么读不了盘？你能过来一下吗？ 客服：是不是盘的问题？ 用户：不是的。 客服：好吧，我过去！ 等客服过去的时候，看了一下，是无法读取，把光驱打开，里面放的是软盘…… 客户的滑稽行为往往会让客服人员哭笑不得。平时私底下我也在很多同行那里听到类似的故事。客户，可以是企业内部其他部门的员工，也可以是社会上众多的芸芸众生；可以是IT达人，也可以是IT盲人。这些都是服务台的话务人员和一线技术支持需要面对和考虑的。接下来我们就需要去解决一个问题：如何用他们听得懂的语言进行技术指导？ 我曾经多次强调过这个问题，但是在实际执行中发现技术维护人员有一个通病：对技术比己高的人比较尊重、佩服，对技术不如自己的人又存在一种不屑。当然这种不屑完全是来自技术上的差距而不是非技术的轻视。他们会对一些很简单的技术问题表现出不耐烦，大有一番“这么简单的问题还来问我&rd...
周五参加了一个部门的例会。会上听了新上任部门主管有关部门管理的改进计划。其中谈到工程师管理并从中引发出对一个问题的思考：未完成的任务是否需要做回访？中心规定：凡外出维护单必须在完成之后，工程师向服务台座席员反馈并由座席员回访用户，询问用户是否对此次的维护满意。这个规定对未完成的任务只要求工程师反馈，不安排座席员回访。这是一个很有意思的规定。直接的效果就是用户满意度基本上维持在100%。用户的特点是即使报修时喊的震天响，但工程师上门并解决了问题，用户一般还是和颜悦色地签上字并表示对工程师的满意。用户满意了，委托我们为这些用户提供IT服务的客户也就满意了。用户满意度是客户考核我们的一个指标。100%的数字完成了一个考核指标，美化了我们的服务报表。也许从满足客户IT服务考核看，以这种方式进行满意度统计无可厚非。但从提升自身IT服务管理的角度来讲，这样的做法其实是在回避矛盾，错过发现问题，改进工作...
服务台（servicedesk），又称为帮助台（helpdesk），是广泛应用于服务性行业或制造业售后服务的服务管理模式。服务台有多方面的优点：1、构建快速响应客户服务请求的服务中心2、服务模式的构建成本比较低，总体服务的效果和投入产出比较优3、服务台的模式灵活，集中的、分布的、虚拟的方式都可以4、可以提供一致的标准化服务，规范服务5、信息技术的有力支撑，使服务知识可以复制、重用，服务水平和服务质量快速提升服务台模式目前已经在银行、保险、电信、邮政、政府热线、公众服务平台、物业管理等等领域得到广泛应用，并正在影响到其他行业。随着人们生活质量的提升，处理要求高质量的产品，对售后服务质量也提出了高要求。比如电视、空调、汽车、大型生产设备等等，这些耐用品的消费是一个长期的过程，在消费过程中产品出现故障或者使用者需要培训支持，都需要服务部门提供支持，服务台管理模式正是集中资源满足客户服务请求的最好...
回想3年前刚到客户服务部的时候，IT运维模式业务简单，800电话还没有使用，一部电话就连接起用户和服务提供者。在了解客户服务部的发展之后，发现这一部电话也是用户日益觉醒的服务意识使然。我们做IT运维也因用户的挑剔体现出自己的价值。最初的服务台模式见图1。这图其实是合并处理之后的效果。POS机软硬件的运维在地理位置上是分在两个地方，电话也是两部，各自有调度人员受理问题、安排任务。因为道理一样，所以我就将其归在一个结构下面便于说明。 图1 这种模式如果非用ITIL来套可以将其看作是专业型服务台。受理用户报修并安排任务的人都曾是具有丰富经验的工程师。他们在解决用户问题时，真正具备过滤器的作用。他们可以直接调用工程师上门。速度很快，效果也高。随着公司业务的发展，IT运维也相应做了调整。成立客户服务中心真正实现IT运维响应的物理统一。如图2所示，IT运维流程细化清晰。800电...
IT服务，我们都在讨论的是IT对外服务。服务请求也是针对客户或者是用户。今天早上服务台主管问了我一个问题：一线工程师的疑难问题是否也要通过服务台汇报？我们讨论了一会。目前要求任何对外的联系都由服务台受理，然后转接。现在遇到2个问题：1、服务请求没有将工程师的要求纳入，工程师遇到配件不合格或者配件带错的情况究竟是给服务台打电话寻求帮助，还是越过服务台直接给任务调度（负责分配任务和调度人手）打电话寻求帮助？2、如果将工程师的要求也纳入服务请求，作为内部的服务请求同样走服务台受理、转接的流程，那么会存在效率上的问题。这里涉及到的问题可以分两个方面来看：一个是服务请求的识别；一个是局部的效率和整体的效率平衡。讨论这些话题不能脱离具体的背景：服务台人数不足，没有合适的计算机工具支持。服务请求的识别不存在困难，以前没有更深入地考虑过，现在可以将此事拿出来具体分类并设计出具体的处理流程。最大的问题是如何...
