The purpose of the Request Fulfillment Process is to receive service requests from users and route each request to the appropriate process for handling. Some service requests are handled by the Request Fulfillment Process, whereas many others are routed to other processes for fulfillment. Request Fulfillment can be the contact management process for an implementation of an IT Service Desk (or equivalent).

Read the Service Desk Key Concepts.

Important links

• Request Fulfillment Tool Mentors
• Tivoli® Open Process Automation Library Extensions for Request Fulfillment

Outcomes

As a result of the successful implementation of the Request Fulfillment Process:

• User and customer satisfaction is enhanced
• Service requests to the IT organization are successfully received and processed for fulfillment or other appropriate handling
• Requests are accurately and appropriately routed to the correct process and correct service provider for handling (fulfillment)
• Service level targets for service desk responsiveness and quality are achieved
• Users receive accurate and timely communication concerning the status of their service requests

Scope

At the initial receipt of a service request from a user, the nature of the request and information within it has to be established. Many such service requests can be dealt with by the set of activities within this process. Other service requests, once initially assessed, will be beyond the capability of this process to perform the primary added-value work needed by those requests and will be passed on to other, more specific processes. This process will interact at the process framework level with the specific processes to determine which types of service requests should be handled by which processes. Over time, the range of service requests which can be directly fulfilled is likely to increase.

Examples of interactions are:

• Incidents are routed to the Incident Management process
• Service requests assessed as standard changes are passed directly to other appropriate processes
• Other, more significant change requests are transferred to the Change Management process

Wherever the service request is dealt with, this process retains ownership of the service request on the user's behalf and is responsible for achievement of service level targets relating to service requests.

This process provides the primary interface point for users of IT services with the service provider.

Includes

Receipt and management of service requests relating to:

• Incidents
• Standard changes (such as deployment of standard software)
• Identity
• Access rights
• Security service requests
• Information, advice, guidance
• User satisfaction interactions
• Complaints

Items which are assessed to be change requests (rather than standard changes) can be routed to Change Management

Excludes

• Those interactions between the business (and other customers) and the IT service provider that consider the status, scope or coverage of the overall service provision agreements. (Service Level Management)
• The direct fulfillment of those service requests which are dealt with by other processes. Where such fulfillment workings require direct contact between IT service provider staff performing those processes and users, then those activities are part of those processes. An example of this would be interacting with a user as part of deploying a PC (Deployment Management)
• Establishing entitlement limits for user communities against each service (Combination of Service Marketing and Sales, and Service Level Management)
• Granting access rights (found in Identity and Access Management)
• Installing standard technical components (Deployment Management)
  

Key performance indicators

• User satisfaction with IT handling of
  • Incidents
  • Service requests
  • Requests for information
• Number of contacts handled
  • Percent handled by the first line of support
• The elapsed time and direct costs
  • In this process domain
  • In each process step and between steps
• Time to completion of service goal

Relation to other processes

• When it becomes clear that a service request represents an incident, the information is routed to Incident Management.
• When it is determined that a service request is a change request, the service request is sent to Change Management for consideration.
• If the service request is common and straightforward, it can fall within the realm of standard changes, which can be immediately implemented by whatever process is most appropriate, such as Identity and Access Management. Otherwise, Change Management must process the service request as a request for change.
• The fulfillment of some service requests may be performed by Deployment Management.  In addition, service requests involving simple deployments will update the information in Asset Management and Configuration Management.  
• Comments and feedback, both positive and negative, are provided to Customer Satisfaction Management. 
• Service requests may be generated by a tactical service catalog created by Service Catalog Management.  
• The list of standard changes is created by Change Management as part of the Change Management Framework.

Further reading

See "Request Fulfillment" in the ITIL® documentation.

See the IBM® Service Management Web page.