Service request fulfillment
What is a service request?
IT receives a wide variety of requests from customers. These requests may include simple requests for support, a new mobile device, software installation, or even a request to move office desktop equipment. ITIL classifies these types of requests as a 'request for service'. The size, frequency and low risk nature of these types of requests means that they are more appropriately handled by a separate process, rather than with incident or change management processes. ITIL identifies the process to handle service requests as request fulfillment. This process is intended to streamline the fulfillment of service requests while delivering the highest level of service support quality to customers.
Many service requests will be recurring, so to achieve the greatest efficiency a repeatable process and procedure should be defined. While some variations with the fulfillment of service requests may exist, it's important to adopt a standard set of processes for request fulfillment. The ownership of service requests resides with the service desk, which monitors, communicates with the customer, escalates, and often times fulfills the service request.
What is request fulfilment?
Request fulfilment is the process for fulfilling a customers request for service. Some of the key objectives of the request fulfillment include: „
- Separate request fulfillment from the Incident and Change processes.
- Request fulfillment needs to be driven by standard services that are defined in the service catalog.
- Provide a single point of contact for requesting standard services from an online service catalog.
- Standard requestable services should include pre-defined processes that streamline the fulfillment.
- Clearly communicate available services, the procedure for requesting them, and the expected fulfillment timeframe.
The process needed to fulfill a request will vary depending upon what is requested, but can usually be broken into a set of activities that have to be performed. 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 varied, 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. Since the service desk team is the first point of contact for customers it recommend they act as the first line of contact for handling service request. Many service requests can and should be handled by the service desk so long as they have sufficient resource, time, tools and skills.
Benefits of request fulfilment
Request fulfilment provides customers with quick and effective access to standard services. Request fulfilment reduces the workload involved in requesting and receiving access to the services that IT provides. Providing this type of access plays an important role in reducing the cost of providing these services. Centralizing the process also increases the level of control over these services. This centralized approach also provides a great opportunity to share knowledge through a searchable knowledge base that provides customers with the information they need. This helps deflect requests and deliver immediate value to the customer.
Request fulfilment also shows the value that support organizations provide to the business by demonstrating the actual cost of the services they offer and providing insight into the resources that are needed to provide certain kinds of services.
Service request fulfilment process
While you will find some variations in the way a service request is captured and fulfilled, it is important to focus on ways to drive standardization to improve the overall service quality and efficiency. The following process represents a sample for request fulfillment based on ITIL recommendations. You can use this simple request fulfillment process as a starting point for adapting existing ITIL processes or defining new ones.
Important request fulfillment activities to consider when defining service requests for JIRA Service Desk
- Begin with the most commonly requested items. Choose ones that are simple and easily fulfilled. This delivers immediate value to customers and allows the IT service desk team to learn as they build out future phases of the request catalog.
- Document all service request offering's requirements (question data, approval process, fulfillment procedures, fulfillment team, process owner, SLAs, reporting, etc.) before you add them to the request catalog. This will allow the IT team to best manage the request offering over time. This step is very important for more complex request offerings that will evolve over time.
- Capture the data needed to start the request process, but don't overload the customer with too many questions.
- Standardize the approval process where possible. For example, all requests for new monitors are considered pre-approved, and all software requests need to be approved by the customers' manager.
- Review the request fulfillment process and procedures to identify which support teams are responsible for completing the request, and if any special requirements exist.
- Identify what knowledge information should be available in the Knowledge Base when a request offering is released. The overall goal of self-service is to give your customers what they want faster and to deflect requests where possible, so if you can answer a question in a common FAQ, include this knowledge as a part of the plan when creating the service request offering.
- Review Service Level Agreements to ensure you have the proper measurements and notifications in place so that requests are fulfilled in a timely manner.
- Identify what reporting is needed to properly manage the life cycle of a service request and request offering in the catalog in the long term.
Fields
We recommend the use of the following fields for your request fulfilment process:
- Description: Use this field to capture the basic information about the incident.
- Status: Indicates the current state of the service request.
- Pending Reason: Specifies the reason for why service requests are moved into pending and what they are pending on.
- Example values: Waiting on vendor, More info required, Awaiting approval,
- Priority: This is determined by the urgency and impact of the request. Your team can define the value matching according to your own processes.
- Example values: Critical, High, Medium, Low
- Urgency: A measure how quickly a resolution of the request is required
- Example values: Critical, High, Medium, Low
- Impact: A measure of the extent of the Incident and of the potential damage caused by the request before it can be resolved.
Example values: Extensive / Widespread, Significant / Large, Moderate / Limited, Minor / Localized
- Operational categorization: Classifies a request for the purpose of assignment and reporting from the operational perspective.
- Example values: Configuration > Printer
- Product categorization: Classifies a request for the purpose of assignment and reporting from the product perspective.
- Example: Hardware > Printer
- Component: Indicates the service associated with the request.
- Resolution: Classifies the resolution.