Is it possible to create different support team queues for assigning incidents/requests to 2nd level support teams?

[Gustavo Codias]

Hello,

One of my clients is planning to implement Incident Management on JIRA ServiceDesk. I've been analyzing the product, but I couldn't find the way to create support team queues so the Service Desk can assign tickets to other support teams (depending on the established escalation procedure).

Could you please confirm if this is possible?

Thanks.

[Gustavo Codias]

Hello Jack!

Yes, the client has several IT support teams, including the Service Desk.

The Service Desk is the single point of contact between the users and the IT support teams, so when there's an incident o request, the user contacts the SD who registers/categorizes/clasifies the ticket, and then escalates them to other areas of the IT organization (for example, Networking).

What I need to do in JIRA SD is to allow the Service Desk agents to assign (escalate) tickets to the other support teams (by creating support groups or "queues"), so they can work on them and resolve them.

Please let me know if you need additional information.

Regards,

Gustavo.

[Jack Brickey]

Gustavo,

might need more info here to get the best solution. Based upon what you have provided, I would recommend one of the following methods:

• Create a custom "escalated" field. Then, assuming you have something like a Tier 1 ground and a Tier 2 group (escalation) then you can simply create queues (which are really just filtered lists) based upon the "escalated" field.
• Add a state to your work flow for escalation. If you do this you can add a post function to the transition into this state to assign to an individual.

There are lots of things you can do w/ this depending on your exact needs/desires.

hope that helped.

[Jack Brickey]

Following up on your additional info provided. 

So it sounds like you may not want the 'escalation' groups (IT Support teams) to interface with the customers (users) but rather only the SD agents. If that is the case then you could consider creating different projects for each IT support team. Then have the SD teams clone the issue when it comes in and move the clone to the appropriate project. You can then create automation rules to automatically resolve the original SD issue when the clone is resolved. On the other hand, if you want the Support teams working directly with the customer then one project with multiple components would be best.

p.s. when commenting back on answers it is best to make it a comment rather than using the answer field.

[Gustavo Codias]

Hello again Jack.

That's correct. The Service Desk will act as a "filter" for all the Incidents/requests reported by the end users. 

Looks like the only way to avoid duplicating (cloning) tickets is to create a custom field and user queues. Is that correct?

[Jack Brickey]

Well the custom field approach really won't work if you indeed want the service desk team to own the original incident and all customer communications but you want your tier 2 groups to actually work the issue to closure. This is why I suggested separate projects for each tier 2 group and using cloning. Having said that...another possible solution to consider...

1. Maintain single SD project
2. Create a new custom field of type user-picker with only the list of SD Agents. Lets call this "SD Agent"
3. Set up Components for each tier 2 team and set the default assignee for each component as desired
4. When issues comes in they will be triaged by your "SD Agents" where they would:
   1. Set the component to route to the proper team.
   2. If you didn't set up the default assign based upon component then the they will need to manually do so.
   3. Set themselves, or some other SD Agent in the "SD Agent" field
   4. Set/Change any other fields as necessary, e.g. priority.
5. Instruct the Tier 2 agents as to whether they should comment publicly or not as desired. If public comments are restricted to SD agents then they will simply monitor the ticket (email updates) and the update the customer as required.
   
   

Personally I like this approach but may not fit your needs. Lastly, and you may already know this, JSD can get pricey if you have a lot of agents. In my world I only have ~8 but we use JSW for our product development teams. This is where I use cloning and automation as discussed previously.

Good luck...

[Gustavo Codias]

Thanks Jack!