服务请求管理

基础要点：

1.以有效且用户友好的方式，处理那些预定义的、用户发起的服务请求，以保障约定的服务质量。

2.请求的类别包括：

（1）交付类操作，如提交报告或更换墨盒。

（2）信息请求，如创建某个文档或询问营业时间。

（3）资源请求，如提供电话、电脑给用户，或提供虚拟机给研发团队。

（4）访问请求，如访问某个文件或文件夹。

（5）反馈，如抱怨使用界面或点赞支持团队。

3.作为访问交付的正常部分，服务请求的处理需要有明确、标准的启动、批准、执行和管理的流程。

4.对于一些需要财务或安全授权的请求，应遵循标准化、自动化、简单化的原则，设定交付时间，以及按需转入事件与变更管理流程。

5.通过精心的流程设计和自动化的工具跟踪，在尽量利用现有工作流的基础上，保障新加入的服务目录请求不但高效而且具有可维护性。

解读：

从定义上来说，此类管理实践要求：服务提供方能够根据服务目录，履行SLA 中所定义的具体服务内容，以及相应的级别。

而从服务请求的过程来看，最终用户通常会从自助式服务门户的服务目录中，通过检索与查询直接提交电子邮件请求；或是通过电话求助，告知服务台手工记录下所需的服务请求。

因此，服务请求一旦产生，则会通过人工或自动化的识别与映射方式流转到后台。后台相关的职能人员或进程，应及时履行审阅与批准的职责，进而直接交付服务，或跟踪与反馈请求受理的整个过程。

除了上述基础要点中所提及的细分类别之外，用户也会经常以服务请求的形式，向服务提供方传递如下类别的信息与诉求：

1.故障申告。即：因无法获取现有的服务，而告知服务台错误信息，并申请技术帮助。对于此类请求，一般需要服务台启用事故管理流程。

2.服务咨询。即：如何获取现有的服务，或是如何进行下一步操作。此类问题相对较为简单，服务台可以一次性予以处理。当然，为了提高解决的效率，我们应当向服务台提供尽可能与用户相同的视图界面，以及完整的判断流程。

3.超时投诉。即：抱怨现有服务的交付质量及响应超时等方面。此时，服务台需要安抚用户的情绪，详细记录诉求，上报并转呈相关职能部门，并及时给出合理的补救措施。

当然，那些由最终用户提交上来的服务请求，有时候也会存在着表述不清，甚至是类别或属性错配的情况。那么，此时就需要服务台及时根据现有的服务目录，对该请求进行调整、更新、甚至是驳回请求并留下相应的表述，以方便用户重新填写，或判断请求的合理性。

可见，我们需要保留与各种服务请求相关的有效记录，进而达到：

及时跟进、并报告服务响应的进展情况；

便于衡量、并在日后改进现有的需求处置流程；

向其他管理流程（如事故管理、问题管理，以及变更管理等）提供第一手的参考信息，以体现业务专业价值。

总的说来，服务请求管理的目标就是要在控制好成本的基础上，保障服务的顺畅交付，并让请求者满意。因此，作为请求方和服务资源方的中间桥梁，服务台需要根据接受过的培训及相关的业务知识，对请求进行及时的受理、过滤、分类、转发、跟踪、以及反馈。

实务：

在企业的实际运营过程中，我们一般不会把服务请求管理列为单独的管理流程，而是将其融入服务台、服务级别管理，以及变更管理之中。

另外，除了在上述解读环节所提到的对于现有服务的请求进行有效的治理之外，我们对于那些新的服务请求也实施了合理的管控。其中包括：

1.重要程度。即：结合实际业务，判断需求的重要性和紧迫性。

2.实现难度。即：根据现有的资源，来界定其可行性。

3.所需成本。即：综合考虑前期的开发、测试与购置成本，以及交付后的运营与维护成本。

通过上述维度的分析，我们需要作出如下判断：

对于不具备可行性的请求，应当向提出方“摆事实，讲道理”，有理有节地予以回绝。

对于可行性较低的请求，可以尽量寻求折中或替代方案，与提出方进一步沟通。

对于切实可行的请求，则需要分类、分级、分期实施。

也就是说：我们对需求按照业务领域进行分类；在重要性与紧迫度上进行分级；根据现有资源和交付难度分阶段予以实施。

为此，我们经常会根据某些新的服务需求，成立专项分析小组，让具备业务专业能力和IT 技术背景的人员参与进来。他们各显所长，全面解析、确认、研究对于新服务的需求，通过明确规划，切实设计，逐步推进，以及协调测试，在基本满足提出方的基础上，实现新服务的最终落地。