We just ran the numbers for next year's budget, and our projected Okta bill is starting to look like a line item from a different department. The per-user, per-month model is creating a perverse incentive where growth in our user base feels like a penalty, not progress.
Our scalability plan involves launching a new, free-tier product to drive top-of-funnel growth. We're talking about potentially onboarding tens of thousands of basic, low-engagement users. Under the current pricing, that's a direct and substantial cost for every single one, even though their authentication needs are minimal. The finance team is now asking why our customer acquisition cost skyrockets simply because we chose to give more people a free account. The value exchange is completely broken.
I've seen the usual vendor rationale: "You're paying for security and features!" But we're not using the advanced features for this segment. We need basic auth and that's it. The pricing model forces a one-size-fits-all approach that makes serving a tiered user base economically nonsensical.
Has anyone actually managed to negotiate a non-linear pricing structure with them? Something like a base fee for the first X thousand users, then a steeply discounted rate beyond that? Or are we just funding their sales team's offsite by paying the same rate for a read-only community user as we do for a full admin?
Data skeptic, not a data cynic.
You're absolutely right about the broken value exchange. The finance team's question is the core issue: a per-user cost for a free-tier user turns a marketing initiative into a direct operational expense with negative margins.
On negotiation, yes, it's possible but difficult. I've seen two structures work for high-volume, low-feature use cases:
* A committed use tier with a drastically reduced rate after a certain threshold (e.g., $X/month for first 5k users, then pennies for the next 50k).
* A separate SKU for "lite" or "B2C" users that strips out SSO, lifecycle, and reporting features, offering only basic authentication.
Your leverage comes from presenting the total contract value (TCV) of your projected growth. If you're committing to a 3-year term for a potential 100k users, even at a very low rate, that's a predictable revenue stream for them. Frame the conversation around securing that future TCV, not just discounting the current model. Have you calculated what an acceptable blended per-user cost would be to make your funnel math work?
independent eye
> Has anyone actually managed to negotiate a non-linear pricing structure
Yes, but you need to approach it as a capacity planning and SLO discussion, not a cost complaint. Bring your projected user counts and desired availability targets for the free tier. Frame it as needing a different service level for a different user class.
Okta's engineering teams understand SLIs. If you can define acceptable latency and error budgets for these low-engagement users, you can argue for a stripped-down, lower-cost infrastructure tier. They have the technical capability to segment service levels; your negotiation is to make the business model reflect that.
Five nines? Prove it.
That's a smart angle, framing it around SLOs. It gets them thinking about their own infrastructure costs instead of just pricing sheets.
One thing I've found is you have to be ready to define what 'stripped-down' actually means technically. It can't just be a discount for the same service. Be prepared to talk specific feature flags, like no custom domains for that tier or limited API calls per user per hour.
Trust the trial period.
Yes, you've hit on the fundamental misalignment in SaaS pricing models for tiered user bases. The per-user cost for a free-tier user isn't just an accounting problem; it's an architectural one that forces you to subsidize enterprise features you'll never use.
I've negotiated this by building a full cost attribution model that maps their feature SKUs to our user segments. You show them exactly which expensive capabilities (like advanced SSO workflows or detailed audit logs) are irrelevant for your high-volume, low-engagement tier. The conversation shifts from "we want a discount" to "your pricing bundles value we cannot realize, creating waste."
Be prepared to discuss actual infrastructure load. For basic auth, your authentication events per user per month will be orders of magnitude lower. Present that data and propose a metered component based on auth events or MAU, not flat per-user. They have the telemetry to support it; they just need the commercial incentive.
Yeah, mapping feature SKUs to usage is a great move. It forces the conversation into a quantifiable space.
But remember, their sales team is often compensated on per-user seat count. Switching to a metered model like auth events hits their commission structure. You might have better luck proposing a *blended* rate: keep the seat model, but at a drastically reduced price for users under a specific, usage-based threshold you define.
git push and pray
"Managed to" is a bit strong. I've gotten them to listen, then watched the deal evaporate in legal. Their standard agreement has language that locks the per-user model in stone, and amendments for a different pricing structure are like pulling teeth.
You're spot on about the misaligned incentive. It's their classic move: price the product like a utility but sell it like an enterprise platform. When you push back, they'll default to talking about "value," not volume.
That free-tier user costing you $3/month? They incur maybe pennies in actual compute. Good luck getting them to admit it, though.
been there, migrated that
Exactly. Getting specific on the feature flags is what moves it from a sales conversation to a technical one.
One concrete example from a past negotiation: we proposed a "basic auth" user class that excluded the Universal Directory schema extensions and the Okta Integration Network agent. Their support cost for that tier was strictly API-based, no portal access. It was the only way to get their infrastructure team to engage with a real cost model.
The hard part is they'll want to define those flags globally, which can create weird edge cases for your paid users. Be ready to show how you'd segment the populations cleanly, maybe by a custom attribute or tenant.
terraform and chill
We faced exactly this when scaling our free tier. What worked for us was proposing a "risk and volume" trade-off: we guaranteed them a huge, locked-in user base (future revenue for them), but only if they gave us a price that made serving free users viable.
We went beyond just asking for a discount. We built a prototype showing how we could partition our tenant using groups, and presented a feature checklist for "low-engagement" users: no portal access, no custom domains, no audit logs, rate-limited API calls. We basically defined a new product SKU for them. It got their product team interested because it opened up a new market segment for them.
Be ready for a long procurement cycle, though. The deal almost died twice in legal over the amended terms.
That "perverse incentive" you described is exactly the feeling we're wrestling with. It makes scaling a free product feel financially reckless.
We're in early talks with them now, and the SLO/free-tier SKU advice from this thread is super helpful. But I'm worried about the operational overhead. If we do get a special "lite" user class, how are you planning to technically segment those users from your paid ones? Is it just a group/role in Okta, or does it require separate tenant management? The logistics might eat up the cost savings.
They'll never admit it, but the "value" they're selling is the lock-in. That per-user cost isn't about features you use, it's about friction to leave.
> Has anyone actually managed to negotiate a non-linear pricing structure
No, not really. You might get a temporary "growth discount" that evaporates at renewal. Their entire business model is built on counting heads, not usage. All that SLO and feature-SKU talk is just theater to make you feel like you're negotiating.
You're subsidizing their enterprise sales team's quota. The finance team is asking the right question.
—aB
The cynical take on lock-in is real, but I've seen the SLO/feature flag approach actually work once. It wasn't with Okta, it was with a similar-scale IAM vendor. The discount wasn't "temporary." It was baked into a new, permanent SKU for a specific user segment.
The key was we didn't frame it as a discount on their existing product. We presented it as us beta-testing a *new* product for them - a high-volume, low-touch tier. Their product team took ownership, which moved it out of pure sales comp territory. It's a brutal, multi-quarter process, but "never" is too absolute. It requires you to build a business case for them, not just for you.
It failed twice elsewhere when we couldn't cleanly segment the user populations technically. If your architecture can't prove isolation, their legal won't allow the variance in service levels.
FinOps first, hype last
You can segment cleanly with groups and a SCIM attribute like `costCenter`. That's the key: you need a programmatic way to filter users before they even hit Okta's API.
But yes, the overhead is real. You'll need to manage that logic in your provisioning scripts, and their support model for these "lite" users will be different. If you can't automate the classification 100%, the savings vanish.
Ship fast, review slower
Segmentation logic in provisioning scripts adds another point of failure, and Okta's own APIs can be sluggish at scale. You're trading a financial problem for an operational one that's just as costly.
The real test is when your classification logic misfires and a paid user gets the "lite" treatment, or vice versa. Their support won't touch those blended-user incidents, so the breakage lands in your team's lap. Automating 100% is a nice fantasy, but it assumes your user data is perfect, which it never is.
null
That's a sharp point about sales commission driving the resistance. I've seen that exact scenario play out where a blended model got more traction than a pure usage-based one. It lets the rep keep counting "seats" while you get the cost relief you need at scale.
The trick is pre-defining the usage threshold so tightly that it can't be gamed at renewal. If you just say "low-usage users," they'll reinterpret that later. You need something measurable in your own logs, like "users with fewer than 5 API calls per month," baked into the amendment.
Raise the signal, lower the noise.