×

扫描二维码登录本站

标签: 服务台

20150521  MONICAZHANG
续上



8、 服务台运作中二线支持团队很重要,从业务服务台试运作的情况来看,二线支持团队的能力明显不足,建议对于二线支持团队的职责及要求进行描述?

有关二线支持团队的要求则放在项目中的流程优化和设计的模块;    ITSS考试


9、 服务台的规则设计,是否可以将从现有情况到未来服务台实现路径进行说明,并说明每一阶段经历的时间?

该文档主要全面设计服务台的完整特征,运营中心可以根据这种指导性设计逐步将服务台功能进行完善和扩充,有关服务台实现路径说明请详见下一个版本;


10、服务台将逐步接手新的服务项目,希望能够对代理服务的程序及要求提出相关办法。

不理解该问题;    ITSS工具


11、对服务台一线坐席人数估算时,业界的两种估算方式,第一种方式建议进一步说明,第二种方式基于电话,但上信的服务台不仅来源于电话,将来可能更多的是来源于Email。

首先这两种算法都是指导性的,服务台一线坐席人数估算还要根据业务类型、客户类型等特点来决定。在第一种方式说明中增加了不建议银联运营中心采用这种方式的简要说明;


12、服务台的建立很大程度上依赖于流程、工具及管理制度,建议能够对于支持的流程、工具提出相应的规划要求。

有关流程在“5相关流程接口设计”中设计,有关工具的要求在“6技术要求设计”中设计;    ITSS团购


2009-7-15 9:03:34  吴素文
1,1.1中的图,没有描述BEM、BSM的位置;

       对于业务管理流程,运营中心平台关注的是统一流程平台同业务流程管理平台的接口,请见图中“流程工具”;


2,1.1中的图中,对于服务台进行了定义:“具备恰当技能的跨地域一二线人员,使用合适的工具,基于准确的信息,按照一定的流程,为客户提供“特定服务”,并确保客户满意”,是否说明本设计文档涉及一、二线人员的工作,其中,一线人员为服务台人员?

为了避免歧义,在图中去掉“二线”,服务台都是一线人员;    ITSS软件


3,关于“5.2问题管理”中,“服务台一线坐席人员可以将每一类事件定期形成报表提交给问题管理流程经理。”是否应该是事件管理流程经理的工作。

事件和问题的流程报表本身应该由相关流程管理人员提供和管理,但是由于服务台在整个运营中心中处于相对独立的位置,所以建议运营中心服务台建设过程中赋予服务台产生报表的职能。报表主要是系统自动产生,主要放在服务台进行管理(如发布等),这样可以保证流程报表的公正性,以及集中处理;    ITSS体系


4,关于“服务台一线专家坐席构成的3种模式”,建议IBM根据对银联现状的调查,给出推荐意见。

由于这4种模式各有利弊(已详细解释),同时,这种人员调整影响面比较大,所以需要银联运营中心相关领导决定;


5,在IBM建议的组织结构中,服务台是否为一个独立的组织?管理岗位只设置一个人员,那么培训、质量等是否均由服务台经理一人承担,如果不是,相应的岗位将设置在哪里?

服务台是运营中心中一个独立的组织,我们建议在服务台一线人员在不超过15个人的时候管理岗位只设置一个人员,将来如果服务台人员扩充,则根据运营实际情况确定是否将其中的管理角色独立设岗。    ITSS认证


2009-7-14 14:14:37  张凉
1,“当紧急事件发生时,运营中心服务台人员需要将信息公告及时发布出去”,建议明确信息公告范围,同时要考察与现有公司的对外公告制度是否存在冲突;

运营中心服务台公告的信息主要限于与运营相关的信息,通过前期调研和考察,这种信息公告管理与银联对外公告制度不存在冲突;


2,针对每一项服务,如果一项服务涉及多个环节,建议对每个环节的处理时间限制即将被打破时进行提醒,而不是等整个一项服务的时间限制被打破时才提醒,这样便于服务台人员进行跟踪;

在相关流程设计时会考虑流程的每个环节处理时限,并且会有相应的提醒机制,同时,服务台人员更加关注的是整个服务被处理的时限,所以要求流程管理平台在设计时需要分别计时并触发提醒;    ITSS培训


3,在技能考核中,服务台解决率和服务台效率是站在服务台整体上还是服务台人员个人上?从描述上看,不应该放在个人考核报表中;

一线解决率是整个服务台的考核指标,也是服务台每个人的考核指标,服务台的总体一线解决率是每个员工的一线解决率集合,所以放在个人考核报表中;


4,在效率考核中,平均应答时间和通话时间依赖于服务请求本身的复杂度,不能单独仅通过时间来考核;

这种时间是平均值,也是指导指标,这种考核主要用于服务台工作量评估,以及服务台一线坐席的横向比较;   ITIL培训


5,短信方式提交服务请求,在验证请求方的真实性上存在一定困难,是否会导致服务质量下降;

短信方式提交服务请求其实存在很多不可控的因素,如:真实性、信息的完整性等,所以在设计时建议尽量不要通过该种渠道提交请求;


6,建议在设计中明确客户的范围,客户的范围不明确,服务台的工作范围和工作内容就不能很好的定义;

在前期讨论的过程中对运营中心面对的客户做了定义,已经增加到修改后的文档中;


2009-7-14 14:14:30  马平清
1,3.3中北信的24小时呼入量估计为5次,在部分分公司前置系统集中到北信后,可能会比这个估计要大;

由于现在没有详细电话呼入记录,所以数据主要通过调研获取,与现实尤其与将来一定存在差异,但是这只是指导性数据,将来如果随着呼入量的增加和变化,服务台人员配额也需要做相应的调整。


2,5.6中知识和案例库由一线专家坐席形成和提交,服务台一线坐席人员使用的同时给予评价,这属于事后评价,在这些知识或案例提交前可否增加一个评审环节,以保证其合规性和正确性,另外对于案例和知识的选择是否也要制定相应的规则。

有关知识和案例库的设计将在专门的模块中体现,在此文档中主要描述服务台与知识和案例库的关系。   ISO20000培训


待续:http://ITIL-foundation.cn/thread-48706-1-1.html

本帖关键字:ITSS ISO20000




上一篇:某ITSS实施项目的workshop关键难点内容展示
下一篇:不能简单看待这些服务台设计方案(ITSS标准)分歧意见
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies
東東 发表于 2020-11-25 15:55:58
超赞的资料,学习中
Powered by ITIL  © 2001-2025
返回顶部