不能简单看待这些服务台设计方案（ITSS标准）分歧意见
20150521MONICAZHANG
续上
1，对于王中军提到的手机号码作为公告手段，维护这些手机号码就要很多工作量，经常会发生换号，或者相关人员已经离职这些情况。手机号码作为公告渠道只能适用于小范围，不能适合做全面推广；ISO20000培训
2、服务台工作内容涉及到各个科室，如何做好培训和知识库管理，希望能给出解决方案；在设计过程中，针对培训给出了指导建议，比如“培训计划”、“培训管理制度”等，在实际运营中，服务台管理者需要根据运营中心的实际情况建立培训机制；
3、对于坐席人数的估算，不能光从电话量去考虑，同时也要考虑服务的内容；这是一个指导性的估算值，是参照最佳实践和同行业运营中心服务台经验，在实际运作过程中，需要根据业务特性等做相应的调整；ITIL培训
2009-7-1319:51:04刘震1，现有科室之间需要协同的工作，是否也需要通过服务台来派发工单？例如系统补丁升级工作，发起方是系统室，协助方是其它各室，是否可以借助服务台进行工单分配、跟踪和考核？运营中心服务台主要执行的是内外部接口，对于运营中心内部的自发的单子不走服务台，只需要内部科室直接在流程管理平台上开工单，如果需要协同完成，则在主单上开各个子单，通过系统派发给相关科室协同处理；ITSS培训
2，监控人员和服务台之间如何进行工作划分？监控人员发现的事件是否需要反馈给服务台？那些需要反馈给服务台？监控人员和服务台各施其职，监控人员发现的事件不需要通知给服务台，监控人员可以在流程管理平台上直接开单，并自行或自动分派给相应的处理人或处理组；
2009-7-1317:57:55王中军1，服务台可能包含职能、流程平台、组织架构等多重含义，在文中也有几种用法，建议有所区别，以免造成混淆。所以，我们在设计之初就有专门章节对服务台进行明确定义；ITSS认证
2，没有单独的服务请求管理（响应、支持）流程？在流程优化设计中会设计服务请求管理流程；
3，服务台的管理制度建议和项目建议的政策体系架构保持一致。基本保持一致，同时在保持一致政策框架下，服务台需要一些具体的管理制度和工作纪律以保证服务质量；ITSS体系
4，预处理环节的引入会不会降低服务的时效性？有没有更好的办法在保证信息准确完整的同时提高效率？从整个运营中心的运作来说，预处理可以增加服务的时效性，很多预处理工作是需要客户提供完整的授权、完整的信息、以及澄清服务请求的确定性，这些都是处理一个服务请求的必须工作，但又是常规性、标准化操作，如果把这些工作漏到二线，会增加二线很多工作负担，同时也无法保证二线对其它请求的及时处理；
5，通过Email和邮件提出的服务请求建议也能够自动转入平台。如果将通过Email提出的服务请求自动转入平台，则对客户在通过Email提出请求时的格式等有具体要求，一定程度上给客户带来不便。建议如果服务台运行正常，客户成熟的状态下再做这种要求；ITSS软件
6，在考核报表中有些呼叫是先前服务请求的后继动作，是否也应有所体现？在设计中有建议服务台一线坐席开单时，对于已经完结的服务请求单，如果客户又有新的要求或对前期处理有意见，需要再次处理，则建议重新开单。其中考虑的因素之一就是为了考核更准确；ITSS考试
7，服务台运营层次图中建议淡化“专家座席工程师”的IT色彩。我们设计的服务台是整个运营中心的服务台，它的职能会综合业务和IT，所以在整个设计过程还是站在运营的角度；
8，服务台值班长每岗1人，意思就是每个班次1人吧？笔误，应该是每班1人，已经修正；ITSS团购
9，事件单协同处理图中分公司事件管理员的职责是什么？对于一个需要中心参与处理的事件单需要另建中心事件单吗？分公司事件管理员主要负责同中心沟通和协调，同时也能保证送到中心的事件的质量，需要中心参与处理的事件单不需要另建事件单，整个体系都运用同一个平台，只需要将事件单的状态做相应的修改即可；
10，服务级别突破的通知如果过时才升级可能太晚了。承担SLA未达成责任的应该是一线还是二线，或有多个二线，应该怎么区分责任？一般最佳实践的做法是做预警，即给突破SLA有个缓冲时间就开始告警升级，SLA是由多个OLA和UC构成，无论是一线和二线都针对OLA进行承诺，在SLA被打破后根据回顾来查看是哪个环节没有履行职责；ITSS工具
待续：http://www.ITILxf.com/thread-48707-1-1.html
本帖关键字：ITSSISO20000
超赞的资料，学习中
页:
[1]