Concurrent AppPoints Are Not Automatically Cheaper

The short answer is no. Concurrent is not a discount. It is a bet on peak usage. It wins only when the number of people logged in at the same time stays well below your headcount, and for full-time shift crews it usually does not. I have watched teams plan a whole migration around "we run three shifts, so Concurrent will save us money," and that instinct is wrong often enough that it is worth taking apart.

Where the idea comes from, and why it is half true

Authorized and Concurrent are two ways to pay for the same access.

Authorized reserves points for a named person, whether they log in or not. You pay for the seat the way you pay for a parking space you rent by the year. It is yours even when the car is in the garage.

Concurrent draws from a shared pool, and only while a session is actually live. Nobody on, nothing drawn. So the intuition is reasonable: if not everyone is online at once, you pay for fewer of them.

Here is the catch that breaks the intuition. A Concurrent seat costs notably more per seat than an Authorized seat, on the order of three times as much depending on the tier. So you are not choosing between "cheap" and "expensive." You are trading "I pay for everyone, at the lower rate" against "I pay a premium for whoever happens to be on." That trade only pays off when few enough people are on at once that the premium is more than covered.

The number that actually matters is peak over headcount

Forget shift count for a second. The only ratio that decides this is your peak simultaneous logins divided by your named headcount. Call it the concurrency ratio.

Concurrent wins when that ratio is low. It loses when it is high. The break-even line, the point where the two cost the same, sits somewhere around a third of headcount for the middle tiers, and it moves depending on which tier the role sits in. Below the line, Concurrent is cheaper. Above it, Authorized is cheaper. To make that concrete: say a tier runs about three times as much per Concurrent seat as per Authorized seat. Then Concurrent only comes out ahead when fewer than roughly a third of that population is logged in at once, and the moment more than that are on, you are paying the premium for nothing. Change the seat ratio and the line moves with it. I am keeping this directional on purpose. The exact line per tier is in the calculator, because the precise number is what you actually build against, and a rule of thumb is what you reason with.

One more thing that quietly pushes your real peak up. A session that closes without a clean logout can hold its points for a stretch after the person walks away. IBM has put that window around half an hour, so check the current figure before you bank on it. The practical effect is the same either way: idle and abandoned sessions inflate your true peak. Plan for the messy peak, not the tidy one you drew on the whiteboard.

What three shifts actually does

Three clean, non-overlapping shifts, with everyone on the active shift logged in, puts your peak at roughly a third of headcount. Line that up against the break-even line and you land right on it. Three full shifts is the break-even case, not the savings case.

Directionally, here is how it shakes out across the tiers. A Limited crew comes out a little ahead on Concurrent. A Premium crew is about a wash. A Base crew can actually cost more on Concurrent than it would on Authorized. So the same shift pattern produces three different answers depending on tier, and only one of them is a win, and a small one.

It gets worse the moment shifts overlap, which they always do in real life. Handoff meetings, early logins, supervisors who span two shifts, the day-shift planner who stays late. Every bit of overlap raises your peak, and every point of peak makes Concurrent worse. So if you were counting on shift work as your savings engine, the engine is barely running, and a stiff breeze stalls it.

Where Concurrent genuinely wins

Not shift count. Low concurrency. The savings scale with how far your peak sits below your headcount, so the real money is in populations that are rarely all on at once.

Bursty or occasional users are the first place to look. Inspectors who work in waves, operators who file the odd request, contractors who log in a few times a month. A pool of people like that can peak at ten to twenty percent of headcount, and down there Concurrent beats Authorized comfortably at any tier. That is the prize, and it has nothing to do with shifts.

The strongest version of the argument is the shared pool across offset populations. For sizing, model the Concurrent draw as one shared demand across every population that can be on at the same time, not as separate role peaks added together. If your day techs, your night inspectors, and your weekend crews each peak at different times, your whole-org simultaneous peak is far below the sum of their headcounts. The more uncorrelated your intermittent populations are, the better Concurrent does, because their peaks never stack. This is the case where Concurrent earns its premium several times over, and almost nobody states it, because everybody is busy arguing about shifts.

This is also why Authorized versus Concurrent is a per-role decision, not a site-wide policy. You pick the access type role by role based on each role's concurrency, then you size the shared pool against your true org-wide peak, not the sum of the role peaks.

So what do you do differently

Stop treating Concurrent as a default discount. Treat it as a per-role bet on peak usage, and make the bet with eyes open.

For constant, high-concurrency roles, lean Authorized. Same for any role that cannot tolerate a blocked login. A control-room user or a tech who has to change a work order status right now should never get bounced because the pool was full. The few points you might save are not worth a blocked login at the wrong moment.

For bursty, occasional, seasonal, or offset many-shift populations, go find them and size them Concurrent. That is where the savings actually live. Then size the pool against the honest org-wide peak, idle sessions included.

I built a free Concurrency Calculator for exactly this decision. Put in a role's headcount, its tier, and your honest peak, the messy one with the idle sessions, and it shows you the Authorized cost, the Concurrent cost, and which side of the break-even line you land on. Run it on a role before you commit that role to Concurrent.

Frequently Asked Questions

Is Concurrent licensing cheaper than Authorized in MAS?

Not automatically. Concurrent is not a discount, it is a bet on peak usage. A Concurrent seat costs notably more per seat, so it only wins when the peak number logged in at once stays well below headcount. Above roughly a third of headcount on at once, Authorized is cheaper.

Does running multiple shifts make Concurrent cheaper?

Barely, if at all. Three clean non-overlapping shifts put your peak around a third of headcount, which is the break-even case, not the savings case. Any shift overlap raises the peak and makes Concurrent worse. Shift count is not the savings engine; low concurrency is.

What is the break-even point for Concurrent versus Authorized?

It sits around a third of headcount for the middle tiers, because a Concurrent seat runs on the order of three times an Authorized seat. Below that ratio Concurrent is cheaper; above it Authorized is. The exact line moves by tier, so model your real peak per role before committing.

Where does Concurrent actually save money?

In low-concurrency populations: bursty, occasional, seasonal, and offset users whose peaks never stack, like inspectors who work in waves or contractors who log in a few times a month. Model the Concurrent draw as one shared pool against your true org-wide peak, not the sum of role peaks.

Quick Maximo questions are always free. Reach out on LinkedIn. I never charge for chatting.