02. 07. 2014
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.
Latest posts by MarinovMihail