Incident Management and Functional Escalation with EriZone powered by OTRS
Within organizations that implement ITIL processes and have a well-defined Service Desk, second and third level support, functional escalations are required when support of a higher-level specialist is requested. (Img 1)
In EriZone powered by OTRS it is possible to map the structure of such an organization into three queues representing the three support levels. Within this queues tickets can be created, moved and resolved.
For a functional escalation, two options are provided:
Moving the ticket from the current queue to another (which represents the next support level)
Splitting the original ticket into a “child” and putting it directly into the desired queue.
There are two important differences between these two options:
Ownership and communication scenarios:
In case the original ticket is moved and assigned to another support level, the new owner is able to communicate directly with the customer, while the SD agent is still responsible for the ticket. In case the original ticket is spitted, the “child” is assigned to a different owner and represents consequently a distinct communication thread.
Performance measurement of the single support levels:
Within EriZone powered by OTRS it is just possible to assign one SLA per ticket. Therefore, if we have a separate ticket for every support level, we can measure the SLA, agreements with the operational levels or agreements with suppliers, for all the involved support levels. If we instead just move tickets from one level to another, we can only measure the performance of the overall support.
Let us make some examples of such functional escalations within EriZone:
Functional escalation to third support level (suppliers)
In case suppliers have access to the EriZone system: split the original ticket, setting the agent as a customer (requestor) of the child, put the child into the supplier queue and eventually assign a new SLA to it (in accordance with the agreements with supplier).
In case suppliers have no access to the EriZone system: split the original ticket, move the original ticket into the third level queue, eventually assign a new SLA to it and forward the child to the supplier (by e-mail).
Functional escalation to second support level
In case only agents from the SD can communicate with customers: split the ticket, setting the agent as a customer (requestor) of the child, put the child into the second support level queue and eventually assign a new SLA to it (in accordance with the agreements between operational levels) . In this case, customer information should be collected exclusively by the SD agents, recorded within the original ticket and forwarded to the second level using the child ticket.
The agent of the SD is responsible for the communication with the customers, but the second level agents can also “talk” with the customers. In order to avoid that two communication threads are established, on two different tickets regarding the same issue, the splitting option perhaps is not the best solution. SD agents could move the ticket to the second support level queue, but as mentioned before – one ticket allows just one SLA, so the performance measurement for the single support levels would not be possible.
Here an idea could be to provide an automatic ticket creation when the original ticket is moved to the second support level queue. An appropriate SLA will be assigned to the new created ticket and it will be linking it to the original ticket. The new linked ticket will be aimed only at measuring the performance of the second support level and will be automatically closed when the original ticket will be moved back to the SD or is closed. The SLA of the original ticket could be still used to measure the overall SD performance.
“Hi guys! I’m Mihail and since the university years I has been fascinated by distributed systems and measurements on them. Now when I join the Neteye project I get the possibility to continue with this passion and this is great. My free time is completely dedicated to my wife and my daughters, I simply love them.”
Author
MarinovMihail
“Hi guys! I’m Mihail and since the university years I has been fascinated by distributed systems and measurements on them. Now when I join the Neteye project I get the possibility to continue with this passion and this is great. My free time is completely dedicated to my wife and my daughters, I simply love them.”
Alerts are critical signals that demand immediate attention to minimize disruptions and maintain smooth operations. Proactively managing alerts throughout their lifecycle is key to effective event-driven workflows, incident response, and business continuity. By leveraging alerting tools within Jira Service Management Read More
Both Microsoft and Google will terminate within summer/autumn 2022 the possibility of accessing POP and IMAP mailboxes using usernames and passwords! In the course of the year 2022 Microsoft and Google will terminate support for Basic Auth (the authentication with Read More
More and more companies are adopting the now “quasi-standard” JIRA Software issue tracking and software project management tool, and the emerging ticketing tool JIRA Service Management. For most of them, when transitioning from their previous system, it is essential to Read More
Welcome to the latest version of our Service Management solution EriZone version 5.9. Product: EriZoneRelease Number: 5.9Release Date: January 7, 2021Release Type: MinorPrevious Release: 5.8 These release notes for EriZone 5.9 describe changes and improvements, and provide information on how to upgrade. Read More
More and more enterprises rely on Microsoft Azure Active Directory as a company-wide identity provider for Office365, Teams, Sharepoint and other Microsoft and various non-Microsoft services. It provides Single Sign-On (SSO), so when opening any of these applications, if an Read More