Escalation of a issue to a team of agents

[Simone Lechte]

Hi everyone, 

I am fairly new to Jira Service Management and was hoping that someone could assist me with nutting out the process/fields or kindly directing me to someone who can help.

When we receive a support ticket we have a group of L1 customer-facing agents who will review the requests and respond to the client where possible.

In the cases where they are unable to respond due to further information or investigation required we need the ticket to be escalated to our L2 team.

Once an L2 agent reviews the ticket they either assign:
- it to themselves
- to the appropriate L2 agent
- escalate to our developers
- or return it to L1 with information to pass onto the client.

Our platform is very comprehensive and we have multiple L2 agents who manage different types of requests/areas of our platform. Due to the comprehensive nature of this, our L1 staff have a limited understanding of who manages what area. In addition to this, our workforce is spread across multiple locations and we have had in the past delays to support due to agents on leave/unavailable.

We also want majority of our responses to clients to come from our L1 team. 

If there is anyone who can assist or provide guidance it would be greatly appreciated :)

Thank you

[Brant Schroeder · Accepted solution]

@Simone Lechte 

I have setup several service desks like this and solve the problem multiple ways.  Both service desks focused on total ownership of an issue by the L1 agent.  The L1 agent remained the assignee in both cases and was responsible for ensuring that the issue was completed.

In option one we had an escalate transition.  When they escalated the issue the transition screen allowed them to select the area it needed to be escalated to, for instance networking, from a custom drop down field. In the workflow there was a post function that would then add the L2 agents in that area as watchers on the issue.  I believe that JSU was used in this case.  When the watchers were added they then see the issue in an escalated queue and are able to address it and work with the L1 agent to complete the issue.

In option two the organization was much larger and we wanted to ensure that the L2 and L3 agents only focused on their issues.  In this case we used issue security to escalate issues.  This also allowed us to escalate issues on submission for certain request types.  L1 agents had access to all security groups and were the initial point of triage.  They would then apply issue security to the issue which allowed users in that area to now see the issue (the queues were the same for all agents)  The L2 agents would then pickup the issue by adding themselves to a custom field Escalation Agent and work it until the L1 agent could close it out. If L2 escalated then the L3 agent would update the custom field and take over working the issue.

I liked the second way better as it did not require an additional app and actually worked smoother.  

[Simone Lechte]

Hi Brant, 
Thank you for your response. 
It has definitely helped with understanding how I can use other fields and transitions etc. 
How do you then have your network team go back to L1 for example? And if an L1 agent is away do you have anything in place to ensure any client responses etc are managed by another agent in their absence?
It is so customisable that it is hard to work out what to use :D
Thanks again for you help 

[Brant Schroeder]

@Simone Lechte 

In both examples the L1 remains the assignee since we are practicing total ownership.  If however someone is out of the office for the day or an extended period there is a queue that other agents use to help move issues forward.  The manager also can reassign the issue if needed.   the L1 are the only individuals communicating directly with the customer majority of the time.  This frees up L2 and L3 personnel to answer more difficult questions, work on application solutions and projects.