The goal of Request Fulfilment is to manage the lifecycle of all Service Requests.
A Service Request is a generic term that describes the numerous and varied demands placed on the service and support organization. Many are small changes, which are considered to be low risk, frequently occurring and low cost in nature, such as change a password or install a software application request. Alternatively, it may simply be a Customer asking for information. It is the scale, frequency and low-risk nature of the Service Requests that require that they be handled by the Request Fulfilment process, and not Incident or Change Management.
The frequent recurrence of Service Requests requires a predefined process Workflow be set with the support Technicians, service targets and escalation paths in place. To cater for the diverse nature of Service Requests, at minimum two Workflows should be customized for Request Fulfilment, one to handle simple requests for information and the other to deal with standard changes.
In the system, Service Requests are logged against Service Items in the Service Catalog and follow Workflows that ensure that each Request is handled with consistency. The Workflows define the actions required to correctly implement any changes to the Service and define the responsibilities, authorization and timeframe expected to manage the changes that may result from a Service Request.
Once a Workflow is assigned to a Service Request, it is routed to an appropriate Technician based on Service Request Workflow State. After a Technician completes their assignment, the Request is forwarded to the next User based on the configuration of the next State for a standard change or closed, if it is a simple request for information.
When Service Requests are raised for Service Item breakdowns, the system allows them to be easily associated with an Incident within the Analysis tab of the Request. Or, if the Service Request results in a change to an Item that is not in the Service Catalog, a Change Request can easily be generated within the Service Request.
If a Service Request is related to an Incident, Problem or Change Request and that related request in the other Process is closed, the Service Request is automatically closed. The system views the request hierarchy from low to high as Service Request, Incident, Problem and Change Request, and if a related request of a higher type is closed, all the lesser type requests are automatically closed,or if the handshaking facility is enabled for the system, moved to the Pending-Approval State.
See: Service Catalog.
To set up the Request Fulfillment Process in the system, the following steps are to be completed:
Assign the Request Process to the relevant Users within the User Information screen under the User>Users tab. (See:Create a User.)
Create or review the SLA within the Service>SLAs tab, and associate the Incident Service Request Workflow to the SLA in the SLAs Workflow tab. (NB: The Supervisor User setting up the SLA must be assigned the Internal Process of Service Level in their User Information screen to complete this action.)
Review the Service Request Workflow within the Service>Workflows tab. (See: Service Request Workflow.)
Create a Service Request Team within the User>Teams screen. (See: Service Request Team.)
Associate the SLA to an Item or Customer or Org Unit. This final step ties all the elements together when a Service Request is created, as the SLA associated with the Item, Customer or Org Unit assigned to the Request determines the Workflow, Team and Technicians that are made available within the Service Request Information screen.