How should Teams of Agents be handled in Jira Service Desk?

[jonesth6]

I have way too many questions below, but am looking for any best practice for managing large numbers of agent teams.  Thanks in advance.

Enterprise Agent Teams in JSD

We're a large enterprise on a trial of JIRA Service Desk Data Center that we're trying to implement.  We're wondering how to best address the many support teams that we have, membership, their issue workload, and team assignment.  I have seen "Organizations" of Customers.  Are there organizations of Agents? Is that coming for JSD Server?

What is a good implementation idea? Is there a plugin we should investigate?

Ideas in Our Heads

Teams as dummy users? Do dummy user's consume an agent license? How do we track Agents as members?

A field as a flag for queues? How can optional notification be emailed based on the field? How is that managed once we hit hundreds of teams?

Soft Guiding Constraints

There are a few soft constraints that we'd like to steer away from:

We hopefully don't need a project for each team.  There are a lot of teams in the support organization and we're concerned about the management of many projects if they're all working on the same issues.

There is only one view of queues presented in a project.  At our scale we wind up with an awkwardly large list of queues.  Plus a JQL filter for queues may not trigger email notification (that some teams might want) if an issue is assigned to them?

If any of those concerns are paranoid fears, a little reassurance would be great.

[Stacey E. Kimmel-Smith]

We are also testing Jira and are a large organization with more than 100 agents on 8-10 teams, performing multiple different functions (tech, admin, library, etc). 

It would be great to hear from organization like us who are using Jira Service Desk...

[Walter Buggenhout]

Hi Tom,

I'd advise you to talk to an Atlassian Partner or - given you're on a Data Center path - your TAM from Atlassian for some guidance around this. From my experience, if you take your questions to the table and invest a couple of hours to max 1 or 2 days, you should have all of this cleared out for you and maybe even be close to having the initial set up done.

Just a few things already:

• Organisations are groups of customers, not agents. This has only been released on cloud so far, but is coming to server with version 3.3 shortly.
• Investigating plugins might be useful, but only if you have a clear idea of what you would want to achieve.
• Every user performing tasks as an agent (being assigned issues, transitioning issues, commenting publicly, monitoring queues and reports, logging work) needs an Agent license, even when this user is a 'dummy' user.
• If you want to use dummy users and still track agents as individual members, add an additional user custom field to identify your individual users.
• take the time to sketch out how you want to organise support. Start from the end user perspective and see how it would make sense for them to enter tickets with support. Map out who will be responsible for reviewing, dispatching, resolving and closing the tickets. There is a contradiction when you talk about managing many projects if your teams would all be working on the same tickets ...