|
流程详细设计
1)用户问询处理流程
表:用户问询处理流程步骤说明
序号 | 步骤名称 | 责任人 | 用户与服务台人工交互说明 | 使用自动化自助服务 | | | | ·当用户出于任何原因访问服务提供者时,期望得到快速的人工响应。 ·尽管有越来越多的替代和更有效的方法帮助用户,传统的电话支持、电子邮件和走访习惯不可能消失。 ·在纯技术或B2B服务交付环境中,人工交互也能使人产生同理心和安慰。 ·除了自动化支持之外,任何抵达服务台客服的问询都应以礼貌和标准的方式满足这样用户就可以感受到一定质量级别的服务,表明其问询受到服务提供者的欢迎。 ·每个交互都必须被记录下来 需要设计激励机制鼓励服务台客服记录问询信息。保存的记录是服务质量的宝贵数据来源,而自动化是实现这一点的关键。 | ·在用户需要人工响应前,可在预处理阶段响应查询,目的是快速解决问题。这些通常称为自服务工具。 例如,当用户呼叫服务台电话号码时,可能会有一个预先录制的问候语,这是称为IVR(交互式语音应答)的自动化系统的一部分。IVR的几个更广泛的功能可以帮助呼入者: √提供用户呼叫原因的分类选项。这既可以自动化问询分类,又可以向问询者建议查询已知解决方案的路径 即将发生的影响用户的变更 √提供自动化参考服务 √确认来电者身份 除此之外,自助服务系统还用于记录问询并向用户提供问询登记的确认。 |
续表 序号 | 步骤名称 | 责任人 | 用户与服务台人工交互说明 | 使用自动化自助服务 | | | | 服务台座席可以在记录问询时执行问询核验。不同的检查适用于不同类型的问询: ·用户是否是他们声称的那个人 ·用户及其组织是否有资格使用指定的服务。这在商业服务提供中尤其重要,如果所要求的服务是收费的,可能存在欺诈 问询的原因是否与所问询的服务有关; 是服务提供者的责任;是否包括在约定的服务水平,等等 ·是否需要传递任何受保护的信息来处理问询,如果需要,是否需要额外的调用者身份检查 虽然一些数据源(如服务目录或身份管理系统)支持这些检查,但服务台座席负责验证问询。 |
·当使用自服务工具自动处理用户与服务提供者间的首次联系时,问询验证的某些方面将实现自动化。 用户和问询的自动验证可以内置到用户旅程中,以增强和自定义,并防止与用户不相关的问题和选项。 例如,若用户在自服务门户中通过了授权和身份验证检查,集成的工具集可以根据服务目录匹配其记录,并根据资格、角色、地理位置、可用库存等向其提供适用的服务产品和功能。 | | | | ·对于服务提供者来说,用户问询的分类意味着对它们进行分类并将它们定向到预定义的价值流。 【注:服务台人员可能参与这些价值流的活动(例如,对事件进行分类,或完成服务请求)】。然而,这些活动属于其他实践的范围,其中服务台代理和工具可能作为资源参与其中。 对一些基本问询进行分类可能会导致服务台坐席在与用户对话的过程中第一次解决这些问题。仔细平衡服务台人员处理用户提出问询的可用性和他们应用技术的能力是很重要的,特别是对于时间密集型任务。 | ·用户问询处理的自动化确保了交互的客观记录。这直接可以用于基本的改进和优化活动,例如估计用户支持的总体需求或计算未解决呼叫的比例。 ·基于前面步骤收集的信息的自动问询分类可以减少在筛选和转交分类上花费的人力和时间。 ●使用自动化后,一些问询类型可在无人工交互的情况下解决(例如,分析问询的情景并向 用户建议自助指南或诊断步骤),或者使用最少的人工交互解决。 ·分类工具的界面和工作流程应该提供良好的用户体验,并鼓励用户交流他们的使用。带有不相关或重复问题的复杂设计会阻止用户在将来联系服务台 |
2)与用户沟通流程
表:与用户流程步骤说明
序号 | 步骤名称 | 责任人 | 步骤说明 | | | | ·无论目标受众数量多少,服务台的每次对外交互都必须符合服务提供者所维护的一致的质量标准。 ·问询记录的状态更新也需要仔细设计的对外沟通。根据问询的性质,可以有利益相关者或服务提供者的员工等多个消息接收者,不同的接受者可以设计不同的信息接收模板。大多数情况下,用问询管理和工作流工具将跟踪每个用户问询的接收者,服务台将提供此项功能设计需求输入。 | | | | ·在全渠道范例中,用户应能决定服务提供者应通过哪个渠道交付信息。 ·服务提供者可决定在SLA中包含的用户沟通需求,这时服务台客服应选择适当的渠道。 | | | | ·在自动化服务交付环境中,通常用一组模板生成问询记录生命周期中所有的通知类型。 ·用户问询管理和工作流工具通常与配置和资产管理工具以及其他数据源集成在一起。应该定期验证标准问询通知模板,这样对链接数据源的变更就不会产生空白项,避免消息显得不专业。商业和大规模服务提供商尤其应该避免使用过于复杂和伪个性化的模板。 ·问询记录生命周期更新之外的自定义人工沟通也应以公司模板的形式呈现,并清晰地说明沟通的目的、相关的问询记录和内容。一些服务提供商将组织沟通培训纳入服务台团队发展计划中其他提供商则由服务台经理或其他管理部门批准服务台客服发起对外沟通的策略 | | | | ·通常沟通信息是自动发出的,电子邮件最常用于用户沟通。然而,在一些规范的服务交付环境中,书面沟通或个人访问更为合适。 ·根据用户沟通环境的不同,必须向服务台人员提供明确的指导,说明哪种交付格式适合哪种类型的用户和沟通。例如,终止与公用事业提供商服务契约的问询,需要在处理正常的问询记录的同时,通过快递等更加可靠的方式向客户发送最终账户余额信息。 | | | | “请不要回复此邮件”可以说是一种不完美的做法,但仍广泛采用。即使消息的内容与他们有关,这一行文字也不鼓励大多数用户回复该消息提倡来自用户的反馈。在全渠道范例中,用户应该能够选择任何合法及合理的渠道,尽可能方便地访问服务提供者。 收集和处理反馈还伴随着对某些类型的商业沟通的法定要求,要求来自服务用户的响应以进行后续查询,例如接收者的确认或报价的接受。在这些情况下,服务台客户需要有开放式任务跟踪未回复的请求,并通过不同的沟通渠道联系用户。应该控制不成功尝试的阈值,以避免激怒用户。 |
3)服务台改进流程
表:服务台改进流程步骤说明
序号 | 步骤名称 | 责任人 | 步骤说明 | | | | - 服务台经理与其他相关利益相关者一起对反馈、绩效报告、技术机会和其他相关信息进行回顾。
- 定期(通常是每月或每季度)进行回顾,或者作为对重大事件的反应进行回顾,例如服务台性能偏差、组织变更、重大事件或灾难。
- 回顾的参与者确定了服务台实践改进的机会。
| | | | 根据改进的性质,服务台团队经理: ·根据持续改进实践中定义的程序登记改进计划: √服务台经理负责协调服务台业务范围内的改进 √实践范围以外的改进由相关经理或团队协调;在改进实施过程中,可能会通知或咨询服务台经理。 ·发起变更请求。 | | | | 服务台改进的状态和进展与相关的利益相关者进行沟通。如果改进对用户有影响,则使用与用户沟通的流程来发送更新。 |
流程相关定义
事件管理流程中的各个信息项需获得统一且明确的定义,这是流程相关定义的核心内容。这样做的目的在于实现更优化的记录、流转、分析和回顾事件工单的能力。通过确保所有参与者对信息项具有一致的理解,可以减少沟通的混淆,提高事件处理的效率。明确的定义还有助于数据的分析,从而更准确地反映事件处理的效果,提供持续改进的依据。此外,良好的记录和回顾机制可为未来相似事件的处理提供经验和借鉴,
1)问询工单信息项定义
问询工单用于明确登记问询的信息纬度,确保问询在流转过程中信息一致,增强信息沟通的效率。
表:问询工单信息项
续表
2)问询分类定义
问询分类用于服务台座席初始分类用户问询以便能够快速获取初始解决方案或智能自助服务台引导确定问询的边界。
表:问询分类示例
服务类别 | 服务名称 | 服务项 | 服务对象 | 分类 | 服务渠道 | 服务方式 | 服务级别 | 备注 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
3)服务台响应时限
对于服务台在没有判断出问询属于那种类型的工单前,仅考核响应时间:响应时限指的是工单状态从“待受理”到“处理中”经过的时间;
再判断出是哪一种工单后,按照其他流程要求执行,比如事件、问题、服务请求;
服务台问询响应时间:5分钟(根据具体管理要求设定);
4)用户反馈
用来在问询单中记录用户对问询处理的满意程度。
表:用户反馈定义
编号 | 代码 | 描述 | | | | | | 用户对问询处理结果既非满意也非不满意,处于中间感受 | | | |
5)流程衡量指标
表:服务台流程衡量指标
关键成功因素(CSF) | 衡量指标(KPI) | 指标计算说明 | 考核对象 |
在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进 | | | | | | | | | | | | | | 平均响应时间:累加完成工单的(【事件受理时间】一【用户登记时间】)/完成的事件数量 | | | 数量:在工单单中根据以下条件过滤 【工单登记时间】在统计周期内 | | | | | | 注:对服务台或服务台座席的其他KPI指标,需遵循服务台参与其他流程的要求 |
参考数字化IT运维管理体系建设指南等书籍资料
|