Difference between revisions of "Service request management practice"
(→Best practices) |
(→Characteristics) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
===Characteristics=== | ===Characteristics=== | ||
| − | :[[Service request]]s are pre-defined and pre-agreed and can usually be formalized with clear, standard procedures. Service requests are a normal part of service delivery, not a failure or degradation of service, which are handled as [[incident]]s. Fulfillment of service requests may include changes to services or their components; usually these are [[standard change]]s. | + | :[[Service request]]s are pre-defined and pre-agreed and can usually be formalized with clear, standard procedures. Service requests are a normal part of service delivery, not a failure or degradation of service, which are handled as [[incident]]s. Fulfillment of service requests may include changes to services or their components; usually these are [[standard change]]s. Service requests may have simple [[workflow]]s or quite complex [[workflow]]s. Some service requests require authorization according to financial, information security or other policies. |
===Examples=== | ===Examples=== | ||
| Line 24: | Line 24: | ||
==Best practices== | ==Best practices== | ||
| + | ===Standardization and automation=== | ||
| + | :Service requests and their fulfillment should be standardized and automated to the greatest degree possible: | ||
| + | :*Opportunities for improvement should be identified and implemented to produce faster fulfillment times and take additional advantage of automation. | ||
| + | :*Some service requests can provide a self-service experience – completely fulfilled with automation. | ||
| + | :*Service request management depends on well-designed processes and procedures, which are operationalized through tracking and automation tools. | ||
| − | + | ===Policies and workflows=== | |
| − | + | :*Policies should be established regarding what service requests will be fulfilled with limited or even no additional approvals so that fulfillment can be streamlined. | |
| − | + | :*The expectations of users regarding fulfillment times should be clearly set, based on what the organization can realistically deliver. | |
| − | + | :*Policies and workflows are needed to redirect service requests that should actually be managed as incidents or changes. | |
| − | + | :*Steps to fulfill requests should be well-known and proven. | |
| − | + | :*Leverage existing workflow models whenever possible to improve efficiency and maintainability. | |
| − | + | :*The service provider can agree to fulfillment times and provide clear status communication to users | |
| − | |||
| − | |||
| − | |||
| − | |||
[[Category: Articles]][[Category: Information Technology]] | [[Category: Articles]][[Category: Information Technology]] | ||
Latest revision as of 20:31, 29 December 2020
Service request management practice (hereinafter, the Practice) is the practice to support the agreed quality of a service by handling all predefined, user-initiated service requests in an effective and user-friendly manner. The Practice relates to service request and service management. This Practice is a part of the ITIL practices.
Contents
Definitions
According to the ITIL Foundation 4e by Axelos,
- Service request management practice. The practice of supporting the agreed quality of a service by handling all predefined, user-initiated service requests in an effective and user-friendly manner.
Purpose
The purpose of the service request management practice is to support the agreed quality of a service by handling all agreed user-initiated service requests in an effective and user-friendly manner.
Requests
A service request is a request from a user or a user's authorized representative that initiates a service action which has been agreed as a normal part of service delivery.
Characteristics
- Service requests are pre-defined and pre-agreed and can usually be formalized with clear, standard procedures. Service requests are a normal part of service delivery, not a failure or degradation of service, which are handled as incidents. Fulfillment of service requests may include changes to services or their components; usually these are standard changes. Service requests may have simple workflows or quite complex workflows. Some service requests require authorization according to financial, information security or other policies.
Examples
- Some examples of a service request:
- Request for a service delivery action
- Request for information
- Request for provision of a resource or service
- Request access to a resource or service
- Feedback, compliments and complaints
Best practices
Standardization and automation
- Service requests and their fulfillment should be standardized and automated to the greatest degree possible:
- Opportunities for improvement should be identified and implemented to produce faster fulfillment times and take additional advantage of automation.
- Some service requests can provide a self-service experience – completely fulfilled with automation.
- Service request management depends on well-designed processes and procedures, which are operationalized through tracking and automation tools.
Policies and workflows
- Policies should be established regarding what service requests will be fulfilled with limited or even no additional approvals so that fulfillment can be streamlined.
- The expectations of users regarding fulfillment times should be clearly set, based on what the organization can realistically deliver.
- Policies and workflows are needed to redirect service requests that should actually be managed as incidents or changes.
- Steps to fulfill requests should be well-known and proven.
- Leverage existing workflow models whenever possible to improve efficiency and maintainability.
- The service provider can agree to fulfillment times and provide clear status communication to users
