Request Fulfillment

The second service operation process we will cover in this chapter is request fulfillment. This is the process for handling requests for standard services, equipment, or information.

The service desk is the single point of contact for users for any aspect of the IT service. We already discussed in Chapter 10 how the service desk handles incidents reported by users. Many of the calls and emails the service desk receives are not reporting anything wrong. They are all the other reasons that the user needs to contact IT, such as for information, for the supply of equipment, to provide access to a system or data, to reset a password, to add or remove a user, and so on. Often these requests are very standard, low-risk, common changes and as such can be handled by the service desk or second-line support teams, without using the normal change management process. In Chapter 8 we covered standard changes (low-risk, repeat changes that may be preapproved). Many requests are actually requests for changes that fulfill the standard change criteria and so may be implemented without any further authorization being sought. Chapter 8 also looked at “change models”—a set of predefined steps for use in a commonly occurring set of circumstances, allowing particular changes to be handled consistently in an agreed manner. Change models are particularly useful in request fulfillment, because they ensure that repeat requests are handled correctly.

ITIL calls all these service requests; they are all opportunities to provide the user with something they have asked for, such as information, advice, a standard change, or access to an IT service (such as resetting a password or providing standard IT services for a new use), and the request fulfillment process is used to handle them.

This process focuses on providing an efficient turnaround of these requests while ensuring that any required authorizations are given. Users appreciate being able to make simple requests and have them fulfilled with a minimum of bureaucracy. By handling these requests at the service desk (and second-line when required), the cost to the IT service provider is also reduced, because more skilled (and therefore expensive) staff members are not used to carry out simple tasks.

Purpose

Request fulfillment is the process responsible for managing the lifecycle of all service requests from the users.

Objectives

The objectives of request fulfillment include providing efficient fulfillment of simple requests to meet the requirements of the business. The process provides a simple means for the business to receive standard services, delivered quickly and consistently, because all the steps required to fulfill the requests (including obtaining any required authorizations) are defined. Users have a single source of information regarding the services available and how to obtain them. If the user wants to comment on or even complain about a service, the same process is used, with a predefined escalation of complaints.

Request fulfillment provides an efficient way to supply standard equipment to users; once an item has been assessed and accepted as compatible with the infrastructure, all future requests can be handled through this process. This encourages the use of standard equipment and software, because it is the easiest and fastest to obtain.

Improving Efficiency by Providing a Standard Request Fulfillment Process

A hospital IT department handled requests for hardware and software from the hospital staff. Users would ask for equipment or software that they had seen advertised in magazines or at their local PC store. Often these offered no benefit over the standard equipment in use in the rest of the organization. Each request was handled by the IT staff approaching several suppliers to find the best price and then informing the requester of the cost so that they could raise a purchase order. The money saved by sourcing the cheapest supplier did not cover the cost of the IT staff time it used. The process might be repeated several times a week for very similar requests, because each was handled separately. When the purchase order was raised, the item would be ordered, and when delivered, the support staff would install it; because each item could be different, this meant the staff had to ensure that they were following the installation directions for the particular model or software. The IT department had then to support all these different items and manage the warranty agreements. Occasionally incidents would be caused because these nonstandard items were incompatible with a change. The whole process was expensive and took up considerable IT time. The process was slow, often taking three or four weeks from request to fulfillment, so users would sometimes circumvent it by buying and installing items themselves!

A new standard request fulfillment process was introduced to address these issues. Following discussion with the business, the IT department agreed on a set of standard software and a number of standard devices—a standard laptop and one for “power” users, a standard desktop PC, and a standard office printer. A small stock of each of these was bought and put in storage. Users now ordered from this short list, at a set price, supplying the purchase order at the time of order. The item was taken from stock and installed the same day, while the purchase order was used to replenish the stock. The new arrangement suited everybody; the user was happy to forego the ability to order any item in return for same-day installation, the IT staff had a simpler range of items to support, the IT management was happy to have a less labor-intensive process, and the finance department was pleased that the IT department was able to negotiate a good price from a single supplier in return for a steady stream of orders.

In addition to these benefits, the simpler process meant that the service desk was able to handle the request, assigning the installation to the desktop support team and ordering the replacement. The simple process was very suited to user self-service and became one of the first services offered to users on the new self-service portal.

---

Take a look at the process flow shown in Figure 12.1; although you do not need to know the process flow in detail for the exam, an understanding of what is involved in fulfilling service requests will help you understand its objectives.

FIGURE 12.1 Request fulfillment process flow

Based on Cabinet Office ITIL® material. Reproduced under license from the Cabinet Office.

Scope

The scope of request fulfillment will vary from one organization to another; it can include any requests that can be standardized and for which organization is happy to use this process. Each request should be broken into agreed activities, with a documented procedure. These procedures are then used to build the request models.

Some organizations will use the incident management process to handle requests, categorizing them as a special type of incident. This has become less common as service management tools have increasingly provided request management workflow capability. There are advantages in treating requests outside of the incident process, because they are very different. Incidents represent a failure in providing the service, and the aim is therefore to reduce the number of incidents. An increasing number of requests, on the other hand, may show that the service offered by the IT department is useful and popular. The targets for incidents and requests may be very different; requests may have specified lead times, which are dependent on other factors (such as the user not being given access until they have attended a training course), whereas the aim is to resolve every incident as quickly as possible.

Where there are a significant number of requests to be fulfilled, a separate process with a different record type should be used. This allows the service provided to be monitored and reported on in a more appropriate way than using incident reporting.

Some organizations widen the scope of requests handled by their service desk or self-service portal to include non-IT requests, such as building management issues regarding cleaning or maintenance issues. Most organizations find that there are also some areas not suited to the process, such as requests for new or changed services, which may be handled by business relationship managers and will involve service strategy and service portfolio management. It would be difficult to have the service desk collect the detail of such a request, and the target lead time would be hard to assess.