User request management (Service Desk) Module
There are two alternatives for managing user requests in iTop. You can choose to install one of the two following modules:
Simple Ticket Management
User Request Management ITIL V3
The Simple Ticket Management module provides a simplified ticketing system. It is used to keep track of end-users requests. There are two types of request:
Incidents are used to track unexpected issues that have an impact on the delivered services.
Service requests are used to request new services or features like installing a new PC, creating a new email address.
This module manages both types of requests in a single type of ticket. Incidents and service requests will follow the same workflow. This allows agent to easily manage any kind of ticket and reclassify a request without having to create a new one.
The User Request ITIL V3 module focuses on service requests.
Whatever module you choose, a user request can be created via the customer portal or directly in iTop. The support agent can then modify and communicate with the customer via a journal called “Public log.” He can also communicate with internal teams within his company through a journal called “Private log”.
A customer user will see only the public log. The private log cannot be viewed from the portal.
A user request is controled by a workflow in order to make sure it is managed according to a defined process. Only authorized users can manage a user request and change its status.
A user request can be linked to a parent problem, or a parent change. In case you have installed the User Request ITIL V3 module, your request can be linked to a parent incident.
It is also possible to regroup user requests under a single user request.
The overview dashboard allows agents and managers to monitor the helpdesk activity.
User Request Properties
|Organization||Foreign key to a(n) Organization||Yes|
|Caller||Foreign key to a(n) Person||Yes|
|Status||Possible values: Approved, Assigned, Closed, Escalated TTO, Escalated TTR, New, Pending, Rejected, Resolved, Waiting for approval||Yes|
|Origin||Possible values: mail, monitoring, phone, portal||No|
|Description||Multiline character string||Yes|
|Service||Foreign key to a(n) Service||No|
|Service subcategory||Foreign key to a(n) Service Subcategory||No|
|Hot Flag||Possible values: No, Yes||No|
|Hot reason||Alphanumeric string||No|
|Pending reason||Multiline character string||No|
|Request Type||Possible values: Incident, Service request||No|
|Impact||Possible values: A department, A service, A person||Yes|
|Urgency||Possible values: critical, high, medium, low||Yes|
|Priority||Possible values: critical, high, medium, low||Yes|
|Team||Foreign key to a(n) Team||No|
|Agent||Foreign key to a(n) Person||No|
|Approver||Foreign key to a(n) Person||No|
|Start date||Date and time (year-month-day hh:mm:ss)||No|
|Last update||Date and time (year-month-day hh:mm:ss)||No|
|Assignment date||Date and time (year-month-day hh:mm:ss)||No|
|TTO Deadline||Core:AttributeStopWatch+ (100_deadline)||No|
|TTR Deadline||Core:AttributeStopWatch+ (100_deadline)||No|
|Last pending date||Date and time (year-month-day hh:mm:ss)||No|
|Resolution date||Date and time (year-month-day hh:mm:ss)||No|
|Close date||Date and time (year-month-day hh:mm:ss)||No|
|Parent request||Foreign key to a(n) User Request||No|
|Parent problem||Foreign key to a(n) Problem||No|
|Parent change||Foreign key to a(n) Change||No|
|Resolution code||Possible values: assistance, bug fixed, hardware repair, other, software patch, system update, training||No|
|Solution||Multiline character string||No|
|User satisfaction||Possible values: Very satisfied, Fairly statisfied, Rather Dissatified, Very Dissatisfied||No|
|User comment||Multiline character string||No|
|SLA tto passed||Core:AttributeStopWatch+ (100_passed)||No|
|SLA tto over||Core:AttributeStopWatch+ (100_overrun)||No|
|SLA ttr passed||Core:AttributeStopWatch+ (100_passed)||No|
|SLA ttr over||Core:AttributeStopWatch+ (100_overrun)||No|
|CIs||All the configuration items impacted for this ticket|
|Contacts||All the contacts linked to this ticket|
|Child Requests||All the requests that are linked to this parent request|
|Work orders||All the work orders for this ticket|
Creating a User Request
Managing Public & Private Log
The public and the private log are used to keep track of all communications and activities related to a user request.
The public log is aimed at exchanging information with the requestor.
The private log is the preferred way for keeping track of the investigations or operations: copy/paste of command line results, summary of communications with a provider, etc.
Each entry in the public or private log is tracked with the name of the user who updated it and when it was done. It cannot be modified nor deleted.
The public log is visible from the customer portal.
Managing impacted CIs and Contacts
When a user request is created, the agent can specify which configuration items (CIs) are related to this request via the tab “CIs”. The impact analysis engine automatically adds to this list all the other CIs that are potentially impacted by the selected items. It also adds all the contacts that are potentially impacted.
The impact rules of each CIs are described in the Configuration management module.
Dependencies with the service catalog
The Helpdesk module is linked to the service catalog in order to:
define which service and service subcategories can be selected for a given customer
define to which team a user request can be assigned
compute time to own (TTO) and time to resolve (TTR) deadlines
The list of services displays only the service that have been purchased by the selected customer via a customer contract. The list of service subcategories displays only the sub categories corresponding to the selected service and the selected request type.
The following picture describes the relationships between the service catalog elements and user requests.
Assigning a user request to a team and agent
The list of teams to which you can assign a user request is defined by the delivery model of the corresponding customer. When creating a user request, the agent has to select the customer organization, then the list of teams is strictly limited to the teams defined for this customer. If a team is missing, the delivery model of the customer must be updated to reflect this need. See More about Delivery model for more information
The following picture describes the relationships between the delivery model and user requests.
Automated priority computation
The priority is computed automatically. This computation depends on the impact and the urgency of the user request. The following matrix describes how the priority is computed:
To meet service agreements with customers, iTop automatically computes time to own (TTO) and time to resolve (TTR) deadlines. These deadlines depend on the service level agreements defined in the customer contracts. In the basic version of iTop there is no coverage window. The calculations assume a 24*7 service coverage.
The measured TTO is the time cumulated while the user request is not assigned. When the TTO deadline is passed, the ticket status is automatically changed to “Escalated TTO”.
The measured TTR is the time cumulated while the user request is neither pending nor resolved. When the TTR deadline is passed, the ticket status is automatically changed to “Escalated TTR”.
The computation of the deadlines depends on:
The service level agreement defined in the customer contract for the selected service
The priority of the user request
The type of request
These are defined in the service level targets (SLT) corresponding to the service level agreement (SLA).
The deadlines computation is performed each time a modification is made on the user request.
When the cumulated TTO/TTR reaches 75% of the TTO/TTR deadline, then the user request is displayed in yellow. Once the deadline is passed, it becomes red.
Once the user request is resolved, deadlines and measures are kept within the user request. This can be used both for analyzing process issues and for reporting purposes.
The following information are recorded:
TTO deadline (date and time)
TTO cumulated (seconds)
TTO passed (yes / no)
TTO overrun (seconds)
TTR deadline (date and time)
TTR cumulated (seconds)
TTR passed (yes / no)
TTR overrun (seconds)
Regrouping User Request
It is sometimes useful to regroup user requests under an incident which is the root cause of the issue. For instance when a mail server is down, you may have several end users complaining about mailbox being unavailable.
To group user requests, use the field parent incident.
If an incident ticket is parent of a user request, then each time its private and public logs are modified, iTop will automatically update the logs of the child requests. When the parent incident get resolved, iTop will automatically mark the child requests as “resolved”.
User Request Life Cycle
|New||Assigned||Escalated TTO||Waiting for approval||Resolved||Pending||Escalated TTR||Closed||Approved||Rejected|
|Last pending date||H||H||H||H||H||R/O||H||H||H||H|
|SLA tto passed||H||R/O||H||H||R/O||R/O||R/O||R/O||H||H|
|SLA tto over||H||R/O||H||H||R/O||R/O||R/O||R/O||H||H|
|SLA ttr passed||H||H||H||H||R/O||H||H||R/O||H||H|
|SLA ttr over||H||H||H||H||R/O||H||H||R/O||H||H|