We have approximately 500 agents over 100 teams across the organization. These teams include many different IT and apps teams, many facilities teams, HR teams, marketing, finance, etc... Essentially anyone who provides a service is a member of a team and some people are on multiple teams.
Given the above, I'm wondering the best way to architect a Jira Service Desk implementation to ensure all of the following requirements can be met:
It seems from other posts, the two main options are to either create a project per team or create a custom team field and set up multiple queues. Those options seem to meet some but not all requirements. Are there other ways to set this up? add-ons to consider? Is this a reasonable use case for JSD?
Hi @Matt Strandberg,
As an Atlassian Consultant, I will try to help you with some points, but I am pretty sure that you are going to need a specialist service and a detailed explanation of your situation to an expert so they can help you. That is a paying service.
Points 1 and 3 are contradictory, need ¡more information to find a solution. Thinking quickly, you probably need Dashboards with filters.
Point 2 must be done via Notification Scheme and workflow postfunctions
Point 4 is already solved by Jira Service Desk, you should define exactly which kind of reporting will be needed.
Point 5, 6 and 7 are already solved by Jira Service Desk portal and automations
I can't help you more than this even if you are more specified because usually, it takes hours to have all the points defined to start working in a solution. I hope that these tips help you to find the solution to your problem.
Thank you for your response. I should clarify that what I'm really looking to understand is what type of team architecture is recommended given that we'd need to solve the requirements I provided. for example: would it be advisable to have a JSD project per team or is there a way all of these teams can co-exist in one project?
Can you elaborate on how #1 and #3 are contradictory? We want an agent to not have to sift through the work of other support areas in order to see work assigned to him and his team (#1) and we want to ensure that should that agent want to, he has the ability to find any issues in the system (#3).
As a consultant, have you worked with a client that has had similar needs?
Hi again Matt,
I misunderstood point 1 and 3. They aren't contradictory, and yes, we are working in a similar project right now in a completely new instance.
With 100 teams and the possibility of users being in many groups, I think that neither creating 1 project nor 100 projects would be ideal. You can separate projects by product or another category (internal, external, departments, etc) which your organization then can use to split the teams in the different projects, and finally use queues and dashboards.
To improve visibility for users in Jira Service Desk, add-ons like Comala Canvas, Queues for Jira Service Desk, Queue Collapse for Jira Service Desk can improve user experience.
I would definitely recommend that you create a service desk by Team. (E.g. IT, HR, Finance). Agents can be agents for multiple service desks. But this way you can more easily tailor each team's service desk for their request types, notifications, components, etc.
The only drawback is that native Queues will only work By Service Desk. You can get around that with plugins as mentioned above, or simply use a dashboard (not as real time, but still pretty good).
Hope that helps
Thank you for your response and help. We have about 100 teams. Are you suggesting we would create 100 projects or are you suggesting we should bundle them by department (e.g., all of the IT teams as one project, all the HR teams as another, etc..)?
The main drawback to this in my limited understanding is that we would would have limited ability to centrally manage configurations. For example, if we wanted a standard assignment e-mail (that is a custom e-mail template that is the same for all teams), it would need to be built and maintained in each project. Is that understanding accurate? If so, how would you propose it be managed?
I would recommend bundling by department. At this time configurations for request types, SLAs, automation (all the Service Desk supported stuff) has to be managed per project.
However, Screens, workflows, permissions, notifications can be shared to have some centralization.
Hope that helps
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot