27用户请求管理（服务台）模块
iTop中有两种方式管理用户请求。你可以选择安装下面两种模块的任意一种：
简单工单管理模块提供了一个简单的工单管理系统。它被用来跟踪最终用户的请求。简单工单管理系统包含以下两种类型的请求： - 事件：事件被用来跟踪那些影响了交付服务的意外的问题
- 服务请求：通常用来申请新的服务或特性，比如安装新电脑、创建一个新的邮件地址
这个模块管理一个单一类型的工单中的两种类型的请求。事件和服务请求会遵循相同的流程。它允许坐席轻松地管理任意一种类型的工单并且不需要重新创建就可以重分派一个请求。
ITILV3的用户请求模块主要关注服务请求。 假设你选择安装这个模块并且如果你也需要管理事件的时候，那么你就需要安装事件管理模块。 无论你选择的是哪个模块，一个用户请求都可以通过用户界面或iTop中直接创建。创建完成之后坐席技术人员就可以修改和通过一个叫“公共日志”的日报与客户联系。而坐席可以通过“私有日志”同公司内的内部团队联系。 客户用户只能看到公共日志。私有日志在网站上是看不到的。 一个用户请求由工作流程所控制以确保它可以根据已定义的流程控制。只有被授权的用户才可以管理用户请求并改变其状态。一个用户请求被链接到一个父问题或者一个父变更。假设你安装了一个ITILV3的用户请求模块，那么你的这个请求就可以被链接到一个父事件当中去。 另外，还可以在一个单一用户请求下面重新组合用户的多个请求。 概述控制台允许坐席和坐席的经理去监控桌面支持的动作。
27.1用户请求
用户请求用来记录所有提交了请求的用户。
27.1.1用户请求属性 名称 | | | | | | | | | | 可能值：已审批，已指派，已关闭，升级TTO，升级TTR，新建，挂起，已驳回，已解决，待审批 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 可能值：支援，错误修正，硬件维修，其它，软件打补丁，系统更新，培训 | | | | | | | | | | | | | | | | | | | | | | | | | |
27.1.2选项卡
将显示以下表格：
27.3管理公共&私有日志
公共和私有日志用来追踪所有有关用户请求的沟通以及动作。 公共日志是用来与申请人交换信息的。 私有日志是追踪调查和操作的首先方式：比如，复制/粘贴命令结果，与服务提供商联系的汇总等等。
公共日志和私有日志中的每一条条目都会被追踪到，是由谁更新的以及什么时候完成的。并且这个日志是不能被修改和删除的。 公共日志是在客户页面中可见的。
27.4管理受影响的配置项和联系方式
当创建了一个用户请求后，坐席可以通过“配置项”表单指定这个用户请求关联到哪个配置项。影响度分析引擎会自动添加通过选中的条目中有潜在影响的所有配置项到列表中。同时它还会添加所有有潜在影响的联系方式。
自动影响度分析只有在用户请求第一次被记录时才会启动。稍后，坐席可以从受影响的配置项列表中添加或删除条目：iTop是不会返工工单的更新列表的。
27.5服务目录的依赖性
桌面支持模块链接到服务目录是为了： - 定义了一个给定的用户可以选择哪些服务以及服务子目录
- 定义了一个用户请求可以分配到哪个技术团队
- 计算TTO和TTR的截止时间
只有那些在通过与客户签订的合同上被客户购买的服务才会显示在这个服务列表上。这个列表只显示那些所选择的服务和请求类型所对应的服务子目录。以下的图片描述了服务目录元素和用户请求之间的关系。
27.6分配一个服务请求到一个团队和坐席
你能够分配一个用户请求到一个团队的列表由相应的客户交付模式定义。当创建一个用户请求时，坐席需要选择客户组织，然后团队的名单必须是严格限制在客户定义的团队。如果一个团队少了这块，那么客户的交付模式必须进行更新以反映这一需求。请查看关于交付模式的更多信息。 以下图片描述了交付模式和用户请求之间的关系。
27.7自动优先级计算
优先级是自动计算出来的。这个计算是依靠用户请求的影响度和紧急度的。以下的矩阵说明了如何计算优先级。
27.8截止日期计算
为了满足与客户签订的客户协议，iTop会自动计算机TTO和TTR的截止日期。截止日期取决于客户合同中定义好的服务级别协议。基本版本的iTop中没有覆盖这个服务窗口。这个是按照24*7的服务覆盖率来计算的。 只要用户的请求不是暂停或者解决，量化的TTR的时间都会被累积下来。一旦过了TTR的截止日期，这个工单的状态将会自动变为“已升级的TTR” 截止日期的计算取决于： - 对于已选择的服务在客户合同中定义好的服务级别协议
- 服务请求的优先级
- 请求类型
在服务级别目标中定义好的截止日期对应服务级别协议。 在用户请求上的每一次的更改都会计算截止日期。 当TTO/TTR的累积时间达到TTO/TTR截止日期的75%的时候，用户请求将以黄色显示。一旦过了截止日期，颜色将变为红色。 一旦解决了用户请求，截止日期和措施都会保存在用户请求中。这样既可以分析过程中遇到的问题也可以有汇报的用途。 以下信息都会被记录： - TTO截止日期（日期和时间）
- TTO累积时间（秒）
- 超过TTO（是/否）
- TTO溢出（秒）
- TTR截止日期（日期和时间）
- TTR累积时间（秒）
- 超过TTR（是/否）
- TTR溢出（秒）
27.9对用户请求重新分组
对于那些有根源的事件下的用户请求重新分组有时是有用的。比如当一台邮件服务器宕机，有可能有一些用户向你抱怨邮箱不可用了。 为了分组用户请求，需要关联父事件。 如果一个事件是一个用户请求的父事件，那么每当更新了私有日志和公共日志时，iTop都会自动更新子请求的日志。当父事件被解决后，iTop同时也会把子请求标为“已解决”。
27.10用户请求生命周期
| 
转播
分享
淘帖
()
