Service request management

Service request is normally raised by users or someone on behalf of them and it represents an activity related to a service which has been agreed as a part of service delivery. 

Each service request may include one or more of these items: 

• A service delivery request activity. Example: increase the memory of a computer 
• Request for information. Example: request to receive information about organizational chart 
• Request for provisioning a service or supplying a resource. Example: supply a new physical server or supply a VM in cloud 
• Request to access a resource or service. Example: access to a folder on storage. 
• Feedback, suggestion, complaint, or thank. 

A request fulfillment could include some changes in services and their components, these changes are generally standard changes that are pre-authorized. Service requests are usually a part of service delivery and they don’t include faults or quality decreasements (which are parts of incident management). Because service requests are predefined and agreed and are sections of service delivery, they can be with a clear and standard process of running, approving, fulfillment, and management formatted. Some service requests have simple workflows but some others are complicated and need a combination of different teams. Regardless of the level of complication, the activities for request fulfillment should be understood and approved. That helps the service supplier to agree with service delivery times and to give a clear report about the progress of request to the user. 

Some service requests need to be authorized because of financial, security, or some other policies but some others not. 

To achieve better management, these recommendations are noticeable: 

1. Automation of service request and service supply process -as much as possible- is an advantage. 
2. There should be policies to identify the types of services that need minimum authorization or no authorization.
3. Customers’ expectations about times of responses to requests should be set clearly based on a realistic view.
4. The improvement opportunities should be recognized and implemented in order to achieve a decrease in response time and the use of automation. 
5. There should be procedures that distinguish between standard requests and incidents and changes and guide them through corresponding workflow.

Figure 5.35