What are the best practices for escalating?

Lindsay Siurna November 27, 2019

I am looking for suggestions on how to handle escalations from service desk (tier 1) to tier 2.

 How we currently handle requests:

Help desk takes the call and is able to resolve most requests on their own but there are some that need to go to tier 2 in order to complete.  

We were thinking of using the escalated status: transitioning to escalate and then assigning these tickets to tier 2.  Then Tier 2 would mark them as in progress and start working on them. 

Is this the correct way to use this? 

How does the service desk maintain visibility of these tickets? 

Once we assign them to an IT member, they are out of our sight.

How do you differentiate functional escalation from hierarchical escalation?

How we currently handle incidents:

Help desk takes the call and dos the initial diagnosis. If they are unable to resolve it, it would be transitioned to the escalated status and assigned to tier 2.  Tier 2 would mark them as in progress, work on them and then assign them back to the Service Desk.  

Is this the correct way to use this?  What about visibility?

I have seen that some people create a subtask and assign that to Tier 2 so they don't lose visibility.  Should we be doing that instead?  What are the best practices?  (I am aware that ITIL suggests that the Service Desk owns all Incidents from ‘cradle to grave’ so am trying to figure out the best way to do this.)

 

Thanks for your help!

1 answer

0 votes
Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 27, 2019

Hi @Lindsay Siurna

something seems to be missing in your explanation. I'm wondering if you are saying that when you escalate the issue the person that is taking ownership (T2) is not an agent in the current project?

Here are my thoughts...

You can either have the T2 users as agents in the current project or you can create a separate 'escalation' project and create linked issues between the T1 project and the T2 project. Personally, I generally prefer the former unless I dealing w/ a help desk -> development handoff scenario in which case I'm using the later. This is because the developers are generally working in JSW and T1 would be JSD.

If you keep it in the same JSD project then I would not create a new Escalate status but rather I would either use a Label or a custom radio button to Escalate and then it would go into an Escalate queue for the T2 agents to be accountable for triaging and keeping it empty by assigning it.

Lindsay Siurna November 27, 2019

Hi Jack.  Thanks for your help - we have been debating this for a while. 

Sorry, T2 agents are all agents in our Service Desk project.  

What did you mean by keeping it empty by assigning it?

Would you recommend this for both requests and incidents?

Lindsay

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 27, 2019

Sorry Lindsay, that was rather cryptic :-(

So what I do is I have a Triage queue(s) for unassigned issues. All issues initially come in unassigned. It is up to my entire IT team to monitor this queue and keep that queue empty by taking ownership or assigning ownership to one of the other agents. This is particularly useful when multiple agents can do the same job it also ensures that new issues are reviewed rather than simply falling into an agents queue w/o getting a quick look.

As to requests vs. incidents I guess it depends on the nature of the incident. If it is a critical incident then I would probably still stick into the Triage but I would also do some special alerting. I use OOTB and addon Automation for these actions.

Lindsay Siurna November 27, 2019

Thanks again.  

I like your suggestion about using a custom field/label instead of the escalate status.  

Just a couple more questions about the visibility of the ticket...we have a similar initial process.  Tickets come in unassigned and T1 assigns them to themselves or someone else on T1.  If there is a request that T1 needs T2 to do, we have been assigning it to to the SME on T2.  However this results in the  T1 agent losing visibility of the ticket which is especially important not to do for incident management.  Any tips/ideas? 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events