Tell us about your experience when you set up and configured your service desk

[Gemma]

G’day Jira Service Management admins!

We’d love to understand more about your experience when you set up and configured your service desk.

What do you wish you knew then (when you started configuring JSM), that you know now? What would you do differently?

If you are new to JSM and set up your first service desk within the past three months, what were your biggest challenges in getting your service desk up and running?

Please share your experiences as a comment below, or sign up so we can organise a time for quick chat.

Thanks,

Gemma

Jira Service Management

[Han Kong]

1. Would like to copy the default request types so that I can make minor modifications instead of having the build it from scratch.

2. Request types cann'tt be entitled based on user groups.

3. Affected services cannot be selected by users.

4. SLA cann'tt be displayed in the service portal.

5. Required field cann‘t be requested type.

6. Issues cann’t be assigned to a team.

[Jehan Gonsalkorale]

Hi @Han Kong thanks for taking the time to respond and sharing here. 

My teams are working on a few of these. 

1. We are releasing the ability to duplicate request types within a project and are working on the ability to do this across projects. You should be able to duplicate within a project right now. 
2. Are you looking to have some request types available only to specific user groups? Like only managers can create certain request types? This is something we are discussing internally, I appreciate you flagging this (if I've understood correctly). 
3. I'm aware of this issue but have flagged it with our internal teams. 
4. This is being discussed internally, I'll try to get back to you on that once we have an answer. This is the JAC ticket to follow. 
5. We are releasing updates to the Global Issue Create that will always select a request type by default. This will resolve many of the problems of agents creating tickets without request types. 
6. Could you tell me more about how this would work? I'm assuming this is to help the team triage tickets where it is first assigned to a group and then they figure out who works on each ticket etc. Is that correct? 

Looking forward to hearing from you, I'll try to provide an update on #4 shortly. 

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

[Han Kong]

Thank you for solving some of my problems.

2.The portal groups and types of requests that users are authorised to access, based on their group, role, location, etc. This is similar to the access rights for folders and files.

I can give users from a department access to a portal group, but only give certain users access to the specific request types under the portal group.

6.For example, if I assign a issue to a team based on the affected service or component, the team members are alerted and someone comes to pick it up.

If the issue is unassigned when it is not collected, team members can see the issue in my team's unassigned tickets and no other team members can see it. Make sure that each team only sees the issue that is relevant to them to avoid too much noise.

An agent may join more than one team, so the assignment to a team function allows the agent to see as many issues as possible that are relevant to themselves and allows for more use in analysis and tracking. For example, statistics on the workload of each team and the workload of team members.

We need to configure the team leader and manager so that the team leader can be notified when the SLA reaches 50% and the manager at 75%. It would be great if the on-call functionality in opsgenie came into effect. opsgenie only works on events and we need the same effect on service requests, changes and other issue types.

This is the basic function of all ITSM tools.I see a lots of JSM users frustrated because they don't have this feature.

[Han Kong]

@Jehan Gonsalkorale  We hope you will consider.

[Jehan Gonsalkorale]

Thanks for the detail here @Han Kong this is very useful and I entirely agree that these are important use cases for us to deliver on. 

We are already actively considering both, so I'll make sure your input here is considered in those discussions. 

I'll be sure to provide updates as we progress this. 

[Gabriel Lences]

@Jehan Gonsalkorale  We're currently in the early stages of choosing a new ITSM solution in our company and looking into JSM as one of multiple potential candidates for our environment.

Our current solution is pretty dated and non-flexible, but even so , I'll just second some of the points Han said, as these some of them will be things we will be heavily looking into as requirements:

- Administering access to request types / service categories based on an group membership (ideally if somehow group memberships could be assigned to Services) : 

• our current tool can do this on the "Service category" level somewhat, but we'd like for it to go even further deeper to the request types. Reason for this whole permission thing is making the Service Catalog a lot less confusing and a lot more tailored to users and only present them with requests for the services they are eligible for. In our company we have A LOT of services that we provide to the employees, and i really mean a lot. Most of them can be however narrowed down to only specific people as consumers of the services, either based on location, child organization, department, or basically by using any other attribute from AD for the membership. Having a "no customized permissions / everyone sees every request for every service" means our service catalog will end up just the same as it is now - too many options for the users up to the point where they literally get confused on what to select. I hope there are some third party apps as of now at least that handle this kind of thing, because this will play a somewhat big role in our consideration, I reckon. I think it would be cool if it worked in a way where i can assign dynamic group memberships based on any AD / user attribute for the service objects and somehow connect which request types fall under that specific service, which would then be presented to the consumer of the service. Other services and its request types where the user would not be a member of would not be presented to the user as he would be not elligible for that specific service.

- Assigning request to teams 

• basically seconding what Han said, I think this is a basic functionality of a standard ITSM tool nowadays (even our dated solution has this as baseline, "Support Groups") . I can't really see how our analysts would work without this. Our IT division consists of like 200 people, with XY teams and even in those teams there are several people which support multiple services. Every support group manages their own support group queue of tickets and a person can be a member of multiple support groups to which tickets can be assigned. We have these support groups mostly divided by services such as Docusign Support , etc., while behind every support group is an AD group for membership permissions.

Regards,

Gabe

[Jehan Gonsalkorale]

Hi @Gabriel Lences, I appreciate you taking the time to write this. 

I am currently looking at both of these features and I'm looking to see when we can develop them. I definitely agree that they are valuable and necessary, it's more a matter of when we can get a team to develop it. 

We do have JAC tickets for these feature requests, so we will post updates there as decisions are made and we can share them. 

https://jira.atlassian.com/browse/JSDCLOUD-106

https://jira.atlassian.com/browse/JSDCLOUD-195

I'll also take the context you shared here and add it to our internal write ups so they are part of our internal discussions. 

I hope that helps, sorry I can't provide an ETA on these at this time. 

Best regards,

Jehan

[Gabriel Lences]

Thanks for the reply and consideration @Jehan Gonsalkorale , hopefully this can make it into the product soon-ish, though looking at the dates the JAC tickets were created, I'm less optimistic and a bit worried. 🤔

[Dirk Ronsmans]

2 & 6. are really a struggle for us as well.

Being able to restrict request types to groups/users/organisations would be amazing. 

That way you don't have to set up a project per customer organisation or try and hide for example HR related requests or internal requests to the entire customer base.

Being able to assign to a team/group and then drill down to a user of that group in a different field is also something I hear a lot as an annoyance from customers.

While we would love for all IT to be one big team, we are still siloed and set up in a first/second/third line tier system in a lot of companies. Being able to send a request to a different team and have them handle the assignement internally (based on holiday/sick leave/availability/expertise) is a must!

I would also like to add an extra one @Jehan Gonsalkorale , a quick and easy way to create a Request (like you would from the portal) but from the Agent view after clicking the Create button.

At this momet you can select a request type at creation but the form itself remain the general create issue screen instead of flipping over to the request type form. (which would allow for more guided creation)

[Gabriel Lences]

Hello @Jehan Gonsalkorale , any update on this especially 2 & 6. or at least info if this is going to be something that you'll be looking at in the near future? Possible ETA considering your post in May? 🙂

"We are already actively considering both, so I'll make sure your input here is considered in those discussions. I'll be sure to provide updates as we progress this. "

[Han Kong]

This screenshot is from teams 2022, and I see that the new service portal will support richer features, including the ability to see different request types for other groups of users.

I would like to know if this feature will be available this year?

[Dirk Ronsmans]

@Han Kong do you have a source for that screenshot? Seems I missed that one and would love to look further in to it :)

[Han Kong]

Sorry, I can't remember which video it is in.

I have this screenshot too.

[Han Kong]

@Dirk Ronsmans, I found it. The speaker is Darren Henry, Product marketing, ITSM & ITOM Solutions. He says they plan to change the service portal but don't give a time frame. 

@Gemma @Jehan Gonsalkorale If you know anything about the program please share it with us.

Modern Event Management with Opsgenie and Jira Service Management | Team '22 | Atlassian

[Dirk Ronsmans]

Thanks @Han Kong !

I'll take a look :)

[Han Kong]

At 14:25 in the video.

[Sushant Koshy]

Thank you @Han Kong  for sharing this.

I am the Product Manager for Help Center on Jira Service Management. We are working towards making this vision a reality over the next few quarters. The final outcome may look different from the visuals shared here. 

To begin with, in the next couple of months, we are rolling out two capabilities:

• External resource on Help Center - With this capability, project admins will be able to add links to external help resources on Portal.
• Collections on Help Center - Admins will get the ability to group requests and knowledge from across different projects in 'collections'. These collections will be available on the Help Center home page.

We will continue to work towards adding more personalization capabilities to the Help Center. 

[Gabriel Lences]

Hello @Sushant Koshy , how are the personalized help center options coming along?

I've read that external resources and collections on the help center should be avialable now, but I'm curious on what are the closest plans on improving the help center as seen in the screenshots? 😊

Thanks,

Gabe