SHEC客户服务人员使用手册Word下载.docx
- 文档编号:17815877
- 上传时间:2022-12-10
- 格式:DOCX
- 页数:39
- 大小:633.90KB
SHEC客户服务人员使用手册Word下载.docx
《SHEC客户服务人员使用手册Word下载.docx》由会员分享,可在线阅读,更多相关《SHEC客户服务人员使用手册Word下载.docx(39页珍藏版)》请在冰豆网上搜索。
Nopreviousdocument
11-Dec-10
2
查阅人
Name
Position
分发
CopyNo.
Location
1
LibraryMaster
ProjectLibrary
2
ProjectManager
3
4
(9-Dec-96)
(9-Dec-96)
文档说明
文档简介
本文档为上海日立电器有限公司(以下简称上海日立)实施OracleSupport的客户服务人员(包括服务经理)的用户使用手册。
服务请求是Oracle服务流程的主线,文档介绍了这一核心概念及主要字段的意义和用途,说明了服务请求的基本处理流程及详细操作过程。
客户服务经理可以根据客户提出的服务请求创建和分配任务,文档详细介绍了任务的创建和分配步骤。
文档还介绍了知识库的使用和丰富完善方法以及客户服务人员如何查看和访问自己的服务请求和任务。
本文档可用于客户服务人员的系统培训,亦可作为客户服务人员学习系统的参考使用手册。
格式说明
为叙述方便,对本文中使用的有关格式,作如下说明:
(T):
表示页面上的标签
(M):
表示菜单
【按钮】:
表示web页面上的按钮
超级链接:
表示web页面上的超级链接,点击该超级链接,可查看更详细信息
参考文档
参考文档:
SHECiSupport普通用户手册.doc
SHEC知识库管理员使用手册.doc
Chapter
1OracleSupport基础
本
章将简要介绍了OracleSupport的主要功能以及服务请求的基本处理流程和责任划分,使用户能建立服务请求、任务、知识库、产品安装信息等基本概念。
本章内容包括
●OracleSupport功能概述
●服务的基本流程及责任划分
Note:
Usethissectiontodivideyourdocumentintochapters.
ThechapternumberaboveisaWordSequencefieldthatautomaticallyupdatestoreflectthecorrectchapternumberwhenyouhavemultiplechaptersinyourdocument.
Alsoconsiderdividingyourdocumentintosectionsbyinsertingasectionbreakbeforeeachchapter.Youcanalsoincludethecurrentchapternumberincaptionsandpagenumbersusingbyinsertingafield(Insert->
Field_)withthecontents:
SeqChapter\c
Formoreinformation,searchfor“Sequence”inWordforWindowshelp.
OracleSupport功能概述
Oracle服务套件的根本目的,就是要使服务商能利用各种渠道,如电话、e-mail、或网络接受客户的服务需求,并为之提供快速满意的服务,以密切服务商和客户之间的关系,提高客户的满意度和忠诚度,获取更多的客户价值。
为了充分发挥客户的能动性和主动性,Oracle开发了iSupport,这是一个基于网络的自服务产品,客户可以利用它提交服务请求,查看自己的帐户信息,搜索知识库,查询维护自己的产品信息,参与在线论坛等。
这是一个与后台处理及ERP系统紧密集成的自服务环境,客户显得非常积极主动,可以获得全面的最新的信息。
但是客户利用iSupport提出服务请求后,需要服务方的客户服务人员进行处理,给客户满意的答复。
OracleSupport就是这样一个供客户服务人员使用的基本支持平台,利用这个平台客户服务人员可以查看和输入服务请求(因为有些客户习惯于用电话或e-mail等方式提交他们的请求),查看自己的任务,汇报服务的过程和结果。
客户服务经理除了普通客户服务人员的职能外,还需要针对客户服务请求创建和分配任务,以组织对客户的服务。
客户服务人员在服务过程中都可以搜索知识库、查看客户产品信息,以辅助完成相应的任务。
服务的基本流程及责任划分
客户的服务请求是服务流程的起源,也是贯穿于整个服务流程的主线。
因为服务流程总是基于客户的服务需要开始的,而整个服务的过程就是围绕解决客户问题进行的。
一个基本的服务流程一般有以下分以下几步:
1.提交服务请求
提交服务请求有两种方式,一是客户自己通过iSupport在网上提交,另一种是客户打电话或e-mail方式与客户服务人员联系,由服务人员提交。
在提交服务请求之前或提交的过程中,可以搜索知识库,搜索与服务请求相关的问题的解决方法,如果解决方法可以解决客户问题,那就可以不提交服务请求或者关闭服务请求。
值得说明的是,服务请求并不一定都是客户的问题,公司的内部员工也可提交请求,以寻求其它人员的帮助。
2.查询服务请求
客户提交服务请求后,应该有人负责处理,即相应的责任人。
因此系统提供各种搜索标准,以便客户服务人员方便地查询自己负责的或关心的服务请求。
如果服务请求与客户购买的产品相关,服务人员可以查看到客户产品信息(由产品安装信息库维护),并需要判断该服务请求是否在产品的服务协议范围内。
3.创建和分配任务
服务请求的责任人查看到自己负责的服务请求后,一般情况下,都需要针对具体的服务请求内容,派不同的人去处理,即创建和分配任务,对复杂的情况,可能一个服务请求需要创建一系列的任务,派相关的人才能完成。
4.查看和执行任务
为服务人员分配任务后,必须通知服务人员本人,服务人员收到通知后,查看任务并完成相应的任务。
在完成任务的过程中,服务人员可能会与客户不停的交互,或者面对面的交流,一起工作才能完成。
如果交流是通过网络完成,服务人员需要把任务进行过程中的进展情况输入系统,便于客户查看和反馈。
任务完成后,服务人员需要向客户提交解决方案和结果。
5.关闭服务请求
任务完成后,如果客户认可,即可关闭服务请求,如果用iSupport客户可以自己关闭,如果服务请求已完成,或者很久没有响应,也可以由服务人员关闭。
以上流程的各个阶段,是由不同的人完成的,他们在服务流程中的工作性质和作用是不同的,所有系统赋予的权限也是不同的。
我们把这些不同性质的工作单元称为责任,不同的人可能有不同的责任,同一个人也可拥有几种责任。
根据日立的实际情况,将服务人员的责任分为
1.SHEC客户服务人员
客户服务人员可以创建和查看服务请求,查看通知,查看自己的任务,搜索知识库等。
日立公司品证部、营技部、营业所的普通工作人员分配此责任。
2.SHEC客户服务经理
除SHEC客户服务人员责任拥有的权限外,还可以创建和分配任务。
日立公司品证部、营技部、营业所的部门经理和客户服务的负责人分配此责任。
3.SHEC客户服务管理员
全面管理客户服务的各个方面,包括服务请求管理、任务管理、资源管理、升级管理、知识库管理、产品安装信息库管理、系统设置等。
日立公司市场部综合管理科负责客户服务的人员可分配此责任。
4.SHEC知识库管理员
负责知识库的创建与维护,可派专门人员负责。
5.SHEC产品安装信息库维护员
负责录入和维护客户的产品信息,可让专人负责。
2服务请求
章介绍服务请求的基本概念和主要字段及其意义,服务请求的基本使用,包括服务请求的创建、知识库的使用、联系人和日志查看等。
本章内容包括:
∙服务请求基础
Ø
什么是服务请求
服务请求的主要字段
∙服务请求使用
服务请求页面简介
创建服务请求
为服务请求添加附注
搜索知识库
从服务请求将新的解决方法添加到知识库中
查看服务请求的日志
管理服务请求联系人信息
将服务请求与其它文档相关联
搜索服务请求
升级服务请求
关闭服务请求
服务请求基础
服务请求是客户要求服务的起点,也是贯穿于整个服务流程的主线,因此理解服务请求的概念和系统描述方法,并清楚其在服务过程中的变化是非常重要的。
什么是服务请求?
我们不妨回顾一下客户服务的实际过程。
对一个运行较为规范的企业。
当客户遇到问题时,比如产品质量问题,使用问题等,企业总会提供某些渠道,比如热线电话、E_mail,网站等为客户提供服务。
服务请求是指客户提出的一切需要厂商解答的问题和需要的服务,包括售前、售中、售后的。
以热线电话为例,当客户服务人员接到客户电话的时候,也就意味着一个服务请求的开始。
一般情况下,客户服务人员会提出如下问题让客户逐个做答。
⏹先生/女士贵姓,叫什么名字?
⏹是那个单位的?
⏹有什么问题需要帮忙的?
⏹客户在回答问题的过程中,可能会提到其它信息,比如产品、问题的急切程度等。
客户对这些问题的回答实际上就构成了客户服务请求的各个要素。
我们知道,数据库的基本思想就是要把事物概括为一条条的记录,再细分为具有不同属性的字段,这样才能进行方便的存储和操作。
同样的,系统中就将客户服务请求分解成一个个不同类型的字段。
服务请求的主要字段
呼叫人信息
第一个问题的回答实际上给出了呼叫人的姓名,显然呼叫人可能是以下三人员之一
⏹客户公司的业务人员(B2B)
⏹个人客户(B2C)
⏹本公司的员工
显然对于不同类型的联系人我们想知道的信息也是不同的,需要区分对待,系统根据这种业务需求,也相应的建立了三种呼叫人类型,即
⏹组织
⏹个人
⏹员工
以分别对应前面的三种情况。
对于组织类型的公司,除了呼叫人的个人信息外,还有公司的信息,包括公司名、帐户、联系人等。
如果系统中已经有呼叫人的信息,系统会自动调出相关的信息,如果系统中没有,系统可以创建之,这是很自然的做法。
但是此处创建的客户不会进入应收的客户信息,这是非常符合逻辑的事情,此处的客户只想得到服务,如果为其分配帐户,显然超越服务人员的权限,出于安全的考虑,分配帐户应当慎重些。
呼叫人除了有自己的联系方式外,还可以为之设定联系人,以便呼叫人联系不方便时备用。
联系人必须首先在系统中已经有定义,如果没有,可以先定义,联系人有两种类型,即
⏹关系
汇总和附注
第三个问题的回答显然是很关键的,它说明了是一个什么样的问题,如果问题很简单,就可以用一句话概括,如果问题比较复杂,一句话可能说不清楚,但也能用一句话概括其主要意思,然后对这个问题进行详细说明,这是非常符合人的思维方式和表达习惯的。
这一句概括的话,系统中称之为“汇总”,它实际上服务请求的概括,我们可以把它理解成服务请求的标题。
而详细的说明系统用“附注”来实现,“附注”实际上就是一条条的自由文本,附注是一个非常有用的工具,我们会经常用到。
为了更清楚地区别一条条的附注,我们可以对附注进行分类,以区分其性质和用途,系统中称为“附注类型”,它是用户可以定义的。
对附注进行分类,这样对附注的性质就会一目了然,以便于进一步的统计分析。
在服务过程中,我们可以为服务请求不停地添加附注,以记录服务过程中的相关信息和服务过程。
在系统中,可能许多用户都有访问服务请求的权限,但是有时候某些附注只希望自己能看,有些只希望内部人员看,针对这种业务需求,系统为附注增加了状态控制,它实际上是附注访问权限的控制,可针对每一条附注进行定义,共有三种,即
⏹共享:
只要能访问服务请求,就可见该附注
⏹内部:
该附注只能员工类型的用户才能看到
⏹个人:
该附注只能添加附注的才能看到
附注的修改权限与可见权限是一样的,即可看到,就能修改。
缺省的权限为共享,即所有员工类型的用户都能看到和修改。
产品
在客户描述问题的过程中,如果问题是与产品相关的,首先就会提到。
产品与问题有以下三种可能
⏹问题与产品无关
⏹问题与产品相关,但用户本身并没有购买该产品,这种需求出现在客户对产品本身感兴趣,但还没有购买的情况下
⏹问题与用户已经购买的产品相关,这种情形出现在客户已经购买的产品出现了某些问题,希望得到帮助和服务的情况下
所以在服务请求中,产品的信息是可有可无的,也就是说可选的。
如果选择产品,显然产品应该在系统中已有定义,而且分两种情况,如果用户没有购买该产品,应该在系统中已经定义的项目(Item),都可以选取,而如果是最后一种情况,应该在产品安装信息库中选择。
产品安装信息库也是ServiceCore的模块之一,它跟踪了客户购买产品后,在产品使用过程中的相关信息。
在系统中提供了产品安装信息库的复选框,以满足后两种业务需要,当你勾上了产品安装信息库这一选项时,就只能从产品安装信息库中选择产品了,而一旦从产品安装信息库选择了产品,其相关的信息就将在产品服务范围标签中显示出来。
例如如果客户购买产品时,已经和厂商签订了服务合同,相关的合同信息也将显示出来,当然也可以增加新的合同,因为在服务过程中可能签订新的合同。
紧急程度和重要程度
在客户描述问题的过程中,可能会表现得非常焦急,或者特意嘱咐希望什么时候解决,这实际上表明了服务请求的另外一个属性,系统中称为“紧急程度”,它是从客户的角度来看待服务请求的重要性。
但是客户都希望自己的问题尽快得到解答,所以有夸大的嫌疑,我们不能完全按客户的意志来进行衡量,我们必须有自己的衡量标准,系统中称为“重要程度”,紧急程度和重要程度的级别都是可以设置的,而且可以用不同的颜色来表示。
责任人
要想把一个服务请求描述清楚,光有以上信息显然是不够的,对企业而言,最起码应该记录是谁负责出来这个服务请求,即“责任人”,责任人是一个广义的概念,系统中定义的资源类型都可以成为责任人,资源是在资源管理器中定义和从人力资源模块导入的,它可分为
⏹员工资源
⏹组资源
⏹小组资源
三种类型,选择了类型后,显然只能选取相应的资源。
请求类型和状态
为了总体上区分服务请求的性质和进一步的统计分析,系统中定义了“服务请求类型”,以对服务请求进行分类。
服务请求类型可以根据企业的实际请求进行定义。
而为了区分服务请求的不同阶段,系统定义了“服务请求状态”,这是一个重要的参数,通过这个字段,客户和厂商在查询的时候,就能清楚地知道服务请求处于什么样的阶段,接下来该做什么。
以下是一些常用的服务请求状态
⏹打开:
说明该服务请求刚提交,尚未被处理
⏹被指定:
说明该服务请求已分配给相应资源负责
⏹处理中:
说明该服务请求已分配任务,正在处理过程中
⏹已关闭:
说明该服务请求已经完成,或者超过期限被强行关闭
用户可以根据实际业务需要定义相应的服务请求状态。
事实上,由于服务请求状态可以分得很细,并不是所有类型都与所以的状态状态相关,比如“索取资料”这类的服务请求不可能经历“产品测试”这样的状态,我们可以为每种类型的服务请求指定相应的状态组,这样这种类型的服务请求就只能经历在指定状态组中的状态,这也使得服务请求的分类显得更有意义。
缺省情况下,如果不为服务请求类型指定相关的状态,默认可以使用所有的状态。
不同类型的服务请求处理的业务流程可能是很不相同的,系统中可以为不同类型的服务请求指定相应的预先好的工作流,这样不但可以对不同类型的服务请求进行分别处理,而且可以实现业务流程的自动化。
这样不但可以满足实际业务的要求,而且可以充分发挥计算机管理系统的自动化功能。
在实际业务中,服务请求的某些状态变更可能需要具有某种职责的人才能做,比如,在处理产品维修这类服务请求时,“产品测试”到“测试合格”的状态转变只能有测试的技术人员来完成,因为这需要完成相应的动作并确认。
系统中可以为状态的转变定义规则,并将规则的使用权赋予一定的职责,就达到以上的业务目的。
问题代码和解决方法代码
在实际服务中,有些问题用语言描述很困难,或者很麻烦,而有些问题却经常出现,人们希望有简单的代码来描述,为了满足这样的业务需求,系统提供了问题代码和解决方法代码,以方便表达和使用。
在企业中,有许多企业内部员工都清楚的“内部语言”或“行话”,如果是描述问题和解决方法的都可以定义成问题代码和解决方法代码。
服务请求编号
用系统提供的以上字段,基本上就能比较全面的把客户请求定义清楚了,当用户保存这条服务请求时,系统会自动产生一个服务请求编号,它是服务请求的唯一标志,是服务请求的主关键字,不同的服务请求就是利用这个编号来区分的。
日志
为了跟踪和记录服务请求的变更过程,系统自动产生日志文件记录服务请求的变化过程,包括附注的添加和改变,状态的改变等等,从日志文件我们可以很好地了解服务请求处理的过程,包括每一项内容改变的时间和内容。
总结
由以上的分析介绍,我们可以看出服务请求的每一个字段都是从实际的业务中归纳、整理和抽象出来的,也是符合实际业务需要的。
下面对服务请求的各个字段做一总结:
首先,服务请求肯定是某个人提出的,我们成为“呼叫人”,呼叫人可能有三种类型,即B2B客户的联系人,B2C客户和厂商的内部员工,如果呼叫人已在系统中存在,我们可以调出其相关信息,如果没有可以在系统中输入。
另外如果Oracle产品与呼叫中心集成,系统可根据呼叫人的呼叫电话等自动识别其身份,并调出相关的信息。
服务请求的内容可能比较简单,也可能比较复杂,我们可用“汇总”和“附注”很好地描述服务请求的内容,我们还可以利用“问题代码”来更简练地描述问题。
如果已经实施Oracle脚本模块,在客户描述问题的过程中,客户服务人员可以利用脚本程序提出问题,根据客户的回答引导客户对问题的描述。
可用“服务请求类型”来区分服务请求的性质,并可以针对每种服务请求类型定义不同的工作流实现分别处理和自动化。
可用“服务请求紧急程度”和“服务请求重要程度”来从客户和服务人员的角度对服务请求的急切程度和重要性进行评价,根据它们的级别可以进行不同优先级的处理。
为了描述服务请求的不同阶段,我们引入“服务请求状态”字段,根据服务请求状态的改变我们能清楚地知道服务请求在整个服务请求流程中的阶段以及下一阶段应该进行的工作。
我们还可以对不同类型的服务请求指定不同的状态组,以剔除多的状态,更好地反映实际业务情况,而对于不同状态之间的转变我们可以定义转换的规则,并指定相应的职责,以限制服务请求状态变化的过程和权限,以规范业务流程。
服务请求可能是与产品相关的,也可能是与产品无关的,与产品相关的情况下,有可能客户并没有购买产品,而只是对产品感兴趣,因此此时应该可以选择系统中所有定义的项目,而如果服务请求是与客户已购买的相关的,我们就只能从客户的产品安装信息库中选择产品,系统能很好地满足这种需求。
每个服务请求都应该有专人负责,系统中称这个人为责任人,责任人可以是员工、组、小组三种类型,他们都应该是厂商的内部资源。
在以上字段中有些字段是必须输入的,比如“汇总”、“请求类别”、“紧急程度”、“重要程度”、“状态”、“责任人”等,因为这些字段是服务请求的基本信息,是不可或缺的。
而有些字段,比如“产品信息”、“联系人”、“附注”等是可选的,因为对服务请求而言,它们并非必不可少。
对于“请求类别”、“紧急程度”、“重要程度”、“状态”、“责任人”等可以通过预置文件设定默认值。
信息输入完毕后,在保存服务请求时,系统会自动产生一个服务请求编号,它是服务请求的主关键字,在系统中的唯一性标志,因为服务请求的其它字段都可能完全相同。
为了对服务请求的处理过程进行跟踪和记录,除了服务请求状态的改变之外,可以用附注对服务请求的过程进行记录,为了限制附注的访问和修改权限,系统给出了三种附注状态来实现。
在服务请求的处理过程中,系统还能自动生成日志文件来记录每一个动作的时间和内容。
通过系统的这些字段和工具显然不但能很好地描述服务请求的问题本身,还能跟踪服务请求的处理过程,能很好地满足实际业务的需要。
值得说明的是,在Oracle产品家族中,为服务请求的提交提供了多种入口,用户可以利用iSupport提供的Web界面自己提交服务请求,也可以通过电话、传真、电子邮件等方式,在客户服务人员的帮助下提交服务请求。
但是如果用户已经实施iSupport模块,我们推荐并鼓励客户使用iSupport提交产品,这样不但能激发客户的积极性和主动性,还能减少客户服务人员的数量,降低客户成本。
服务请求使用
服务请求页面简介
路径:
服务请求->
创建服务请求
服务请求页面包括八个子标签,服务人员可以利用相应的标签访问与服务请求相关的内容信息或管理服务请求的处理流程。
如访问客户信息、问题详细信息、问题解决方案、服务历史信息等,可以为服务请求创建和分配任务。
以下是服务请求的各个子标签及主要功能描述
产品服务范围查看和更新产品属性
工作台输入问题描述及各类附注信息
查看回复日期和期望解决日期
日志查看服务请求生命周期内各种事件的历史信息
联系人查看和更新联系人信息
地址查看和更新客户安装地址,收单方地址,收货方地址
任务查看和分配与服务请求相关的任务
交往查看客户交往历史
相关单据查看和关联与该服务请求相关的服务请求
创建服务请求->
工作台(T)
1.打开创建服务请求窗口
2.选择呼叫人类型和名称等详细信息
3.如果问题与客户产品相关,请选择“产品安装信息”选项。
如果选择了该选项,产品值列表将仅显示客户拥有的产品,否则显示所有库存项目。
注意,系统字段和参考号字段仅仅在选择“产品安装信息”选项时才可用
4.选择一个产品和产品的序列号。
此时系统将显示详细的产品信息,单击产品服务范围标签查看详细的产品及服务服务信息
5.责任人类型、责任人、请求类型、重要程度、状态等字段的默认值都是由客户配置文件定义的。
如果需要,你可以改变这些值默认值
6.单击工作台标签,在汇总字段中输入一个问题的简短说明,这个字段是必须输的
7.选择输入紧急程度、问题代码、解决方法代码。
为了客户跟踪方便,可输入联系人提供的后援服务编号
8.“回应人”(应译为回应时间)的默认值是由与客户签订的合同决定的,如果呼叫人提出希望解决的时间现制,将此时间输入“解决方法依据”(应译为解决时间)字段
9.保存服务请求。
系统将产生一个服务请求编号,这个编号是服务请求在数据库中的唯一编号,记住这个编号,以便于查询。
为服务请求添加附注
创
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SHEC 客户 服务人员 使用手册
![提示](https://static.bdocx.com/images/bang_tan.gif)