Jira Service Desk Projects

[Warren Siaton]

Hello, I'm looking for some guidance on Jira Service Desk where we currently have support queues set-up in our ITSM tool by location and or software specialty.  Can you provide some guidance on what is preferred way to set-up the structure of Jira Service Desk.  Your feedback is greatly appreciated.   I understand that a Project is considered a support group. I just want to understand if you could transfer incidents across multiple support groups.  This is the case where incidents may come into the helpdesk, but would be transferred to the proper support group.

[Ismael Jimoh]

Hi @Warren Siaton 

If I understand correctly, you have JIRA Service Desk and would like to know how to transfer work from one working group to another.

For me to proceed, may I ask if all users who are working on the issue JIRA Service Desk agents(all of them have JIRA Service Desk licenses)?

If no, then my suggestion is as follows:

1. Have your standard JIRA service desk project for the issue.
2. Add a status in your workflow to highlight work is being transferred because users without the SD(service desk) license cannot send messages to customers.
3. When work needs to be transferred, create a linked issue to the new project where this new set of users are working. (Also transition the issue to the new status. If you have SLAs and it is important, you can pause time here).
4. When the person completes his work and hands over back to your agent(s), the message can then be passed to the user from the agent.

Also, if no (SD license) and the task is moved permanently to a new team, you can communicate this to the customer and close the ticket after some sort of handover.

If yes(All users have SD License), you can:

1. Create a status of some sort of escalation that is visible internally but not necessary externally so work continues and can be tracked.
2. The agent can continue work within the same project (you can create a project role Escalation Team for example if you want them to work on specific tasks).

An alternative even if yes is to have the same process as I described above but instead of creating a linked issue, you can even move the ticket to the new project.

The thing is there are lots of ways to handle this.

For me, the best practise is often as much as possible,

• break the problem to the lowest common denominator so you know what team is in charge of what.
• new ticket should be created separately(this helps avoid information overloading and the support team can jump in knowing only information they need for their task) for this new problem but linked to the source problem.
  
  

Hope it helps.