Difference between revisions of "Escalation, Resolution & Closure"

From Hornbill
Jump to navigation Jump to search
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. 
 +
 
 +
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.
 +
 
 +
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===

Revision as of 20:30, 29 September 2015

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

Customer resolution.png

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.

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