Difference between revisions of "Service request management practice"
(→Purpose) |
(→Characteristics) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
==Purpose== | ==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. | |
| − | [[Service request]]s are pre-defined and pre-agreed and can usually be formalized with clear, standard procedures. | + | ==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 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=== | |
| − | + | :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 | ||
[[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
