Case Study: why did an external Atlassian Specialist choose our Queues for Jira Service Management for one of his customers?

Some time ago, we had the pleasure of talking with Patrick van der Rijst, an Atlassian Specialist with a software development background. Patrick works in the Netherlands and has over 10 years of experience in getting the most out of Atlassian products and services. He has already consulted a wide range of customers. If there are certain gaps within Atlassian products, he provides his clients with Marketplace solutions. For one of the companies he was helping, Patrick decided to choose our Queues for Jira Service Management. In this interview, we asked him about the challenges he met, why he picked this particular extension, and finally: what was his impression of collaborating with us. 

Patrick van der Rijst: The specific customer to whom we offered your solution was a parking facility company. They take care of parking garage barriers, payment terminals, etc. They operate in several countries: the Netherlands, the UK, and Belgium. This means that they have three different Service Desks, a dedicated one for each country. Usually, you would try to combine them, but in this particular case, they have different onsite agents and mechanics who work per country. The onsite mechanics are not allowed to view data from other countries, contract-wise. What’s more, there is remote support (in case the payment terminal isn’t functioning, maybe there is no need for the mechanic to go onsite if it can be remotely fixed). In order to secure the data, the remote support doesn’t have access to all three Service Desks. The onsite mechanics, who are also agents in the system, can only display their country view. 

The first idea was to set up another separate Service Desk just for remote support, but then, the customers would have to decide on their own whether something requires online or remote support. It’s understandable that clients don’t always know how to qualify issues properly. Possible mistakes would involve the constant movement of issues from onsite support to remote support. For this reason, we left that out of scope. We decided not to implement a dedicated Service Desk for remote support, but to work with solution groups. Thanks to Queues for Jira Service Management, when you access the Service Desk as an agent, the queues are pre-filtered by the solution group “onsite support”. On the other hand, remote support has access to all issues gathered from all Service Desks pre-filtered by the solution group “remote support.”

Patrick: Being able to set up queues instead of using an adjusted dashboard. Operating on actual queues that agents have in projects and gathering issues from multiple Service Desks. Basically, it is the core functionality of the Queues app. Also, the queues-cloning feature was beneficial. Thanks to this functionality, the team doesn’t have to reconfigure every queue manually. Another helpful feature that isn’t available in the native Jira Service Management was categorizing queues. That was something we really liked. Before we tried adding characters (like an arrow) to our queues to mark them. Your product actually provides the possibility of assigning categories such as, for example, incidents, change requests, and service requests.

Patrick: I’m not sure how the filters should be set up. I don’t know if they are stored in the queue configuration itself or if they are configured per user. We noticed that open incident queues also contained tickets waiting for the supplier or waiting for the development. Being able to easily filter them out would facilitate our work.  

Patrick: First of all, when looking for a solution, you do it based on your experience. I know for a fact that Deviniti’s Queues has been around for some time. The product has had three different names already. Still, the app has been there for many years. There is a great Support team behind it, in case you have any issues. For me, it is one of the most important reasons for choosing a specific app: being aware of the fact that bugs are being quickly fixed and knowing there is a great team behind the app, in case you do need help. That’s the reason we chose Queues.

*At the moment, we’re working on a new component that will allow you to save more than one filter that you can apply to the specific queue. In the first version, only the Jira admin will be able to configure them (Global Filters). In the next step, we plan to introduce this option to end users too, if needed (My Filters).

Patrick: There was one thing that we ran into. It was the Visible to groups board. I believe that if you leave it blank by default, your queues won’t be visible at all. Whereas my understanding is that if you leave Visible to groups empty, it will be visible to all. So you have to apply your group per queue to make sure those people have access to it. This was the thing.

Patrick: I actually looked up the case with the Visible to groups and I understood that if you leave the field blank, it won’t be visible to all users. So you have to configure the group to make sure those users have access to the queues. To sum up, the documentation helped me resolve my issue, but I wouldn’t expect the app to work that way. 

Patrick: I do like working with you. Deviniti has been around for quite some time. Your company had a chance to look at the backlog of Jira Service Management, spotted the issues that Atlassian didn’t fix, and immediately took care of them. You are always quick to introduce implementations. Also, when the Cloud got a huge boost, once again you were there. Your products were able to offer most of the features that end users were already familiar with. 

A way of taking care of these issues was by offering additional features. Many users needed them, like, for example, the dynamic fields. It is something that I really like and I know my customers make use of it. Another practical feature is hiding request forms from users who shouldn’t have access to them. My customers benefit from this functionality, for instance, when only managers are the only ones to request specific things. By this, I mean activities like, for example, onboarding new employees. In this particular situation, personal data need to be hidden from other users that don’t belong to a specific group. 

Patrick: Thank you. Feel free to reach out if you need anything else from me. 

The interview was conducted by Paulina Strzelecka from Deviniti, our Technical Writer specializing in Atlassian Apps.