ITIL® Intermediate RCV Tutorial : Request Fulfillment

Request Fulfillment

Welcome to lesson 6 of the ITIL Intermediate RCV tutorial, which is a part of the ITIL Intermediate RCV Foundation Certification course. This lesson looks at how the request fulfillment process contributes to RCV practices. The lifecycle phase emphasized in this unit is service operation.

Let us look at the objectives of this lesson.

Objectives

By the end of this ‘Request Fulfillment’ lesson, you will be able to:

  • Understand the complete overview of the purpose, objectives, scope, and importance of request fulfillment as a process, as well as of how request fulfillment may help to establish a self-help service practice within an organization.

  • Explain the Request fulfillment policies, principles, concepts, activities, methods, and techniques in relation to RCV practices.

  • Explore the relationship between request fulfillment and release and deployment management, as well as how it differs from incident management.

In the next section, we will learn about the purpose and objectives of request fulfillment process.

Purpose and Objectives of Request Fulfillment

The purpose of Request Fulfillment would be actively managing the lifecycle of all service requests from the users.

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 approval and qualification process exists

  • Provide information to users and customers about the availability of services and the procedure for obtaining them

Other objectives of the process also include:

  • Sourcing and delivering the components of requested standard services (e.g., licenses and software media)

  • Assist with general information, complaints or comments.

Let us now look into the scope of this process in the next section.

Scope of Request Fulfillment

The process required to fulfill a request will vary depending upon exactly what is being requested. In some organizations, the Service Requests will be handled through their Incident Management processes.

However, this may not always be appropriate as an Incident is usually an unplanned event.

Whereas, a Service Request is usually something that can and should be planned! It may be appropriate to handle Service Requests as a completely separate work stream, particularly if the organization has chosen to widen the scope of the Service Desk to expand upon the just IT-related issue and use the Service Desk as a focal point for other types of requests for service.

For example, a request to service a photocopier or even going so far as to include, for example, building management issue, such as a need to replace a light fixture or repair a leak in the plumbing. Like any other process, RF process is value to the business.

Let’s discuss this in the next section.

Request Fulfillment- Value to Business

The value of Request Fulfillment is to provide quick and effective access to standard services which business staff can use to improve their productivity or their quality of business services and products. Request Fulfillment effectively reduces the bureaucracy involved in requesting and receiving access to existing or new services, thus, also reducing the cost of providing these services.

Centralization fulfillment also increases the level of control over these services. This, in turn, can help reduce costs through centralized negotiation with suppliers, and can also help to reduce the cost of support.

In the next section, let us look into the policies of the Request Fulfillment.

Curious about the ITIL Intermediate RCV certification course? Click to watch our Course here!

Request Fulfillment- Policies

As we have seen every process has its own set of policies, likewise here we will see the policies stated for Request Fulfillment process.

  • The activities used to fulfill a request should follow a predefined process flow (a model) devised to include the stages needed to fulfill the request, the individuals or support groups involved, target timescales and escalation paths. This ensures that requests are fulfilled consistently and efficiently.

It implies that all types of requests for any given service are identified in advance, and their fulfillment flows considered during service design.

  • The ownership of service request should reside with a centralized function such as the service desk, which monitors, escalates, dispatches and often fulfills the user request.

This provides the benefit of a single point of contact for requesting and receiving information about service requests and their status.

  • Service requests that impact CIs should usually be satisfied by implementing a standard. This ensures that change management does not lose track of changes that may be introduced to CIs through request fulfillment activities.

  • All requests should be logged, controlled, coordinated, promoted and managed throughout their lifecycle via a single system. This supports a consistent and repeatable approach for handling service requests and reduces the potential for lost requests and conflicts that might arise during handling of requests.

  • All requests should be authorized before their fulfillment activities are undertaken. This ensures that resources are efficiently used only for authorized requests. This implies that requests are tied to access management activities and the information security policy

  • Fulfillment of requests should take place under an agreed set of criteria for determining their priority that is aligned with overall service levels and objectives. This ensures that request fulfillment activities support service levels and objectives by prioritizing those activities based on actual business need.

It implies that required service levels and objectives for different types of requests are already understood and agreed to by the business.

  • Clear communication for making requests and determining their status must be in place. This implies that a single point of contact is in place which can be used to request the service and obtain its status.

This is often provided by the service desk or through a web-based interface but could be through an automated request directly into the request fulfillment or procurement system.

Next, we will discuss the principles and key concepts of this process.

Principles and Basic Concepts

In this section, we will go through some of the keywords or key concepts of Request Fulfillment process. They are:

Request Models

Some Service Requests will occur frequently and will require handling consistently to meet agreed service levels. To assist this, many organization will wish to create predefined request models ( which typically include one or more standard changes to complete fulfillment activities).

This is similar in concept to the idea of incident models.

Menu Selection

Request fulfillment offers great opportunities for self-help practices, where users can generate a service request using technology that links to service management tools.

Ideally, users should be offered a ‘menu’-type selection via a web-based interface or request portal so that they can select and input details of service requests from a predefined list.

In this way, appropriate expectations can be set by giving target delivery and implementation targets/dates (in line with SLA targets).

Request Status Tracking

It defines that Requests should be tracked throughout their lifecycle to support proper handling and reporting on the status of requests. All service requests should follow a standard set of criteria for assessing their priority.

Escalating Requests means that in some situations it may be necessary to escalate requests to resolve certain situations or take further actions that are not part of the standard set of fulfillment activities.

Financial Approval

It is the concept of getting approval from the concerned finance. Service requests will often need financial approval. The cost of fulfilling the request must first be established. It may be possible to agree fixed prices for “standard” requests or an estimate of the cost must be produced and submitted to the user for financial approval.

Other Approvals

In certain circumstances, further approval may be required such as compliance-related or wider business approvals. Request Fulfillment must have the ability to define and check such approvals where needed. Coordination of Fulfillment Activities

The actual fulfillment activity will depend upon the nature of the Service Request. Some simpler requests may be completed by the Service Desk, acting as first-line support, while others will have to be forwarded to specialist groups and suppliers for fulfillment.

The Service Desk should monitor and chase progress and keep users informed throughout, regardless of the actual fulfillment source.

Closure

When the Service Request has been fulfilled, it must be referred back to the Service Desk for closure. The Service Desk should check that user is satisfied with the outcome.

In the last few sections, we discussed the key concepts used in the Request Fulfillment process. Let us look at the activities, methods, and techniques in the coming sections.

Process Activities, Methods, and Techniques

The different activities of the request fulfillment process are:

  1. Receive Request

  2. Request logging and validation

  3. Request categorization

  4. Request prioritization

  5. Request authorization

  6. Request review

  7. Request model execution

  8. Request closure

Let us learn about each activity in the next few sections.

Receive Request

The request fulfillment work begins with Receiving Request. Fulfillment work on service requests should not begin until a formalized request has been received. Service Requests should mostly come from the service desk, but it is not unusual to have requests that come in from other sources such as RFCs, email, an automated web ordering interface or phone call.

Standard forms and records should be used to capture request information so that they can be more easily processed, with minimal need to go back to requesters for more information.

Initially, it must be determined whether the request might actually be an incident or a request for new or changed service features.

In other cases, the request may actually be a request for new or changed service features.

This can come from a user or customer who is asking for a new service or requesting something new that is an addition to the agreed standard services available to them.

The next activity would be Request Logging and Validation.

Request Logging And Validation

During request logging and validation, all service requests must be fully logged and date/time stamped, regardless of whether they are raised through a service desk, RFC, telephone call or email.

All relevant information relating to the nature of the request must be logged so that a full historical record is maintained.

Requests must also be initially validated. This includes validating the source of the request and that the request is within the scope of the IT services being offered.

As further activities to fulfill a request occur, the request record should be updated accordingly, with relevant information and details so that a full history is maintained.

Examples of this might include changing the request status or closure date and time once fulfillment activities have been completed.

On completion of validation, the request categorization activity begins.

Request Categorization

Under the request categorization, Part of the initial logging must be to allocate suitable request categorization coding so that the exact type of the request is recorded. This will be important later when looking at request types/frequencies to establish trends for use in determining how services are being used, which requests are the most frequently asked for and other ITSM activities.

Examples of typical categories of requests might include:

  • By service –categorizing the request by the service it is part of. For example, a request to establish a new user email account may be part of an email service.

  • By activity –categorizing the request by the type of activity it is undertaking. Examples might include password reset, desktop installation or printer cartridge replacement.

  • By type –categorizing the request by what kind of request it is, such as an informational request versus a standard change.

  • By function –categorizing the request by which function will be used to perform the fulfillment activities for it.

  • By CI type –categorizing the request by the types of CIs that it impacts.

Request Prioritization

Once the category is set, it is time for setting the Request Priority. Another important aspect of logging every request is to agree and allocate an appropriate prioritization code as this will determine how the service request is handled both by support tools and support staff.

Prioritization can normally be determined by taking into account both the urgency of the request (how quickly the business needs to have it fulfilled) and the level of impact it is causing.

An indication of impact is often (but not always) the number of users being affected. Other factors that can also contribute to impact levels are:

  • The number of services impacted by fulfillment activities

  • The number of users or business units impacted by fulfillment activities

  • Whether the requester is at an executive level of the business or a lower level administrative function

  • The level of financial gain or loss if the request is fulfilled or not fulfilled

  • Effect on business reputation if the request is not fulfilled

  • Regulatory or legislative fines or penalties if the request is not fulfilled.

On completion of prioritization, the request goes for authorization.

Request Authorization

During Request Authorization, No work should take place to fulfill a request until it has been properly authorized. Simple authorizations can take place via service desk alone or as pre-authorized requests based on the request type.

In some cases, a more rigorous authorization may be needed from other sources before any work can proceed, such as through access management to determine whether the requester is truly authorized to make the request, or financial management to authorize any charges or costs associated with fulfilling the request.

A service request that cannot be properly authorized should be returned to the requester with the reason for the rejection, and the request record also updated to indicate the rejection status.

The next activity is reviewing the requests.

Request Review

Now it is the time for Request Review. At this stage, the request is reviewed to determine the proper function that will fulfill it. In many cases, the service desk function may perform all needed fulfillment activities. In other cases, the requests may be escalated to other functions that perform specialized activities to fulfill them.

As requests are reviewed, escalated and acted upon, the request records should be updated to reflect the current request status.

Automated tools may also be used to capture, log, analyze and fulfill requests without human intervention.

An example of this might be a website where users can issue self-help requests that automatically reset passwords for user accounts or provide equipment such as cellular telephones.

This is followed by request model execution.

Request model execution

As functions undertake activities to fulfill a request, a request model should be used that documents a standard process flow, roles and responsibilities for fulfilling it. This ensures that a repeatable and consistent set of actions are always undertaken for each request type that minimizes the risks for delays or failures as requests are fulfilled.

As functions receive and analyze requests, the appropriate request model should be chosen based on the type of request being fulfilled. The process steps and activities indicated in the model are then executed by the function to fulfill the request.

Request models may be described as process steps and activities that can be:

  • Stored as reference documents that can be accessed as part of the SKMS

  • Stored in specialized configurations within automated workflow tools

  • Stored in code elements and configurations as part of web-based self-help solutions.

On execution of the request model, the next activity would be to close the requests.

Request closure

Once service request activities have been completed, the service desk should be notified of the completion status. The service desk should then check that the request has been fulfilled and that users are satisfied and willing to agree that the request can be closed.

The service desk should also check the following:

  • Financial requirements - Financial management may need to be notified of any costs incurred by fulfillment activities or if requesters are to be billed for them.

  • Closure categorization - Check and confirm that the request categorization was correct, or where the categorization subsequently turned out to be incorrect, update the record so that a correct closure categorization is recorded for the request –seeking advice or guidance from the fulfillment group(s) as necessary.

  • User satisfaction survey - Carry out a user satisfaction call-back or email survey for the agreed percentage of requests.

  • Request documentation - Chase any outstanding details and ensure that the request record is fully documented so that a full historical record at a sufficient level of detail is complete.

  • Formal closure - Formally close the request record.

Let’s look into the Rules of reopening request in the next section.

Interested in an ITIL Intermediate RCV certification? Check out our course preview now!

Rules for reopening requests

For reopening requests, it is wise to have predefined rules about if and when a closed service request can be reopened. It might make sense, for example, to agree that if the request needs to be reopened, but beyond a certain point a new service request must be raised.

The exact time threshold/rules may vary between individual organizations, but clear rules should be agreed and documented and guidance given to all service desk staff so that uniformity is applied. The impact on data tracking and reporting should be considered when establishing these rules.

Let us move to the next section on RF triggers.

Request Fulfillment Triggers

Most requests will be triggered by either a user calling the Service Desk or a user completing some form of self-help web-based input screen to make their request. Many Service Requests may come via the Service Desk and may be initially handled through the Incident management process.

There is a strong link needed between Request Fulfillment, Release and Configuration Management – as some request will be for the deployment of the new or upgraded component that can be automatically deployed. Upon deployment, the CMS will have to be updated to reflect the change. Where appropriate, software license check/updates will also be necessary.

In the next section let us look at the inputs and outputs of this process.

Request Fulfillment Inputs and Outputs

As we all know, every process has its own set of inputs and outputs.

Inputs for the process could be:

  • Work Requests

  • Authorization forms

  • Service Requests

  • RFCs

  • Requests from various sources such as phone calls, web interfaces or email

  • Request for information

Outputs could be :

  • Authorized/rejected service requests

  • Request fulfillment status reports

  • Fulfilled service Requests

  • Incidents(rerouted)

  • RFCs/Standard Changes

  • Asset/ CI updates

  • Updated Request records

  • Closed Service Requests

  • Canceled Service Requests

Let us now look at the interfaces of request fulfillment with other lifecycle stages.

Request Fulfillment Interfaces with other lifecycle Stages

The primary interfaces with Request fulfillment lie with Service Desk or Incident management. Many Service Requests may come in via the Service Desk and may be initially handled through the Incident Management process.

Some organizations may choose that all requests are handled via this route – but others may choose to have a separate process, for reasons may vary. A strong link is also needed between Request fulfillment, Release, Asset, and Configuration Management – as some requests will be for the deployment of new or upgraded components that can be automatically deployed.

Like any other process, information management is an integral part of request fulfillment. Let’s look into the details in the next section.

Request Fulfillment Information Management

The Service Requests will contain information about:

  • What service is being requested

  • Who requested and authorized the service

  • Which process will be used to fulfill the request

  • Who it was assigned to and what action was taken

  • The date and time when the request was logged as well as the date and time of all actions taken

  • Closure details

  • RFCs: In some cases, the request fulfillment process will be initiated by an RFC. This is typical where the service request relates to a CI

  • The service portfolio, to enable the scope of agreed service requests to be identified

  • Security policies that prescribe any controls to be executed or adhered to when providing the service, e.g., ensuring that the requester is authorized to access the service, or that the software is licensed.

Moving on, let us discuss the Critical success factors and Key Performance Indicators of the RF process in the next section.

Critical Success Factors (CSFs) and Key Performance Indicators(KPIs)

The following list includes some sample CSFs for Request Fulfillment. Each organization should identify appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a small number if typical KPIs that support the CSF.

These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances.

Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the continual service improvement (CSI) register for evaluation and possible implementation.

The table below lists the CSFs and their corresponding KPIs:

CSF

KPI

Requests must be fulfilled in an efficient and timely manner that is aligned with agreed service level targets for each type of request

  • The mean elapsed time for handling each type of service request

  • The number and percentage of service requests completed within agreed target times

  • Breakdown of service requests at each stage (e.g., logged, work in progress, closed, etc.)

  • Percentage of service requests closed by the service desk without reference to other levels of support (often referred to as ‘first point of contact’)

  • Number and percentage of service requests resolved remotely or through automation, without the need for a visit

  • Total numbers of requests (as a control measure)

  • The average cost per type of service request

Only authorized requests should be fulfilled

  • Percentage of service requests fulfilled that were appropriately authorized

  • Number of incidents related to security threats from request fulfillment activities

User satisfaction must be maintained

  • Level of user satisfaction with the handling of service requests (as measured in some form of satisfaction survey)

  • Total number of incidents related to request fulfillment activities

  • The size of the current backlog of outstanding service requests.

So far we discussed the activities, triggers, inputs and outputs, interfaces, information management, CSFs and KPIs of RF. Let us move on to discuss the challenges faced by RF process.

Request Fulfillment- Challenges

Listed here are some of the common types of challenges that you may encounter:

  • Clearly defining the type of requests that will be handled within the Request Fulfillment process

  • Establishing self-help front-end capabilities

  • Service Level targets will need to be agreed and communicated for each type of request

  • The cost of fulfilling requests must also be agreed

  • Agreements will need to be in place for which services will be standardized and who is authorized to request them.

  • Information about what requests are available will need to be easily accessible.

  • Requests will need to follow a predefined standard fulfillment procedure

  • Request Fulfillment has a very high impact on user satisfaction.

Let us now proceed to discuss the risks of the RF process.

Request Fulfillment - Risks

Some of the common risks you may encounter during request fulfillment are:

  • Poorly defined scope

  • Poorly designed or implemented the user interface

  • Badly designed or operated back-end fulfillment processes

  • Being overambitious – don’t try to improve everything at once.

  • Be realistic with timelines and expectations.

  • Not focusing on improving both service and service management processes

  • Not prioritizing improvement projects

  • Lack of making strategic, tactical or operational decisions based on knowledge gained – reports are actually used; people see that the reports are being used

  • Lack of management taking action on recommended service improvement opportunities

  • Lack of meeting with the business to understand new business requirements

  • The communication/awareness campaign for any improvement is lacking, late or missing altogether.

  • Removing testing before implementation or only partially testing

With this, we have come to end of Module 6 on Request fulfillment. Let us quickly summarise.

You should also consider taking up an ITIL Intermediate RCV Certification course!

Summary

Here is the summary of the topics that we discussed so far:

  • Request Fulfillment is the process of dealing with Service Requests from the users

  • Some organizations handle Service Requests through their Incident Management processes (and tools); others handle them as a completely separate work stream

  • Some of the Request Fulfillment process activities, methods, and techniques are Menu Selection, Financial Approval, Other Approval, Fulfillment, and Closure

  • An Incident is usually an unplanned event whereas a Service Request is usually something that can and should be planned

  • The “release” can be predefined, built, and tested but only deployed upon request by those who want the “release.”

  • There are many challenges, critical success factors, and risks about Request Fulfillment Let us now move to the next module on Change Evaluation.

The next lesson talks about Change Evaluation.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy