Difference between revisions of "Escalation, Resolution & Closure"
Line 16: | Line 16: | ||
* Promotion of the Incident onto a 'Breach' visual Board which maybe monitored by interested stakeholders in the Incident Processes | * Promotion of the Incident onto a 'Breach' visual Board which maybe monitored by interested stakeholders in the Incident Processes | ||
− | ===Resolution=== | + | ===Resolution=== [[File:Customer_resolution.png|200px|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. | ||
===Closure=== | ===Closure=== |
Revision as of 20:22, 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===
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.