nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Second Line

Robin Robin

What is the appropriate approach for having a SecondLine support tier.

The new issues need to be in a FirstLine queue, and the Agent must be able to refer the issue to the SecondLine queue if she cannot resolve promptly.

It would be good to hear suggestions as to how this is best mapped to JIRA ServiceDesk.

Thanks, Robin.

Accepted answers

Jack Brickey

Robin, building on what Jonas said here, however, It appears that the escalation would be done internally (by Tier-1 agent) not externally (by customer). If that is the case then it is pretty straightforward but the details depend on your specific scenario and current configuration. With that said, i would approach as follows.

add a new status to the workflow. let's call it "Escalated"
add a transition from "Waiting for Support" (or whatever status it is in when Tier-1 is assessing) to the new "Escalated". You will then want to tie in all other necessary transitions in/out of "Escalated" unless you simply choose all statuses can transition to/from "Escalated".
From here there are a number of things you can do (validators, post functions) depending on what you want.
Create an "Escalated" queue(s) from which your Tier-2 engineers would work.

there are a number of things you can do to further the basics above, e.g. use Automation to automatically notify the customer w/ a comment that it has been escalated or add a new SLA metric that is unique for escalations, etc.

hope this helps.

All comments

Jonas Andersson

I would build an escalation process with workflows that simply allowed the customer to click "escalate" and the workflow would transition or even move the issue to another project. Depends if you want to keep it all in one project still. If that's the case i would simply put up a couple of users that are associated with emails from distribution lists in exchange which would be assigned issues on escalations. Once a level 2 agent gets the notification, he can login and assign the issue to himself. Que's could be set up using dashboards that show issues still not assigned to any agents. This will also allow you to keep the JSD agent count low, as only a handful of shared users would be "agents" and regular users would assign themselfs the issues through jira.

Jack Brickey

add a new status to the workflow. let's call it "Escalated"
add a transition from "Waiting for Support" (or whatever status it is in when Tier-1 is assessing) to the new "Escalated". You will then want to tie in all other necessary transitions in/out of "Escalated" unless you simply choose all statuses can transition to/from "Escalated".
From here there are a number of things you can do (validators, post functions) depending on what you want.
Create an "Escalated" queue(s) from which your Tier-2 engineers would work.

hope this helps.

Robin Robin

Thanks Jack / Jonas for your answers.

Yes, escalation is undertaken by Tier1 agent because he lacks the skillset, or could not resolve promptly.

New status and appropriate transitions seems most appropriate here.

Kind regards, Robin.

Ali Rees

I would like to do something similar although slightly different. We have distributors that act as first line support and sell our products in different geographioes. They can raise tickets on behalf of their customers to us, as well as us raising tickets on behalf of them and our direct customers.

For obvious reasons we do not want distributors to have full access and to be able to only view their tickets for their customers.

Thoughts on best implementation of this ?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk

jira-service-desk-cloud