The primary communication channel between IT and the users is the Service Desk function. When a user contacts Service Desk, in principle the issue can concern anything at all. It might be a question, an order or someone who needs help with an IT service which is not working. That is to say, a request of some kind which has to be dealt with by Service Desk. The Request Fulfilment process exists in order to manage issues which arrive at Service Desk from users.
All issues from users start in the Request Fulfilment process as a service request and are subsequently passed on to other processes if necessary. Service request (or request for service), has become an established generic name which describes orders or enquiries which arrive at Service Desk from users.
For example, a service request can be a user who has a question about how an application is used, a request to have a new application installed, or who wants to order a new telephone or PC.
Purpose
The purpose of the process is to be responsible for the entire implementation of service requests. This is achieved through:
- Providing a channel where the users can order and obtain IT services, provided that they are available to order and that approval is in place, when required, from whoever is paying.
- Providing information about IT services and how they can be ordered.
- Processing orders for standard services
- Answering questions, receiving complaints and other comments
- Helping the users to access the right function with their issue.
Scope
All issues from users start as service requests. The broad definition means that Request Fulfilment often consists of several procedures, depending on what is being requested. Errors in the IT environment that are not known about must be passed on to the Incident Management process and proposals for improvement sent to the concerned function via the Continual Service Improvement process. What subsequently remains and must be completed within the process are support issues and orders.
For support issues it is of great importance that contact paths for escalation are documented for the applications that are part of Service Desk’s responsibility. That way the issue can be rapidly resolved or forwarded to the right support group.
In order to clearly delimit the scope of what can be ordered, each orderable component or IT service must be solidly documented with clear procedures for implementation and any approval necessary.
it is common for Service Desk to provide a web portal where the users can register their orders themselves. The process is subsequently more or less automated. An example is that a user orders an MS Project by entering the details in a web portal. An e-mail is subsequently dispatched to the manager concerned for approval. Once the issue is approved, the application is installed automatically on the user’s computer.
Here it is important that the automated version is retained as a part of the Request Fulfilment process and Service Desk, instead of being managed by another function within the IT department. The danger is that there is a difference between what the web portal provides and what is included in Request Fulfilment, with duplicated documentation, information and statistics as a result.
As everything that is managed within the Request Fulfilment process should be documented in procedures, it is part of the process’s responsibility to provide templates and procedures to establish new, orderable items and services. However, responsibility that the information is entered and is current lies with the service owner for the respective service.
Value for the business
The Request Fulfilment process can give the business’s users fast and effective access to existing IT services, which reduces waiting times in the business’s production process. Moreover, secure and well documented procedures for ordering and installing new applications lowers production costs for the IT department and reduces the risk of errors.
The business is often directly dependent on the IT system. The process provides well-documented procedures to ensure rapid support for users who need help, which reduces downtime in the business’s production process.
Service request catalogue
A large part of the process’s remit is to manage orders from users. To be able to ensure fast and secure management, all orderable products and services must be documented with procedures which describe content, delivery time, production and any authorization necessary. What such a procedure describes is published for the users by Service Desk as a service request catalogue.
The difference to a service catalogue, which is described in more detail in the Service Catalogue Management chapter, is that the service catalogue sets out IT services which can be purchased by customers, while the service request catalogue sets out products and services which can be ordered by users. One example is the IT service ”workplace”, which is purchased by the business, this can then contain several additional applications which can be ordered individually by the users as a service request.
If what the user wants to order is not in the service request catalogue, the enquiry is managed as a proposal for improvement and is forwarded to the concerned function in the Continual Service Improvement process.
Activities
Registration – All issues must be registered with concerned users, equipment and a detailed description of the issue. This is usually where automatically generated issues end up, via, for example, a portal where administrators can pick them up and supplement the information. If an issue is to be passed on to another group/organization for further processing, the work is made considerably easier when full and adequate information is recorded in the issue.
Categorization – Categorize the issue according to a predefined list. The categorization is the same regardless of type of issue, and it reflects the service catalogue’s structure in order to facilitate, among other things, responsibility issues and statistics.
Request type – Errors in the IT environment that are reported must be checked according to the list of known errors. If it is a known error, the temporary solution should be implemented and the issue sent onward to Continual Service Improvement. Errors that are not on the list proceed in the Incident Management Process. Questions are managed according to the documented support procedure. If there is no procedure or if the service desk analyst is not able to respond with his/her own knowledge, the issue is managed as a proposal for improvement in the Continual Service Improvement process.
Prioritization – The priority is determined through a combination of current impact, future impact and time frame according to the prioritization model.
Authorization – Certain orders may need approval from an authorized person in the business. This should be set out in the procedures set for the order, which should also include by whom and how an approval should be managed.
Delivery – Delivery the order according to the documented procedure.
Closing – All solution groups can close an issue after having checked with the user that everything is OK.
Documentation
The following documentation should be available within the framework of Request Fulfilment:
- Service request catalogue
- Procedures for how they are to be implemented
- Procedures for financial approval
- Escalation routes for support issues
Relationships with other processes and functions
The Request Fulfilment process has links to many other processes. The most common are listed here:
Trigger
Request Fulfilment is triggered through:
- Users contacting Service Desk
- Users completing and submitting a form in a web portal for Service Desk
Input
The following inputs are needed for Request Fulfilment:
- Procedures for service requests
- The business’s rules for financial approval
- Procedures and contact paths for support issues
Output
The following outputs are generated by Request Fulfilment:
- Service requests implemented
- Users helped
- Reports
- Incidents registered
- Proposals for improvement registered
Measurement
This is how the Request Fulfilment process can be measured:
- The percentage of service requests that are
- Completed in the time promised
- Closed at first contact
- Managed from Service Desk without needing to visit the user on site
- Average time per issue
- Number of issues per month
Challenges
In addition, the following elements need specific attention when implementing the process:
- Access to adequate documentation of service requests, it is difficult to implement something that is not specified
- Be precise that it is the respective service owner who owns his/her own service request. Service Desk and the Request Fulfilment process only provides what is documented
- The use of self-service portals, these must be a part of the process and owned by Service Desk
- Notify the delivery times which apply for the orders, be honest about the service levels for the service requests that are entered in, in the catalogue
