Purpose The term ‘service request’ is used as a generic description for many different types of demands that are placed upon the IT organization by the users. Many of these are typically requests for small changes that are low risk, frequently performed, low cost etc.
E.g, a request to change a password, a request to install an additional software application onto a particular workstation, a request to relocate some items of desktop equipment) or may be just a request for information.
Request fulfillment is the process responsible for managing the life cycle of all service requests from the users. It is the process for dealing with service requests, many of them are actually smaller, or low risk. The purpose needed to fulfill a request will vary depending upon exactly what is being requested. Some organizations will be comfortable to let the service requests be handled through their incident management processes.
The objectives of the request fulfillment process are to:
Maintain user and customer satisfaction through efficient and professional handling of all service requests.
Provide a channel for users to request and receive standard services for which a predefined authorization and qualification process exists.
Provide information to users and customers about the availability of services and the procedure for obtaining them.
Source and deliver the components of requested standard services (e.g. licenses and software media).
Assist with general information, complaints or comments.
The process needed to fulfill a request will vary depending upon exactly what is being requested, but can usually be broken down into a set of activities that have to be performed.
For each request, these activities should be documented into a request model and stored in the SKMS. Some organizations will be comfortable letting the service requests be handled through their incident management process (and tools). With service requests being handled as a particular type of ‘incident’.
Note however, that there is a significant difference here an incident is usually an unplanned event,
Whereas a service request is usually something that can and should be planned!
Therefore, in an organization where large numbers of service requests have to be handled, and where the actions to be taken to fulfill. Those requests are very varied or specialized, it may be appropriate to handle service requests as a completely separate work stream, and to record and manage them as a separate record type. This is essential if reporting is desired that more accurately separates incidents from requests.
Ultimately it will be up to each organization to decide and document which service requests it will handle through the request fulfillment process, and which will have to go through other processes such as business relationship management for dealing with requests for new or changed services. There will always be gray areas which prevent generic guidance from being usefully prescribed.
Value to Business
The value of the request fulfillment process includes:
The ability to provide quick and effective access to standard services that business staff can use to improve their productivity or the quality of business services and products.
The ability to effectively reduce the bureaucracy involved in requesting and receiving access to existing or new services, Thus also reducing the cost of providing these services.
The ability to increase the level of control over requested services through a centralized fulfillment function.
This in turn can help reduce costs through centralized negotiation with suppliers, and can also help to reduce the cost of support.