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!
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.
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.
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?
Hello Insight users, As part of our (Mindville's) acquisition by Atlassian, our training team is looking to build some new Insight training materials. It would really helpful if you can ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event