JIRA Service Management Reviews

My clients use Service Management for general ITSM ticketing. They typically use Jira internally for providing help desk services to other departments, but one of my customers uses it for his customers, like external websites, etc.

Service Management is great if you're an Atlassian shop already using JIRA for the development team and you want another tool for help desk ticketing. When it's all under the same umbrella, I can easily take a ticket from the help desk and move it to the development team. You can't beat that integration between two products. 

Service Management is highly customizable, but I think it might be too customizable. If a company isn't aware of the best practices, it can easily mess something up. For example, you might try automating something that Jira doesn't support, and it could interfere with the product's out-of-the-box capabilities. 

Asset management should be built into Service Management. Typically, companies need both. You have to buy Atlassian's asset management solution separately. It could either be offered as a bundle or some lighter version of asset management could be included with Service Management. 

I have been using Jira Service Management for a year or so.

I have confidence in Service Management. 

Service Management is scalable. 

I rate Atlassian support two out of 10. It takes a lot of time to reach them and get ahold of someone who understands my problem enough to provide a solution. Also, I live in Israel, so my work week is Sunday through Thursday, but I can only contact them from Monday to Wednesday.

I've worked with ServiceNow. Comparatively, Jira provides a good solution at a reasonable price, and it's quicker to implement inside a company. ServiceNow's implementation is complex. I'm more comfortable with Jira. 

I rate Service Management six out of 10 for ease of setup. At first, setting up Service Management seems incredibly easy. You log into the website and access the site, but nothing comes from the backend because you don't have anything set up for the company. You need to set up the fields, workflows, etc. Companies expect to be able to do it fast after buying the license, but it's not that quick. It typically takes five days to set it up. It isn't a plug-and-play solution.

I rate Service Management four out of 10 for affordability. The price could be better, especially for companies using more than one Atlassian product. It's suitable for SMBs that can afford it. I don't think there's another tool that's both better and cheaper. All help desk tools are relatively expensive.

You also need to consider the overall work we need to do on the tool. The five days of work needed for deployment isn't much, but it requires ongoing maintenance over time.

I rate Jira Service Management seven out of 10. If you plan to implement Service Management, you need to be aware that you can do whatever you want with it, but you might not know the long-term effects. If you do too much automation, it could have unforeseen consequences in the long run. You need to be highly specific about your needs from the start, so you can correctly build the tool's architecture.

We use JIRA Service for our help desk, our procurement processes, and for our financial approvals. We also use it for our technical team collaboration with lines. I'm a program architect.

I think it's very easy to develop any process inside Jira Service Management, you can build any software with it. It's simple to use and user-friendly. It's based on a technical system, but you can move any process into JIRA Service Manager very easily. Its workflow design is very simple and that's why people prefer this product. I think it's currently the best solution on the market.

Service Management currently lacks an asset management module that can make deployment more difficult. We recently had to purchase SolarWinds Asset Management to cover that aspect.

I've been using this solution for 10 years. 

The solution is stable. 

We have around 700 users so the solution is scalable.

The customer support could be improved. 

We used two or three of our developers for the initial setup and they also manage the server. It's not a large team.

Licensing costs are on the expensive side. 

The solution is suitable for mid-sized or enterprise companies and I rate it 10 out of 10. 

We use it to track software development projects.

We get software developed faster.

I like that it's easy to set up Sprint and put tasks and stories into Sprint. It is really easy to lay out the work that needs to be done.

I think that either a Gantt chart or a calendar view is something my management is used to seeing, and while they like the Sprint burndown charts, they would still like to see what is on the plan, and what is up and coming. I would like to see improvement in the ability to filter completed tasks.

I have been using JIRA Service Management for three years.

The stability is ok for our needs. There are times when there have been some flaky things, that I don't think we expected, but it's not crashing all the time.

It seems to scale just fine.

I haven't figured out how to find Jira's technical support. There are times when I would have been happy to have had Jira technical support and I could not figure out how to get ahold of them.

There were some pieces that were more difficult than I expected. This is another place to think of some improvement. Not regarding the installation instructions, but more guidance on the different ways to set up your project and different ways this tool can be used. Again, if I'm paying for the licensing of the tools, going out, and sending lots of people to large training courses, this becomes more expensive. I'm looking for the developers to give more guidance on directions on relating to the tool and the ways that the tool is useful. 

I would rate JIRA Service Management an eight out of ten.

We use this solution to track the work of different team members and to ensure that project tasks get completed. They get assigned tickets relating to those project tasks and and a deadline by which they have to complete the tasks. As they make progress, they update each task in the Jira ticket and this keeps everyone in the loop about their progress.

We have an Agile environment and using Jira makes it easy to adhere to Agile best practices. 

It would be useful to be ale to link tickets across different gantt charts in Jira and Confluence.

I have been using this solution for two and a half years.

This is a stable solution. 

This solution is very scalable. We have tons of people across different companies using it. 

I would rate this solution a nine out of ten. 

One use case is to communicate with customers. We have a lot of customers who are facing issues with products and they can raise the request from the customer portals. Internally, we'll also use it for the IT team and the Jira team. If any configuration changes or any new projects need to be created, or any configurations to be implemented, et cetera, we have a service management project and they will raise their tickets.

The SLAs are great. With SLAs, we can try them out. If you are providing solutions or responding to customers, it's great. 

The flow of the reports is good. I don't see any features or anything that is lacking. Everything is good on the JIRA Service Management, in terms of what they have provided.

It's easy to set up.

We have a lot of add-ons, however, instead of the add-ons, for example, cloning could be better. 

When we do a clone of a particular issue, it needs to ask certain things like system fields at least, to copy them or not. One thing which I did not like, is whenever we are moving a request from one project to another project, if, during that time, for example, a resolution has been fixed and now I am moving that issue to a particular work in progress status, during that time the resolution needs to be clear. JIRA applications are not providing the information. It is not clearing it in the backend.

If we are moving from one issue to another, we are waiting for support to resolve them. During that time window, a resolution is mandatory and it is not prompting us to resolve anything. Due to this, sometimes the reports might not get properly recorded.

I've been using the solution for the last four years. 

Recently, in the Jira cloud, we have had an issue. Users are not able to log in and some of the customer data has also been lost. Overall, it's stable, about 99% stable.

Currently, the number of users on Jira Service Management is around 300 plus users - maybe as many as 400. In terms of Jira software, we have 1400 using it.

It's a scalable product.

We do have plans to increase the licensing in the future.

Technical support has been helpful. We are satisfied with the level of service. 

The implementation is straightforward.

I wrote the automation. I used automation for the Jira app, and in the backend, in the workflows. I used a validator with the script. Based on that, I pulled some conditions. It was easy.

I'm not aware of the exact pricing. It's my understanding that, compared to Service Management, the price is a little higher, however, the Jira software price is okay. It's a good price.

I'm just an end-user.

We are on the cloud, and therefore using the latest version. They release new versions and fixes automatically and we can take advantage of them right away. 

Others need to be aware of how we need to use service management first. They need to know the queues and the SLAs. They need to understand the configurations also. 

I'd rate the solution nine out of ten.

In our bank, we use a partner company who develops software for us. They use Jira for the developer portion to track issues, or bugs, that need to be fixed on the software development life cycle. 

We have two teams, one is the development department which includes developers and business analysts who use Jira to track and develop issues within their own team and a third-party consultant. The other is the audit team who is using Jira to track their audit findings and follow-up.

Jira's issue tracking for different projects for the development side is quite useful.

With respect to our help desk, we have been considering switching from ManageEngine to Jira so that we can have a single consolidated system for all the development life cycles. Jira has different modules that can develop workflow for demand management and project management, but the solution is no out of the box and would require lots of customization. The cost of switching has prohibited us from moving ahead with Jira as a service desk solution.

I have been using Jira Service Management for almost 5 years.

Jira is quite stable.

We haven't used Jira on a large scale. Our work groups are a maximum of 20 people.

We currently are using ManageEngine for the service desk solution. This solution has been good but they do not have a consolidated system for the development life cycle. We would like to switch to Jira for this service solution as well but cost prohibits us from moving forward.

The initial setup is not complex. The deployment itself does not take much time, however the custom workflow does take longer. 

We completed the installation with the help of external consultants who are familiar with Jira.

Jira is becoming quite popular and is well supported. We find that when working with other companies on other projects, they are using Jira to track issues so it is beneficial for us to use the same solution.

Jira has lots of modules and integrations, however too many makes licensing difficult to understand upfront and becomes quite expensive to have a full solution.

I would rate Jira Service Management a 9 out of 10.

We are a software development company with 80 users. As part of development, we track the sprint to see if all the storyboards are complete and development completion. We notify the development team about change requests or incidents using JIRA Service Management.

In software development you need to handle case related software issues, JIRA has helped us with that.

I find the Kanban chart where we put each story in to be the most valuable feature. We use the Kanban chart to revise the project every morning in our five-minute meeting.

JIRA Service Management should make reporting easier. I would like something integrated with DevOps tools.

I have been using JIRA Service Management for two years.

JIRA is a very stable solution.

The solution is scalable.

Once the system is integrated we look at the tickets and find the solution in-house. Someone from JIRA will contact us and offer a solution, but rarely will we request support.

We moved from HP Service Manager to JIRA Service because it was more suited to a software development company. We needed something to support our agility model where other software is focused on operations.

We used an integrator to deploy JIRA. The initial setup of the solution was simple and transferring to JIRA Service took about 3 months.

Switching to JIRA provided a financial ROI. We did the ROI study when deciding to move from HP Service Manager and determined it was beneficial.

If you are a software development company you need to use JIRA because it aligns with project management.

I would rate a JIRA Service Management a 9 of 10.

Most of the use cases were finding solutions to customer problems and SLA cases. We worked with customers on some cases like call centers and with some companies who would like to solve their customer's problems. We also worked with the banking industry and insurance industry.

I have worked at OBSS, which is one of the biggest software companies in Turkey. They were also one of the Atlassian Solution Partners in Turkey. I recently left that company.

Compared to other solutions, Jira Service Management is really reasonable regarding price and speed. Technical support from the Atlassian agents is great.

In the Turkish market, the biggest problem is that they are looking for a server type of solution, but when it comes to Jira Service Management, Atlassian is a remote type of license. There are just two different options, data center and cloud.

When I was working at that company, we started to work with Central Bank of Turkey. We also worked with the defense industry. The biggest complaint was about data privacy. If Atlassian opened a data center in Turkey, that would be a very good solution for these kinds of companies.

Some plugins could be implemented into Jira Service Management, like our plugin. We had our own plugin calculated each status and how much time the company spent in each status.

I have used Jira in the past 12 months. We were using the server type of license. I don't remember the exact version we used, but I have also used the cloud version of Jira Service Management, which was called Jira Service Desk in the past. I used it for more than three years.

The solution is stable.

There were three or four people working on maintenance, but their work was not only in Atlassian. They were working as system engineers. This is one of the responsibilities of maintaining Atlassian products and services.

The solution is scalable. The data center's most popular feature is being scalable.  The cloud is very fast, and setting it up is very easy. 

Our company had around 500 people, but after I left the company, it was around 700 or 800 people.

Technical support is good.

When we created a ticket on Atlassian, they were also working SLA services, L1, L2, L3, and L4. When we created a ticket, we were getting very good service from an agent. In some cases, we had talks with our channel manager, especially about the cost of licenses.

We previously used Confluence, Puppet, Bamboo, and HipChat, and then it was sold to Slack. We used Fisheye and Crucible as well. We were using most of the solutions regarding Atlassian. In my daily life, I have also used Trello.

I worked mostly as a business developer, but when I received feedback from our deployment staff, they said it was not difficult to deploy the solution. Cloud is very easy to use. You just can start to work with it.

The license we use is on a yearly basis. As a Solution Partner, we were using the free one and were using the free plugins. We were also giving our own plugins to the Atlassian Solution Partners for free. We don't pay anything to Atlassian.

I would rate this solution 9 out of 10. 

Sometimes the beginning of the implementation and working with custom-built workflows was a little bit difficult for regular companies. At this step, I strongly advise that they work with an Atlassian Solution Partner.

Specific industries need specific solutions. Atlassian partners have a lot of experience, maybe in that specific country and in that specific company field.

I'm working with a new organization, and we're considering going with Jira. First, we wanted to show the management, the features, and what options the competitors offer as well. Then we'll be moving forward.

Two features I like about Jira are its ticketing system and its compatibility with Confluence. Also, the Knowledge Base is one of the more valuable features that would really benefit us. 
These were the two main features that I'm looking forward to using at this current organization.

With Jira, we were unable to implement time-based automation in its ticketing system. We would like a feature where we can define tickets based on severity, then tickets are automatically escalated to the next level after a set period of time if they go unanswered. 

I've been using Jira for the last 10 years.

Jira is of course very scalable.

We haven't faced any technical issues so far. Standard and premium support are both available 24/7, so I'm guessing it is going to be good. 

Setting up Jira was very easy. The interface is good. Implementation is simple. One person can set it up by himself.  And the user experience is really good in Jira. 

For the people like us, the lower the price, the better. But when compared to other competitors, I think it's Jira's price is okay. 

I would rate Jira Service Management 10 out of 10. I think that people should really go for it because of its ease of use. I would definitely recommend it to others.

Our primary use case is for customer service and customer requests. We also use it to set SLAs and as a general help desk. We are customers of Jira.

The solution has improved company functioning by providing more transparency, in my opinion. Our business is already working out of JIRA, so it connected directly with the platform rather than requiring us to move between several different platforms.

The reporting is a great feature. I also like being able to create customized forms which is extremely helpful.

If you raise a ticket with Jira, the portal doesn't enable any capability to see your other JIRA tickets, only the parts that are in the plugin for the service management. That's not a great experience because we have project teams that work out of their own Jira backlogs, so unless it's a link to a ticket in the JSM, there's no visibility for the customer in one single location.

I've been using this solution for two years. 

We haven't had any issues with performance, other than issues related to being on-prem. It's a stable solution.

The biggest issue is not being able to display linked issues and that makes scalability painful as far as the customer experience goes, and weighs down the system with more tickets. In terms of expanding, it's fairly straightforward. We have over 5,000 users in various roles including managers, developers, HR - it's across the board. In terms of maintenance, we have the main administrator and then a couple of guys that help out.

We transitioned from Salesforce to Jira Service Management mainly because a lot of our teams were already working out of Jira for their own project tracking. It just allowed us to bring everything together rather than working in different systems.

The initial setup was fairly straightforward and was carried out by an in-house team.

I would suggest looking into your current layout and requirements, evaluating them and then figuring out the best option in terms of how you want things categorized and broken down from both a customer perspective and a backend perspective before you try to build it out.

Despite the few downfalls, its cost is still very good compared to other holistic systems. A big reason for getting the switch approved was that the cost was substantially lower than other solutions. I can't speak for the cloud experience, I'm sure it's a little easier than running on-prem, which is very administrator heavy when you want to do a lot of automation or post functions. It's important to be prepared for that. Depending on how your organization is set up, you're likely to need your admin to do those things.

I rate the solution seven out of 10.