We needed a centralized, user-friendly, and admin-friendly system for our help desk. We had multiple systems and teams that needed to be deployed for this system. For example, we had a development system, a first-line help desk team that was available 24/7, and an escalation process. The first line, second line, and third line might be a local partner or so. We even automated the process for the external partner of our company. So when our first line escalated to the second line of support and the second line couldn't resolve the issue according to the process, it went to the partner. And the partner saw all the history on the tickets. It was a really nice solution.

It has improved our work in a number of ways. First, it has made everything much faster. Before Jira Service Management, it could take weeks to resolve a ticket. But with the notifications and reminders that Jira Service Management provides, we have reduced the time spent on tickets from a couple of weeks to just two to three days.

It has definitely saved us time for really usual stuff, for example, a laptop that doesn't work properly and you require the first-line service desk to address the problem. Previously, it could take up to a week to get it resolved because we didn't have a centralized, automated system for control, monitoring, and reminders, particularly for the first-line managers. Also, there was no escalation process in place. We were using a basic, free, open system without any escalation features, and we received notifications through email, but those were only generated upon ticket creation.

There is room for improvement in support. We had one or two cases of not really nice responses from the partner.

So, there is room for improvement in terms of response time.

In the end of 2021, I implemented a Jira help desk solution in an aviation company.

I worked with a user and a project manager who implemented this solution for about a year. We had a project, then about a year of usage only as a user.

I used it last seven months ago because then I switched jobs. And before that, if we are talking about Jira Service Management, it was implemented at the end of 2021. So it was, like, four months of projects.

It was really easy to set up, and it was really clear for the help desk managers and for the end-users to set the workflow and the business process of the tickets for the help desk. Like, from the box, we used the box solution. It was perfect. I used it six months ago.

It is a stable solution. It is an online solution so it is easy to maintain.

In terms of scalability, Jira covered all our demands. I would rate the scalability a nine out of ten.

We didn't use all the possible settings for the solution, but it still scaled well to our 1200 users. We didn't have any stability problems with Jira, so it gets a ten out of ten from me.

We had some problems with our partner's tech support.

I would rate my experience with the initial setup an eight out of ten, where one being difficult and ten being easy to set up. It took a bit longer than we planned because of the partner.

I had a project manager, a business analyst, and four other people on my team for deploying and maintaining the solution. We also had the head of support and the first-line support manager who tested everything for us.

Overall, the project took about four months, but that included deploying all the processes, levels of escalation, and other things. So it was super easy.

It wasn't the cheapest solution out there. It could have been a bit cheaper, but the user experience and overall capabilities of Jira make it worth the price.

We have another team working on those tools, for example, Trellix and Symantec Data Loss Prevention. We have a range of information solutions used in an ongoing project, and it's only in the planning and feasibility stage for DLP. So, I have worked with a bunch of them.

I would definitely recommend Jira. It's a great solution, but like any other IT tool, it's important to have well-defined processes in place before you implement it. If your processes are not well-defined, Jira won't be able to help you as much.

Overall, I would rate the solution a ten out of ten. It was a great experience for both our first-line help desk managers and our end users. The interface is super easy to use, and the analytics features are really helpful. We were also able to deploy Symantec Data Protection 2 in Jira, which was a great addition.

I use Jira Service Management for product development. Jira Service Desk is largely for handling customer queries and internal ticket management. It helps us with any IT-related requests and also allows customers to submit feedback for the product. So that's how we use Jira Service Management.

Jira Service Management provides workflow management, making it easy for us to track queries and provide solutions. It allows us to review historical data to see how our response time to queries has improved over time. This feedback loop helps us enhance our services and products based on customer input and Net Promoter Score (NPS) feedback.

Different projects benefit from various features. With Jira Service Desk, the simplicity of setting up a quick form and getting the service desk running quickly is very helpful.

On the Jira Software side, I find the idea management feature valuable. It allows us to maintain a backlog of ideas submitted by customers, employees, and product engineering teams. We can track where ideas originate, follow their development into the product, and engage with customers throughout the process, providing a powerful capability.

One area I see for improvement is the custom options for marking an idea as obsolete. Currently, there are options like "not started" or "not working," but in today's rapidly changing tech world, some ideas can become obsolete quickly. For example, technology may become obsolete or a product may no longer be able to cater to a certain idea due to business pivots or changes in the product strategy. However, there is no specific option to indicate why an idea is considered obsolete, whether it's due to technological changes, business model shifts, or other reasons. Capturing these business-driven changes is not easy within the current setup.

It would be beneficial to have a configurable drop-down where we can filter and categorize the reasons for obsolescence, including technical, standard cases, and, importantly, business reasons. If such an option already exists, it might not have been effectively communicated to customers, as I haven't come across it yet within the customer community.

It's essential to have clear ways to manage and track the obsolescence of ideas based on both technical and business considerations.

I have been using Jira for more than six years. I currently use the latest version.

I would rate the stability a nine out of ten. Stability is pretty good; there's never a significant downtime. It's been great.

It is highly scalable. I would rate the scalability a nine out of ten. We have 500+ end users using this solution. Almost all of our employees use this solution.

It's used every single day, heavily utilized for Jira Service Desk and Jira Software for product development. We use it to its maximum potential.

While Jira has a decent community where you can find answers, technical support is fairly okay, mostly due to their strong community.

I would rate my experience with the initial setup a six out of ten, where one being difficult and ten being easy.

Initially, as a completely new user, the interface was not very user-friendly, with many cluttered options. However, once someone showed me how to use it, it became less challenging. But for new users starting with self-service abilities, it's not up to the mark.

The deployment didn't take too long, maybe two or three weeks. It is a self-maintained solution.

We have seen an ROI. The standard way of operating with Jira has optimized time efficiency, which translates to cost efficiency. It allows us to resolve issues more efficiently, although the interface complexity might slightly impact overall efficiency.

The price is not high. I would rate the pricing a seven out of ten, where one is low price, and ten is high price. It's competitively priced, considering other similar products in the market.

There are no additional costs. The license we have covered quite a few offerings, like Jira's Confluence page, so that's pretty good.

If you have a large organization with complex processes and need to scale up, Jira Service Management is an excellent platform for service and development management. However, if you're looking to optimize operations, improve services through data insights, and have a large organization, I would recommend considering ServiceNow as well.

Overall, I would rate the solution a seven out of ten. It's a solid solution with some room for improvement, but overall, it's a valuable product for our organization.

We use the product for our procurement processes and our service desk. We use it for our different teams working on the development side for smaller projects, as well as capital planning.

We have the solution deployed on-prem and on the cloud. We have only one team on the cloud and about 35 teams working on-prem.

In Jira Service Management, the most beneficial features are process improvement, workflows, and escalations.

Jira Service Management should be more user-friendly, like other tools. We configure different projects on these tools, so it's okay for us, but Jira could be a little more simplified for clients. Similarly, there should be licenses for frequent and infrequent users.

I have used Jira Service Management for four to six years.

The solution is quite stable. With 30 teams on the solution, there must be more than 30 projects with multiple requests coming in, but two people are enough to handle Jira. I rate the solution's stability an eight or a nine out of ten.

We have about 1,800 employees in our organization, with more than 30 teams working on Jira. The users are all from procurement teams, finance teams, the capital planning team, the service desk, the development team, the networking team, the data center team, and the operations team as well. We are delivering tickets to our operations team. Everyone is using Jira right now. I rate the scalability of the solution a seven to eight out of ten.

The initial setup is very easy. Initial deployment wouldn't take more than a week because it's not a big deal. The configuration and other tasks will definitely take some time due to discussions with teams and project configuration. One person is enough for deployment. We have two people providing support for Jira.

I rate the pricing a ten out of ten because it is very highly priced. We have paid $20,000 recently for a one-year license for our on-prem server.

We have also procured ServiceNow. Other tools like ServiceNow and monday.com provide simplified user interfaces.

We have started moving into cloud deployment because Jira has discontinued the support for the on-prem servers. Moreover, we are moving to the cloud to reduce the cost. There are many users who are licensed for our on-prem server, but they are not using it. We have 1,800 employees, but out of 1,800, there are 1,000 employees using Jira on a daily basis. We are paying the cost per user. There should be licenses for frequent and infrequent users. For example, my manager logged in once in one quarter or after two months or one month, and we are paying $20 per user.

If they want to save money and have the ability to make workflows by themselves, they can use it for startup companies. Startup companies should instantly go to Jira because it can help them in all departments. They won't need to buy different software for different departments, so it's better to go for Jira and make workflows for each department, which will all be using the same software. That way, they can interconnect within the departments.

I rate Jira Service Management a seven out of ten.

JIRA Service Management was used strictly for our client's IT services in my company. Nowadays, the tool caters to business needs, HR, and administrative purposes, including the payroll aspect of my company's clients. The application has taken a different turn by allowing for managing certain relevant business needs as well.

In recent scenarios, JIRA Service Management has helped my company's clients on the automation front, including onboarding or offboarding employees. The product has multiple use cases with multiple departments, one area that gets highly utilized. The tool also helps convert an incident into a change or problem and then trace and track activities with the tool, which is highly leveraged. Integration of JSM with JIRA software on change and problem management to drive the release, and looking at the release on the DevOps chart, are some use cases by businesses.

The most valuable feature of the solution is its SLA, which everybody wants when it comes to a service-based offering. The queues in JIRA Service Management play a vital role in allowing its users to define the issue types, further classify them into queues, and then carry on.

In-built chat is missing in JIRA Service Management. To compensate for the missing in-built chat, we have been trying to gain leverage with Slack or Microsoft Teams at the moment since it is important to me who stands between the customer and the agent. The aforementioned area needs improvement because it is a very vital area. Suppose one can get on to something in JIRA Service Management that allows for communication. In that case, it is easier to solve a problem rather than communicate with JIRA through comments which will go back and forth.

In short, an in-built chat option will be good for the solution.

I have been using JIRA Service Management for over six years.

It is a stable solution. Stability-wise, I rate the solution an eight to nine on a scale of one to ten.

Scalability-wise, I rate the solution an eight to nine on a scale of one to ten.

I rate the technical support a nine out of ten.

I used to previously work with Bitbucket.

I rate the initial setup phase of JIRA Service Management a six out of ten.

The solution is deployed majorly on the cloud.

The time taken to deploy JIRA Service Management depends on multiple factors. It can range from a week to a month, depending upon what kind of customization and plug-in integrations are required.

JIRA Service Management's pricing is pretty decent compared to competitors. I rate the pricing an eight to nine on a scale of one to ten.

To those planning to use it, I would say that if they have a larger customer base, which may cause them to incur some licensing costs, then that is the area where they should look at JSM as a candidate. If some want to automate their internal processes, which could be operational, business-centric, or technical operation, they can use JSM. People who can look at JSM as a candidate are those who have a little bit of asset requirement where they want to manage the instance and opt for the trace and track functionality to find out what exactly is happening and who is honing what in general.

Overall, I rate the solution a nine out of ten.