Pick Jira if your team tracks its own work. Pick Jira Service Management, now sold only inside Atlassian's Service Collection, if requests arrive from people outside the team and need a portal, queues, and SLAs. If customer support already runs in HubSpot or another help desk, you need neither. Connect that tool to Jira instead.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Jira vs Jira Service Management at a Glance
| Dimension | Jira | Jira Service Management |
|---|---|---|
| Built for | Teams tracking their own work | Teams answering requests from others |
| Typical users | Engineers, product, project teams | IT, ops, and support agents |
| Work arrives through | The team's own backlog | A portal, email, chat, or widget |
| Core objects | Work items, boards, sprints, releases | Requests, queues, SLAs, knowledge base |
| Free tier | Up to 10 users | Up to 3 agents |
| Billing unit | Every user | Agents only, customers are free |
| Entry paid price | Standard, $9.05 per user per month | Standard, $25 per agent per month |
| How it is sold | On its own | Only inside Service Collection |
Prices are monthly billing for small teams, checked against Atlassian's pricing pages in September 2026. Atlassian's own pages show lower headline numbers because those are blended rates for a 300-user or 75-agent team.
Jira and Jira Service Management share a platform, a data model, and a login, which is exactly why they get confused, and why teams end up paying for the wrong one or for both when they needed one. The comparison also changed twice in the last two years. Jira Software became plain Jira in 2024, and in October 2025 Atlassian stopped selling Jira Service Management on its own and folded it into a bundle called Service Collection, alongside a new product for external customer support.
The short framing: if the work starts inside the team, it belongs in Jira. If it starts with somebody outside the team asking for help, it belongs in a service desk, and Jira Service Management is Atlassian's.
First, the Names Changed
Jira Software is now called Jira, and Jira Service Management now comes inside Service Collection. Both renames matter for what you actually buy.
Jira Software is now Jira. In May 2024 Atlassian merged Jira Software and Jira Work Management into one product called Jira. Existing Jira Software customers kept their pricing. So when this guide says Jira, it means the tracker your engineers use, whatever it was called when you signed up.
Jira Service Management now comes inside Service Collection. Atlassian announced Service Collection in October 2025. Its licensing page says the collection "is sold as a single offering, including Jira Service Management, Customer Service Management, Assets, and Rovo," and that "the apps cannot be purchased separately." One Service Collection license covers an agent in both Jira Service Management and Customer Service Management.
This matters for the comparison because a lot of teams searching Jira vs Jira Service Management are really asking where customer support should live. In 2026, Atlassian's own answer to that question is CSM, and it comes in the same box.
What Jira Is Built For
Jira tracks work a team plans for itself. A work item moves through statuses you define, on a board or a backlog, and it can belong to a sprint, an epic, and a release. Workflows are configurable on every plan, including Free. Permissions decide who sees what. Plans, Atlassian's cross-team planning tool, is on Premium.
The defining trait is that the team owns the queue. Nobody outside the team files directly into the sprint, and the work is ordered by what the team decides matters. That is the right model for engineering, and it is the wrong model for requests, because the person asking has no portal, no expected response time, and no view of where their request stands.
If you are still deciding which tracker engineering should use, that is a different comparison. See Linear vs Jira and GitHub Issues vs Jira.
What Jira Service Management Adds
Jira Service Management adds request intake, a portal, queues, SLAs, and ITSM processes to the Jira engine. It is a service desk built on the same Jira engine. Under the hood, a request is a Jira work item in a Jira project, which Atlassian's current documentation calls a service space. On top of that, it adds everything a team needs to take requests from people who are not on the team:
- Request types and forms. Structured intake so a laptop request, an access request, and a bug report each collect the right fields.
- A portal and help center. Requesters submit and track their requests without a Jira account, and read knowledge base articles before they submit. The knowledge base runs on Confluence, and the basic version needs no separate Confluence purchase.
- Channels. Email, Slack, Microsoft Teams, an embeddable widget, and the portal all create requests.
- Queues and SLAs. Agents work prioritized queues, and SLA timers track time to first response and time to resolution.
- Incident, problem, and change management. Alerts, on-call, and incident templates on every plan, with advanced incident, problem, and change processes, change approvals, and AIOps on Premium.
- Assets. Asset and configuration management, included from Standard with 5,000 objects.
None of that is useful to a team tracking its own work, and all of it is useful to a team answering requests. That is the whole comparison in one sentence. A team that needs a portal, a queue, and a response-time promise needs a service desk. A team that needs a backlog does not.
Jira is the right fit when
- The team plans and orders its own work
- Work moves through sprints, epics, and releases
- Everyone who touches the work is on the team
- You need boards, backlogs, and custom workflows, not a portal
Jira Service Management is the right fit when
- Requests arrive from people outside the team
- Requesters need a portal and a way to track status
- You promise response and resolution times
- You run incidents, changes, or IT assets
Jira vs Jira Service Management Pricing
Both products charge per seat, but they count different people, and both pricing pages show a headline number most small teams will never pay.
| Plan | Jira, per user per month | Service Collection, per agent per month |
|---|---|---|
| Free | Up to 10 users | Up to 3 agents |
| Standard | $9.05 for users 1 to 100 | $25.00 for agents 1 to 15, $18.75 for 16 to 100 |
| Premium | $18.30 for users 1 to 100 | $57.30 for agents 1 to 15, $49.95 for 16 to 100 |
| Enterprise | Annual only, through sales | Annual only, through sales |
Both products price monthly seats in bands, and each seat is charged at the rate of the band it falls in, so larger teams pay less per seat. Annual billing is priced in bands instead: Jira Standard is $900 a year for 1 to 10 users, and Service Collection Standard is $750 a year for 1 to 3 agents. All figures are Atlassian's own price tables, checked in September 2026.
Here is what that means for a typical B2B software company with 25 engineers and 6 support agents, all on Standard with monthly billing. Jira for the engineers is 25 × $9.05, or about $226 a month. Service Collection for the agents is 6 × $25, or $150 a month. That is about $376 a month for the pair, and the engineers do not need agent licenses and the agents do not need Jira licenses to work together.
Two thresholds are worth planning around. Service Collection Free stops at 3 agents, so a fourth agent moves the team to $100 a month on Standard. Jira Free stops at 10 users, and the eleventh user moves every user onto a paid plan. Price both products at next year's headcount, not today's.
Service Collection also carries usage-based lines on top of seats. Assets objects beyond the included allowance are billed from $0.02 per object per month, the virtual service agent on Premium includes 1,000 assisted conversations a month and then bills from $0.30 per conversation, and CSM's AI agent is billed at $1.00 per resolution with no included allowance. None of these apply until you use the feature, but forecast them if AI deflection is part of why you are buying.
Who Needs Which License
Only agents need a Service Collection license. Customers are free, and developers work on their existing Jira license. Licensing is where most Jira vs Jira Service Management evaluations go wrong, because the intuitive answer, that everyone who touches a request needs a seat in the service desk, is not how Atlassian licenses it.
Agents need a Service Collection license
Anyone who works the queue, sees SLAs and reports, replies to customers, or manages the knowledge base is an agent, and agents are the only people Service Collection bills for.
Customers are free and unlimited
People who raise requests through the portal, email, or a widget, track their own requests, and read help articles never need a license. Atlassian's Standard plan supports unlimited customers.
Developers can be collaborators on their Jira license
A user with a Jira license can join a service space as a collaborator. Collaborators can view requests, add internal comments, attach files, watch, and log work. They cannot work queues, see SLAs, change a request's status, or reply to the customer.
Agents can work in Jira without a Jira license
Agents can view, comment on, and transition Jira work items on the same site by default. Atlassian states plainly that you do not need the same number of Jira and Service Collection licenses.
One detail catches teams out. Out of the box, ordinary Jira users cannot see or comment on service requests at all. An admin has to grant them permission to browse and comment, and even then their comments are internal only. That is deliberate. The customer-facing voice belongs to the agent, and engineering stays behind the internal line.
Jira Service Management does not bill for the people who ask or the people who fix. It bills for the people in between.
How Jira and Jira Service Management Work Together
Jira and Jira Service Management connect natively through linked work items on the same site. For teams that run both, the connection is the strongest argument for staying inside Atlassian, and it is worth describing accurately.
- 1
An agent confirms the request is a bug
The request arrives through the portal, email, or chat, and the agent works it in the queue like any other request.
- 2
The agent creates a linked Jira work item
From the request, the agent uses Create linked work item to open a work item in the engineering project, on the same site, with no integration to install.
- 3
Engineering works the linked item
Developers never touch the request. They work the linked item in their own board and workflow.
- 4
Automation updates the request
Service spaces ship with an automation rule, "Update when a linked work item changes", which comments on the request when the engineering item progresses. It can be extended to close the request automatically when the fix is resolved.
Two honest caveats. First, the status update is an automation rule, not a native two-way sync, so it does exactly what the rule says and nothing more. Teams usually extend it, and anyone who edits the engineering workflow can quietly break it. Second, resolved in engineering is not the same event as fixed for the customer. If your workflow marks the item done when code merges rather than when it ships, the automation tells the agent too early, and the agent tells the customer too early. Decide which status counts as fixed before you wire the rule. The bug triage guide covers how to set that line.
JSM, CSM, and External Customer Support
Atlassian now steers external customer support to Customer Service Management rather than Jira Service Management. Many searches for this comparison are really asking whether customer support for a software product should run in Jira Service Management.
Until 2025 the answer was "it can." Atlassian documented external customer service spaces, and plenty of B2B software companies ran support in Jira Service Management because escalation to engineering was native and agents were cheap. Those setups still work, and sites created before October 10, 2025 keep their customer service features.
In 2026, Atlassian's own positioning has moved. Its product page frames Jira Service Management as AI-powered ITSM for incident response, change management, and request fulfillment, and it describes Customer Service Management as the purpose-built product for external customers. CSM adds omnichannel intake including voice, customer and organization profiles, an AI agent, and a developer escalation that sends a conversation to a Jira inbox. Because both come in Service Collection, a new team choosing Atlassian for customer support gets CSM and Jira Service Management under the same license.
That is a reasonable package. It is also a full help desk, in the same category as Zendesk or HubSpot Service Hub, and it should be evaluated against them rather than against Jira. If you are weighing Atlassian's service desk against Zendesk specifically, the Jira vs Zendesk comparison covers that head to head, and Zendesk alternatives covers the wider field.
When You Need Neither
Plenty of teams landing on this question do not need Jira Service Management or CSM, because they already have a service desk. Their customers already write to support in HubSpot, and the customer's account, contacts, and deals live on the same record. What they are missing is not a second help desk. It is the handoff from a support ticket to the Jira work item where engineering fixes the bug.
Adopting Jira Service Management to get that handoff means running two support tools and syncing between them. The Jira Service Management HubSpot integration guide walks through why that setup usually disappoints. The shorter path is to connect the support tool you have straight to Jira.
If that tool is HubSpot, there are two ways to do it. HubSpot's own Jira integration creates or links a Jira issue from a ticket, but HubSpot's documentation says syncing between the ticket and the issue can take from one to twenty-four hours, comment sync has to be switched on for each ticket, and Jira status arrives as a read-only property. That is workable for occasional escalations and thin for a team that escalates bugs every day.
IssueLinker was built for the second way. From the HubSpot ticket, support creates a Jira work item in one click, drafted from the ticket conversation, in the Jira project where engineering already works. Comments sync both ways on every linked ticket with no per-ticket switch, and Jira status flows back to the ticket as it changes, so support sees the fix land and replies to the customer on the right day. Engineers stay in Jira and support never needs a Jira login. It works on any HubSpot plan, and seats are never counted. Setup is covered in the Jira HubSpot integration guide.
Support in HubSpot, engineering in Jira, nothing in between
IssueLinker links HubSpot tickets to Jira work items and syncs comments and status both ways, so support sees the fix the moment it lands without a second help desk. Flat monthly price, unlimited users, setup in about fifteen minutes.
Which One to Pick
Engineering, product, or project work that the team plans for itself. Nobody outside the team files requests into it, or requests arrive through a support tool you already run and connect to Jira.
IT, internal operations, or technical customer support where requests need a portal, queues, and SLAs, and many of them end in an engineering fix. Escalation to Jira is native, developers need no agent license, and CSM is included for external customers.
Your support team, customer records, and SLAs already live somewhere else. Adding Jira Service Management would be a second help desk. Connect the one you have to Jira instead.
The mistake to avoid is treating Jira Service Management as an upgrade to Jira. It is not a bigger Jira. It is a different product for a different job, which happens to share Jira's engine. Ask who creates the work. If it is the team, you need Jira. If it is someone asking the team for help, you need a service desk, and the only open question is whether that service desk should be Atlassian's or the one your customers already use.
