Difference between revisions of "Escalation, Resolution & Closure"
Jump to navigation
Jump to search
| (12 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
The Hornbill platform is provided with an escalation engine, which can help ensure Incidents are managed and Service Level Targets are adhered too. | The Hornbill platform is provided with an escalation engine, which can help ensure Incidents are managed and Service Level Targets are adhered too. | ||
| − | + | Service Levels can be created to support the differing Response and Resolution targets you wish to use in your Incident processes. Resolution targets can be linked to your defined [[Service Manager Priorities| Priorities]] , and both Response and Resolution timers can be configured to be started and stopped where required in your Incident processes using the Business Process Tool. | |
Each Response and Resolution timer can be configured with escalation actions before and after the defined timer targets. | Each Response and Resolution timer can be configured with escalation actions before and after the defined timer targets. | ||
| Line 19: | Line 19: | ||
[[File:Customer_resolution.png|thumb|right]] | [[File:Customer_resolution.png|thumb|right]] | ||
| − | Once a Resolution is identified the Incident can be moved into a Resolved Status. The Incident Owner can communicate the resolution to the customer , seeking their acceptance. The Customer can via the Service or Customer Portals, review the resolution, and choose to accept if they concur, or reject if the symptoms still persist for them. | + | Once a Resolution is identified the Incident can be moved into a Resolved Status. The Incident Owner can communicate the resolution to the customer, seeking their acceptance. The Customer can via the Service or Customer Portals, review the resolution, and choose to accept if they concur, or reject if the symptoms still persist for them. |
| − | If the Customer accepts the Resolution this can automatically move the Incident into a Closed Status. If the symptoms still exist the Customer can request the Incident is reopened. | + | * If the Customer accepts the Resolution this can automatically move the Incident into a Closed Status. If the symptoms still exist the Customer can request the Incident is reopened. |
| − | Customers can provide feedback on the level of service they have received when closing their Incidents. | + | * Customers can provide feedback on the level of service they have received when closing their Incidents. |
| − | If an Incident is moved into a Resolved status (as part of an supporting business process), it is possible to configure a period of time at the end of which the Incident will automatically move into a Closed status if the customer has chosen not to accept or reject the proposed Resolution. This can be configured into the supporting business process through the Business Process Tool. | + | * If an Incident is moved into a Resolved status (as part of an supporting business process), it is possible to configure a period of time at the end of which the Incident will automatically move into a Closed status if the customer has chosen not to accept or reject the proposed Resolution. This can be configured into the supporting business process through the [[Service Manager Business Process Workflow|Business Process Tool]] and an automated task. |
| + | |||
| + | * Resolution activity can be automated and driven from a supporting business process with the following actions definable as automated tasks in the [[Service Manager Business Process Workflow| Business Process Tool]], potentially invoked automatically on the successful outcome of an investigation task / activity: | ||
| + | |||
| + | :* '''Suspend wait for Resolution''' - await for the resolution text, and resolution category to be manually set | ||
| + | :* '''Update Incident Status''' - set the Status to Resolved | ||
| + | :* '''Update Incident Closure Category''' - Set the Closure Category for the Incident | ||
| + | :* '''Email Incident Customer''' - Send a customized Resolution Email Template from the required mailbox | ||
It is not mandatory to use a two stage closure process with Incident Management, and the resolution element can be bypassed if not required. | It is not mandatory to use a two stage closure process with Incident Management, and the resolution element can be bypassed if not required. | ||
===Closure=== | ===Closure=== | ||
| + | |||
| + | It is possible to move an Incident from an Open to a Closed status where a two stage closure is not required. | ||
| + | |||
| + | Closed Incidents will not appear in the Request List view, but remain accessible via custom views, and the search functions in Hornbill. Closed Incidents can be reopened if required but only by those analysts with the appropriate rights. | ||
| + | |||
| + | [[category:Service Manager]] | ||
Latest revision as of 01:13, 11 January 2019
Home > Service Manager > Escalation, Resolution & Closure
Introduction
Escalation Engine
The Hornbill platform is provided with an escalation engine, which can help ensure Incidents are managed and Service Level Targets are adhered too.
Service Levels can be created to support the differing Response and Resolution targets you wish to use in your Incident processes. Resolution targets can be linked to your defined Priorities , and both Response and Resolution timers can be configured to be started and stopped where required in your Incident processes using the Business Process Tool.
Each Response and Resolution timer can be configured with escalation actions before and after the defined timer targets.
Escalation actions which can be configured include:
- Email Reminders to the Incident Owner or Owner's Manager
- Reassignment to another Resolver Group / Analyst or Manager
- Promotion of the Incident onto a 'Breach' visual Board which maybe monitored by interested stakeholders in the Incident Processes
Resolution
Once a Resolution is identified the Incident can be moved into a Resolved Status. The Incident Owner can communicate the resolution to the customer, seeking their acceptance. The Customer can via the Service or Customer Portals, review the resolution, and choose to accept if they concur, or reject if the symptoms still persist for them.
- If the Customer accepts the Resolution this can automatically move the Incident into a Closed Status. If the symptoms still exist the Customer can request the Incident is reopened.
- Customers can provide feedback on the level of service they have received when closing their Incidents.
- If an Incident is moved into a Resolved status (as part of an supporting business process), it is possible to configure a period of time at the end of which the Incident will automatically move into a Closed status if the customer has chosen not to accept or reject the proposed Resolution. This can be configured into the supporting business process through the Business Process Tool and an automated task.
- Resolution activity can be automated and driven from a supporting business process with the following actions definable as automated tasks in the Business Process Tool, potentially invoked automatically on the successful outcome of an investigation task / activity:
- Suspend wait for Resolution - await for the resolution text, and resolution category to be manually set
- Update Incident Status - set the Status to Resolved
- Update Incident Closure Category - Set the Closure Category for the Incident
- Email Incident Customer - Send a customized Resolution Email Template from the required mailbox
It is not mandatory to use a two stage closure process with Incident Management, and the resolution element can be bypassed if not required.
Closure
It is possible to move an Incident from an Open to a Closed status where a two stage closure is not required.
Closed Incidents will not appear in the Request List view, but remain accessible via custom views, and the search functions in Hornbill. Closed Incidents can be reopened if required but only by those analysts with the appropriate rights.