Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The Service Request Management module enables the End Users to create Service Requests (SRs) related to their requirements. It also helps the Workgroups to handle the SRs in a more efficient way.

A Service Request (SR) is a formal request, submitted by the User or an Analyst on behalf of the User for any type of service, information, hardware, or software requirement.

Service Request Management Overview
Figure: Service Request Management Overview

The following diagram explains the Service Request Management Life cycle:


Figure: Service Request Management Life cycle

This section explains the various phases of the Service Request Management Life Cycle:

Creation

A Service Request (SR) can be created by an End User, or an Analyst on behalf of the User. While creating the SR, the End User or the Analyst should select a Service Catalog relevant to the requirement. The status of the SR at this phase is New.

Approval

After the SR is created, the SR needs to be approved by the User who is configured as an Approver for the selected Service Catalog. The Approver is selected while configuring the Workflow for Service catalog. The SR may require multiple approvals based on the configuration. After the SR is approved, the status of the SR changes to Assigned.

Request Fulfillment

The Approved SR is assigned to the appropriate Workgroup based on the selected Tenant and Service Catalog. The Workgroup Owner then assigns the SR to the Analyst. Once the SR is assigned to the Analyst, the status of the SR changes to In Progress.

The Analyst fulfills the User requirement and resolves the SR within the Service window, selected by the Workgroup Owner for the Service Request. The Analyst can also create work orders and assign it to different department if part of the User request requires assistance from the other department.

If the Analyst is not able to continue working on the SR due to pending User information, or dependency on any other activity, the Analyst can change the status to Pending. Once the Pending Reason is met and the Analyst can resume his work on the SR, the status of the SR changes back to In Progress. When the SR is in Pending state, the SLA clock pauses and hence, the time is not considered to be within the SLA Service Window.

For Example: A User created an SR for the installation of ABC software on 3rd April 2017, the SLA Service Window for the SR is four days. So, the SR should be resolved by 6th April 2017. But the SR was in pending state for one day, because the License for the tool was not available. Since the SLA clock is paused during the pending state, the new due date for the SR resolution will move to 7th April 2017.

After resolving the SR, the status of the SR changes to Resolved.

Closure

After the Service Request is resolved, the End User or the Analyst can close the SR. The SR may also be closed automatically, if auto closure is configured. The End User can reopen the SR if the resolution is not satisfactory.

The End User can provide feedback for the Resolved/Closed SR from the application or from the Feedback notification mail.


  • No labels