Jira Work Management vs. Jira Service Management: A comparison

Atlassian has a lot of great tools. Sometimes they overlap a bit, and the names can be a bit confusing to some. This can make it hard for non-experts to navigate and distinguish between the tools. So let us shed some light on it. 

Especially Jira Work Management (JWM), which is a relatively new member of the Atlassian suite. It used to be called Jira Core, but is now rebuilt. Interestingly, it is mainly for teams outside of IT. 

In a previous blog post, I looked at what Jira Work Management is (I recommend that you go back to that post to familiarize yourself with it), and I compared it with Jira Software. 

Now it is time to compare Jira Work Management with Atlassian's third Jira product: Jira Service Management (JSM). We will look at:

• Similarities
• Differences
• How to choose between them

So, now that you know what Jira Work Management is, and how to find a fuller description:

What is Jira Service Management?

It is a ticketing system for teams to keep track of all your customers’ incoming service requests, incidents, problems, change requests, and a lot more. It is being used across the world by teams such as:

• Service desks
• Application operations
• Customer service
• Infrastructure teams

As you can see already, these two “Jiras” are used in completely different ways. Let’s compare them in more detail.

How Jira Work Management and Jira Service Management are similar 

Here is a simple summary of the features that JWM and JSM have in common:

• Core issue functionality, such as creating issues, searching for issues, assigning issues, and transitioning issues.
• Project schemes, such as fields, workflows, screens, and notifications.
• Permissions at global, project, and issue level.
•  System settings, like user access to projects.
• Their powerful forms, where customers can create and follow up on requests for the team.
• Search functionality, so you can easily find issues through search and filtering
• Dashboards and reports to visualize issues and analyze, measure, and monitor them.
• Pre-configured templates, saving you time when setting up projects, using a package with both issue types and workflows.
• Logged-in users create a new request via one of the forms, and an item ends up in the project.

Those were the similarities. Now let’s look at how the two tools differ.

How the two tools are different

When we’re examining the differences, we need to be a bit more descriptive. So let’s cover each of them in turn.

Customer/self-service portal

JSM has a nice, clean, easy-to-use self-service customer portal where your customers add and follow up on their requests.
JWM has no portal, but you can create different forms your customers use to create their requests. In JSM you can also use forms that you have created in JWM.

Configurable backend views

JSM has configurable backend views for agents for handling tickets and fill in the needed information in customizable fields.

Agents working on tickets

When an issue is created in JSM, it ends up in an agent’s queue to be worked on and followed up on. The reporter/customer can follow the ticket status in the customer portal. In JWM, both requester/reporter and team are working on the same project view.

In JSM, agents are measured on SLAs, and depending on the urgency of the request, the agents have different times to resolution. Agents and teams also use the built-in reports to follow up and measure the workload and resolution time, etc.

Customer collaboration

If an issue is unclear, or if there are questions, in JSM the agent can comment on the ticket to collaborate with the customer to solve the issue. Once the issue is resolved, the agent changes to “Resolved”, and sends the ticket back to the customer to verify that it is resolved.

When the customer has tested and verified the solution, they close the ticket and give the process a satisfaction rating. In JWM, the collaboration is similar, but there are no satisfaction metrics.

Internal vs. external comments

In JSM, agents use an internal comment function to communicate with each other and with 3rd line developers. When communicating with customers, they instead use the external comments function.

In JWM, the reporter and team can also comment within tickets, but there is no difference between external and internal comments.

Request types

In JSM, you can effectively measure which areas/problems your customers have trouble with, and e.g. optimize how fast you resolve incidents. You do this by gathering all issue requests into different types and levels to track.

You can’t divide issues into request types in JWM. The only way to differentiate between them is by using issue types, for example, task, epic, story, or sub-task. The issue types in JSM are usually different and include incident, service request, change, and problem.

Knowledge base/Confluence integration

You can integrate JSM with Confluence to build a knowledge base. You can’t do this with JWM, but you can embed JWM reports on a Confluence page, and you can also include Confluence in a JWM project.

Metrics and satisfaction rating

JSM has SLA metrics and you can also measure satisfaction on follow-up, tickets, and the team’s work. In JWM, on the other hand, you tend to measure the number of items mostly.

Business teams work in the JWM views

• Summary view: shows an overview of the number of items in the project, some other reports on the number of items, and how long it takes to answer and resolve the requests.
• Board view: shows the status of ongoing items for day-to-day work in the team.
• List view: shows a list of items and all information given by a customer when completing a request form.
• Calendar view: shows items for long-term planning.
• Timeline view: shows the roadmap and dependencies between different items in the project in a Gantt chart.
• Forms: is where you can create one or more forms to add new items to a project.
• Pages: is the place where you can connect your project with a Confluence space.

Agents work in JSM queues

Create as many queues as you like in your different JSM projects. Just enter your search criteria and find the corresponding issues, depending on, for example, team or status.

Internal vs. external users

Use JWM internally within the organization and JSM when working with external customers to add incidents and requests in the portal.

Should you choose JWM or JSM?

The short answer is: “It depends on who your customers are”. Let me explain:

Jira Work Management for non-technical teams with internal customers

Have your internal customers from other teams create requests in the project or from the customizable form.

If you are a smaller business team with internal customers, I recommend you start using Jira Work Management with all its powerful built-in views, such as:

• List view—an Excel-like view.
• Board view for daily work status.
• Timeline view for resource planning and dependencies on other items in Gantt format.
• Calendar view for a longer-term roadmap.

 The teams will be more familiar with it and enjoy benefits such as the better visualization and transparency in JWM.

Jira Service Management when you have external customers

This is when external or internal customers have issues, find incidents in production, or need help with something. By using the following built-in features, your team can handle and follow up on tickets:

• Customer portal
• Request types
• SLAs
• Knowledge base
• Satisfaction rating
• Working in queues
• Follow-up on KPIs
• Using SLAs

And if your customers often ask the same questions repeatedly, your team will greatly benefit from integrating with Confluence and having knowledge base articles for self-service.

Can you have both JWM and JSM?

Yes, you can combine the two products. If you do, I recommend using JWM for planning work internally and JSM for customer support, incidents, and change management calendar. You can also move issues between projects from the two products.

Summing up

I hope you now have a clearer view of Jira Work Management, and how it differs from Jira Service Management. These tools sometimes overlap a lot, so it takes a bit of navigation.

Having helped numerous companies configure both JWM and ITSM solutions, I love that they are very flexible, and that they have such rich functionality that every implementation is an adventure. There are so many possibilities. Have fun!