4.1PURPOSE AND OBJECTIVES (SO 4.3.1)
Request fulfilment is the process responsible for managing all service requests from the users through their lifecycle.
The objectives of the request fulfilment process are to:
- Maintain user and customer satisfaction by handling all service requests in an efficient and professional manner
- Provide a channel for users to request and receive standard services for which there is a predefined authorization and qualification process
- Provide information to users and customers about the availability of services and the procedure for obtaining them
- Source and deliver the components of requested standard services
- Assist with general information, complaints or comments.
4.2SCOPE (SO 4.3.2)
Some organizations deal with service requests through their incident management process (and tools), with service requests being handled as a particular type of ‘incident’. However, there is a significant difference between an incident – usually an unplanned event – and a service request, which is something that should be planned. The process needed to fulfil a request varies depending upon exactly what is being requested, but it can usually be broken down into a set of activities that have to be performed.
Therefore, in an organization where large numbers of service requests have to be handled, and where the actions to be taken to fulfil those requests are very varied or specialized, it may be appropriate to handle service requests as a completely separate work stream. Ultimately it is up to each organization to decide and document which service requests it handles through the request fulfilment process and which have to go through other processes.
4.3VALUE TO THE BUSINESS AND SERVICE LIFECYCLE (SO 4.3.3)
The value of request fulfilment includes:
- Quick and effective access to standard services; this can improve business productivity and/or quality
- A less bureaucratic system for requesting and receiving access to existing or new services, reducing the cost of providing these services
- Where fulfilment is centralized, having more control over services can reduce costs as supplier negotiation is also centralized and support costs are lower.
4.4POLICIES, PRINCIPLES AND BASIC CONCEPTS (SO 4.3.4)
Examples of request fulfilment policies include:
- The request fulfilment activities follow a predefined process flow or model which includes all stages needed to fulfil the request, the individuals or support groups involved, target timescales and escalation paths
- The ownership of service requests resides with a centralized function; for example, the service desk, which monitors, escalates, despatches and may also fulfil the request
- Service requests that impact CIs are usually fulfilled by implementing a standard change
- All requests are logged, controlled, coordinated, promoted and managed via a single system
- All requests are authorized before activities are undertaken to fulfil them.
4.4.1Request models
Service request models (which typically include one or more standard changes in order to complete fulfilment activities) are defined, to ensure that frequently used service requests are handled consistently and meet agreed service levels.
4.4.2Menu selection
Request fulfilment offers great opportunities for self-help. Users are offered a self-help menu from which they can select requests and provide details.
4.4.3Request status tracking
Track requests throughout their lifecycle to support proper handling of requests and reporting on their status. Within the request fulfilment system, status codes may be linked to requests to indicate where they are in relation to the lifecycle. Examples include: in review, suspended, awaiting authorization, rejected, cancelled, in progress, completed, and closed.
The cost of providing the service should first be established and submitted to the user for approval within their management chain. In some cases there may be a need for additional compliance approval, or wider business approval.
4.4.5Coordination of fulfilment activities
Fulfilment activity depends upon the type of service request. Simple requests may be completed by the service desk, while others are forwarded to specialist groups and/or suppliers for fulfilment. The service desk monitors progress and keeps users informed throughout, regardless of the actual fulfilment source.
4.5PROCESS ACTIVITIES, METHODS AND TECHNIQUES (SO 4.3.5)
4.5.1Request receipt, logging and validation
Fulfilment work on service requests should not begin until a formalized request has been received, typically from the service desk. All service requests must be fully logged. Service request records include:
- Unique reference number
- Request categorization, urgency, impact and prioritization
- Date and time recorded, fulfilled and closed
- Name, ID, department and location of the person and/or group making the request
- Method of notification (for example, telephone, web interface, RFC, email, in person)
- Budget centre in case a charge is incurred
- Description of request
- Request status
- Related CIs
- Support group or person to which the service request is allocated.
4.5.2Request categorization and prioritization
Requests can be categorized in several ways: for example, by service, activity, type, function or CI type.
Prioritization is 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. The factors contributing to impact levels are as follows: the number of services impacted; the number of users or business units impacted; whether the requester is at an executive level; the level of financial gain or loss; the effect on business reputation; and regulatory or legislative requirements. A table can be generated for determining priority – Table 3.1 shows an example of a simple priority coding system.
There may also be occasions when, because of particular business expediency, normal priority levels have to be overridden. Some organizations may also recognize ‘VIPs’ whose service requests are handled as a higher priority than normal.
4.5.3Request authorization
No work to fulfil a request should be done until it is authorized. Requests can be authorized via the service desk or by having pre-authorized requests. Alternatively, authorization may need to come from other sources; these could include access management, to determine whether the requester is authorized to make the request, or financial management, to authorize any charges or costs associated with fulfilling the request.
Service requests that cannot be authorized are returned to the requester with the reason for the rejection. The request record is also updated to indicate the rejection status.
4.5.4Request review
The request is reviewed to determine the appropriate group to fulfil it. As requests are reviewed, escalated and acted upon, the request record is updated to reflect the current request status.
4.5.5Request model execution
A request model documents a standard process flow, setting out the roles and responsibilities for fulfilling each request type to ensure that the fulfilment activities are repeatable and consistent. The relevant request model is chosen and executed for each service request.
Request models may be described as process steps and activities that are stored as reference documents in the service knowledge management system (SKMS). Alternatively they may be stored through specialized configurations within automated workflow tools or through code elements and configurations as part of web-based self-help solutions.
Any service requests that impact CIs in the live environment are authorized through change management, typically as standard changes.
Fulfilled service requests are referred back to the service desk for closure. Having checked that the user is satisfied with the outcome, the service desk also ensures that any financial requirements are complete, confirms that the request categorization was correct (or if not, corrects it), carries out a user satisfaction survey, chases any outstanding documentation, and formally closes the request.
4.6TRIGGERS, INPUTS, OUTPUTS AND INTERFACES (SO 4.3.6)
The trigger for request fulfilment is the user submitting a service request, either via the service desk or using a self-help facility. This often involves selection from a portfolio of available request types.
Inputs include:
- Work requests
- Authorization forms
- Service requests
- RFCs
- Requests from various sources such as phone calls, web interfaces or email
- Requests for information.
Outputs include:
- Authorized or rejected service requests
- Request fulfilment status reports
- Fulfilled service requests
- Incidents (rerouted)
- RFCs and standard changes
- Asset and CI updates
- Updated request records.
The primary interfaces are concerned with requesting services and their subsequent deployment:
- Financial management for IT services Interfaces may be needed if costs for fulfilling requests need to be reported and recovered
- Service catalogue management Links with request fulfilment to ensure that requests are well known to users and linked with services in the catalogue that they support
- Release and deployment management Some requests are for the deployment of new or upgraded components that can be automatically deployed
- Service asset and configuration management Once deployed, the configuration management system (CMS) has to be updated to reflect changes that may have been made as part of the fulfilment activities
- Change management Where a change is required to fulfil a request, it is logged as an RFC and progressed through change management
- Incident and problem management Requests may come in via the service desk and may initially be handled through the incident management process
- Access management Ensures that those making requests are authorized to do so in accordance with the information security policy.
4.7INFORMATION MANAGEMENT (SO 4.3.7)
Request fulfilment is dependent on information from the following sources:
- RFCs The request fulfilment process may be initiated by an RFC, usually if the service request relates to a CI
- Service portfolio Enables the scope of agreed service requests to be identified
- Security policies Prescribe controls to be executed or adhered to, such as ensuring that the requester is authorized to access the service
- Authorized approvers People authorized to approve the requests.
Service requests contain information about which service is being asked for, who requested and authorized it, the process used to fulfil the request, the assignee and any actions, date and time of logging, and subsequent actions and closure details.
4.8CRITICAL SUCCESS FACTORS AND KEY PERFORMANCE INDICATORS (SO 4.3.8)
The efficiency and effectiveness of the process can be measured by identifying critical success factors (CSFs) for the process, each CSF being supported by key performance indicators (KPIs):
- CSF Requests must be fulfilled in an efficient and timely manner that is aligned to agreed service level targets for each type of request:
- KPI The mean elapsed time for handling each type of service request
- KPI The number and percentage of service requests completed within agreed target times
- KPI Breakdown of service requests at each stage (e.g. logged, work in progress, closed)
- KPI Percentage of service requests closed by the service desk without reference to other levels of support (often referred to as ‘first point of contact’)
- KPI Number and percentage of service requests resolved remotely or through automation, without the need for a visit
- KPI Total numbers of requests (as a control measure)
- KPI The average cost per type of service request
- CSF Only authorized requests are fulfilled:
- KPI Percentage of service requests fulfilled that were appropriately authorized
- KPI Number of incidents related to security threats from request fulfilment activities
- CSF User satisfaction must be maintained:
- KPI Level of user satisfaction with the handling of service requests (as measured in some form of satisfaction survey)
- KPI Total number of incidents related to request fulfilment activities
- KPI Size of the current backlog of outstanding service requests.
4.9CHALLENGES AND RISKS (SO 4.3.9)
Challenges include:
- Clearly defining the type of requests to be handled by the request fulfilment process
- Establishing self-help capabilities at the front end that allow the users to interface successfully with the request fulfilment process
- Agreeing and establishing service level targets
- Agreeing the costs for fulfilling requests
- Putting in place agreements for which services are standardized and who is authorized to request them
- Making information easily accessible about which requests are available
- Making requests follow a predefined standard fulfilment procedure
- The high impact of request fulfilment on user satisfaction.
Risks include:
- Poorly defined scope, where people are unclear about what the process is expected to handle
- Poorly designed or implemented user interfaces, meaning that users have difficulty raising requests
- Badly designed or operated back-end fulfilment processes that are incapable of dealing with the volume or nature of the requests
- Inadequate monitoring capabilities, meaning that accurate metrics cannot be gathered.
4.10ROLES AND RESPONSIBILITIES (SO 6.7.7)
4.10.1Request fulfilment process owner
Responsibilities include:
- Carrying out the generic process owner role for the request fulfilment process (see section 1.5)
- Designing request fulfilment models and workflows
- Working with other process owners to ensure there is an integrated approach across request fulfilment, incident management, event management, access management and problem management.
4.10.2Request fulfilment process manager
Responsibilities include:
- Carrying out the generic process manager role for the request fulfilment process (see section 1.5)
- Planning and managing support for request fulfilment tools and processes, and coordinating interfaces with other service management processes
- Assisting with identification of suitable staffing levels to deliver request fulfilment activities and services
- Ensuring all authorized service requests are being fulfilled on a timely basis, in line with service level targets
- Representing request fulfilment activities at change advisory board (CAB) meetings
- Overseeing feedback from customers and reviewing request fulfilment activities for consistency, accuracy and effectiveness in order to proactively seek improvements.
4.10.3Request fulfilment analyst
Responsibilities include:
- Providing a single point of contact and end-to-end responsibility to ensure submitted service requests have been processed
- Providing an initial triage of service requests to determine which IT resources will be engaged to fulfil them
- Communicating service requests to other IT resources that will be involved in fulfilling them
- Escalating service requests in line with established service level targets
- Ensuring service requests are appropriately logged.