Considerations on Setting Up A New Help Center and Service Desks

[Cole Simonson]

Given that we are new to the Jira platform, I thought it prudent to put these questions out there, so we might be able to avoid mistakes that require our starting over from scratch...  

An example of our potential Service Desk structure:

1. Does this structure of Projects (i.e. Service Desks) work so tickets can be easily reassigned from one Project to another (from one Service Desk to another)?
2. How to create a separate instance of Confluence for each Service Desk Project (or is that automatic)?
3. If someone clicks on the top-level Service Project that all the other company Help Desks are under, and the person does a search for answers, will that automatically search in all of the Confluence pages associated with each of the sub-Projects?
4. How does the association happen between each Service Desk Project and its own Kanban or Scrum board, or would each Service Desk Project only be associated with its own Backlog (which would then feed into its own Kanban or Scrum board)?
5. Are there any “Gotcha’s” in terms of the sequence of setting things up that might cause us to have to delete what we’ve done and start from scratch?  (An example would be if we used Team-Managed Projects instead of Co-Managed Projects.  Another example I could imagine is if we did not have a top-level Project and just created a set of 5 separate Service Desk Projects, then we might decide later that it would have been better to have the top-level Project so we can ask the user a few questions to guide them to the correct Service Desk.)   

I found this for a suggested sequence online:

From:     https://iwconnect.com/the-basic-customization-of-jira-service-desk/

1. Request Groups.  A Group is simply a category you can assign to each Request Type. In the customer portal, your Request Types are organized in vertical tabs based on your groups.  To add Request Groups, go to Settings > Request types. You should see your Groups in the sidebar and select + Add Group.  A preliminary list of request groups is needed to start the customization process.
2. Issue Types:  The default Service Desk Issue Types are: Service Request, Service Request with Approval, Change, Incident, Problem, Task and Sub-task. If needed, new Issue Types can be defined and used.
3. Fields:  Only certain fields are included in every Request Type, and this is something to be determined before creating the Types). There is a list of existing predefined fields, but we can create as many custom fields as needed depending on our needs.  To add or edit fields, go to Settings > Fields.
4. Request Types.  In each of the [Request] Groups we can add different Request Types. But before doing that, we need to determine all the Issue Types that are needed since every Request Type is a kind of Issue Type.  To add a Request Type, go to Settings > Request types. You should see your requests in the sidebar and select Create request type.
5. Screens:  There is a possibility to have different screens for the customers (ones who create the requests) – Create Screen, and for the service desk agents (who work on resolving the requests) – Edit/View screen.  To add or edit screens, go to Settings > Screens.
6. Workflow:  All the default Jira Service Desk Issue Types mentioned above have their own defined Workflows. If we create a new Issue Types or need to make changes to the existing processes, we can always create new Workflows.  A Jira workflow is a set of Statuses and Transitions that an Issue moves through during its lifecycle, and typically represents a process within your organization. Workflows can be associated with particular Projects and, optionally, specific Issue Types by using a Workflow scheme.  To add or edit Workflow, go to Settings > Workflows.
7. Permission and Notification Schemes:  Defining the Permission and Notification Schemes is also very important, but it can be considered as a second phase of customization (after all the previously mentioned things are defined). 
   1. To edit Permission Schema, go to Settings > Permissions. 
   2. To edit a Notification Schema, go to Settings > Notifications.
8. Groups and Roles:  It is possible to define different Groups and Roles in Service Desk to help you restrict the permissions and notification, as well as give different access to groups of people that do not have license. Collaborators are not an official role, but you can bring in non-agents in Jira to work with agents on JSD projects. Simply add them to the Jira Service Desk Team role in a Project, and they can view issues, be @mentioned, and make internal comments without using an Agent license.  To add or edit groups and roles of the users, go to Settings > Users and Roles.

Thank you all for your wonderful help!  Very appreciated...

Cole

[Trudy Claspill]

Hello @Cole Simonson 

I'm not able to address all your questions, but I want to clear up a fundamental misunderstanding.

You cannot nest Projects. There is no concept in Jira of a top level project and child projects. Projects are containers for issues.  Projects can't "contain" other projects. If this is something that is critical to your operations this requirement would need to be explored in more detail to figure out what the real root needs are and see if there is something that could satisfy them.

And here are a few answers I can provide:

You don't need separate Confluence systems to separate the KBs for each service desk project. You link a service desk project to a Space within a Confluence system. That Space is the KB for the Service Desk.

Boards (Kanban or scrum) are used to view and manipulate issues. Boards select the issues to include based on a Filter Query. That Filter Query can be constructed to get all the issues in just one project, issues from multiple projects, or a subset of issues in one project. Issues can also be included in multiple boards, since boards just view and manipulate issues. So each Service Desk project could have its own discrete board and/or you could create Filters that would pull different combinations of some or all issues from some or all service desk projects. Once you have the filters constructed, you can create additional boards that use the filters you constructed.

[Cole Simonson]

Thanks for the clarifications, Trudy.  I may not have used the correct terminology in talking about Projects within Projects.  Where I wrote:

top-level Service Project, 

I was meaning what I think Jira refers to as the 'Help Center'.  

Perhaps I just should have asked there, if we have these 5 different Service Desks and someone puts a ticket in to get help in the wrong one, is it easy to move that ticket to another Service Desk, or is there anything to understand about how we configure these to make sure that can be done?

Thanks again!

- Cole

[Trudy Claspill]

I have not actually tried moving an issue from one service desk project to another, and assessed the impact.

I know it is possible to move issues from one project to another (regardless of the type of project) if the user has sufficient permissions. That would have to be done by one of your internal users who has permissions in both projects. It could not be done by a Customer.

If there are different fields and/or different values available in the two projects, that would have impact on moving the issue.

I'm not sure if the customer and anybody with whom the issue was Shared would still have access after the issue was moved, unless they are Customers of both projects. That specific I have not explored.

[Cole Simonson]

Good considerations.  Okay, thanks!   :)

[Mikael Sandberg]

Just to add to @Trudy Claspill answer. Atlassian has a vision for JSM where the customer has a single point that they go to to get help, and from there the ticket is then created in the correct tool that the receiving support team is using. This was announced during the ITSM keynote at Team 22, check out Sherif Mansour's presentation that start at the 19 minute mark.

[Cole Simonson]

Thanks Mikael.  I will have a look...

Have a great day!