Atlassian does not charge a flat per-user rate. It charges in volume bands, where the published rate per user steps down as your count crosses defined thresholds, then flattens once you reach the largest bands. Those thresholds are the breakpoints, and understanding them is the difference between buying users efficiently and adding cost without lowering your rate. This explainer sits under our Jira Service Management pricing guide for 2026.
What a breakpoint is
A breakpoint is the user count at which Atlassian's published rate moves to a lower band. Below a breakpoint you pay the higher band rate on every user; cross it, and the lower rate applies. The practical consequence is that a count sitting just below a breakpoint pays more per user than one just above it, so the position of your count relative to the next threshold directly shapes your effective rate. The same step structure governs Jira Service Management agents specifically, explained in how Jira Service Management per-agent pricing scales.
| Position on the curve | Effective rate | What it means for you |
|---|---|---|
| Just below a breakpoint | Higher band | You pay more per user than a slightly larger buyer |
| Just above a breakpoint | Lower band | You have captured that band's benefit |
| Mid-band | Stable | Adding users does not change the rate until the next threshold |
| Top bands | Flattened | Further volume buys little additional saving on list terms |
Why the early breakpoints matter most
The steepest reductions sit at the early breakpoints. As your count climbs into the larger bands, each successive threshold delivers a smaller drop, and at the top the curve flattens almost entirely. This shape has a clear implication: a small or mid-sized buyer can meaningfully lower its rate by crossing an early breakpoint, while a large buyer near the top gets very little from further volume and must look to a negotiated agreement instead. The flattening is the signal that list-price volume has run its course.
How to use the breakpoints as a buyer
Three uses follow directly from the structure. First, before adding users, check where the next breakpoint sits, so a planned increase that lands just short of a threshold can sometimes be sized to cross it efficiently rather than stall just below. Second, if your count sits just under a breakpoint, that is itself a negotiation point, evidence for a rate concession rather than a reason to over-buy users you do not need. Third, once you are in the flattened top bands, stop chasing volume discounts and start negotiating the agreement, because that is where the remaining value is. Benchmarking your effective rate against comparable deals, the discipline in the complete guide to ITSM pricing benchmarks, tells you whether your band rate is genuinely competitive.
Our gated Jira Service Management Negotiation Guide includes the breakpoint map and the volume model we use to size an Atlassian commitment around the thresholds.
Model the breakpoint before you commit
The single most useful preparation is a short model showing your total cost at your current count, just below the next breakpoint, and just above it. That picture tells you whether a planned increase is a step down the curve that lowers your effective rate or a flat addition that simply costs more. Buyers who add users reactively, without checking the thresholds, routinely either miss a chance to cross a breakpoint efficiently or commit just below one and pay the higher band rate on every seat. Running the model first turns volume growth from a cost you absorb into a decision you control, the same right-sizing discipline we apply in how to right-size Jira Service Management agents.
Breakpoints across products, not just one
A subtlety that catches large Atlassian buyers is that the volume bands apply within each product, so your Jira Software count, your Confluence count and your Jira Service Management count each sit at their own point on their own curve. An organisation can be comfortably into a low band on one product while stranded just below a breakpoint on another, paying the higher rate on every user of the second. Looking at the estate product by product, rather than as a single number, reveals where a modest, genuine increase on one product would cross a threshold and lower its rate, and where a product is sitting inefficiently just under a band. This product-level view is also what makes a consolidated negotiation possible, because once you can see each curve you can argue for treatment of the combined commitment rather than accepting each product priced in isolation.
It is worth noting that the published breakpoints describe list behaviour. Once a deal is negotiated, the effective rate can diverge from the band structure entirely, which is why understanding the breakpoints matters most for small and mid-sized buyers and why large buyers should treat them as a starting reference rather than the final word on what they will pay.
For planning purposes, the most useful habit is to record where each product sits relative to its next breakpoint and to revisit it whenever a material change in headcount or scope is on the horizon. A reorganisation, an acquisition or a new team rollout can move a product across a threshold in either direction, and knowing in advance whether that movement helps or hurts the rate lets you sequence the change to your advantage rather than discovering the cost impact after the fact. The breakpoint map is cheap to maintain and repeatedly useful, because it turns every scaling decision into one you can price before you make it.
Where this fits with our service
We map your position on the Atlassian volume curve and negotiate the rate where list pricing flattens, from the platform hub at Jira Service Management through our license optimization service, on fixed fee or gainshare with no fee unless we save you money. Across more than 500 engagements and over 420 million dollars of ITSM contract value negotiated, our average reduction is 30 percent, and on Atlassian the saving comes from sizing the commitment around the breakpoints and negotiating once the list curve runs out.
Frequently asked questions
- What are Atlassian volume pricing breakpoints?
- They are the user counts at which Atlassian's published per-user rate steps down to a lower band. Below a breakpoint you pay the higher band rate on every user; crossing it applies the lower rate, so your position relative to the next threshold shapes your effective rate.
- Do the breakpoints keep lowering my rate as I grow?
- No. The steepest reductions are at the early breakpoints. Each successive threshold delivers a smaller drop, and at the top bands the curve flattens, so further volume buys little additional saving on list pricing alone.
- How should a buyer use the breakpoints?
- Check where the next breakpoint sits before adding users, treat a count sitting just below a threshold as a negotiation point, and once in the flattened top bands stop chasing volume and negotiate the agreement instead.
Size the deal around the breakpoints.
We map your position on the Atlassian volume curve and negotiate where list pricing flattens. Fixed fee or gainshare.
Book a Jira renewal review →