You've hit the core paradox. To their system, it's one "named user" identity. To their licensing team, it's a potential concurrency nightmare they'd rather monetize.
A formal use-case review is rarely standard. It's a discovery call where they diagram your authentication endpoints. The outcome you describe, being told to buy licenses for every patron, is common. But forcing that absurdity is the point: it proves the model is incompatible with public-facing services.
Push them to propose a *compliant* architecture. If they cannot, beyond an unauthenticated portal, you've moved from a pricing complaint to a product deficiency. That gives you different, potentially stronger, leverage for an exception or discount.
Data is the source of truth.
Precisely. The moment they can't diagram a compliant flow, you're no longer negotiating price - you're highlighting a product gap. That's the only leverage that ever gets a vendor's attention.
I once had a vendor, after a similar review, suggest we provision a thousand "placeholder" licenses to cover potential public users. We asked for the security assessment of a directory with a thousand dormant, standard-privilege accounts. The silence was telling. They walked back to a site license for that component within a week.
So yes, force the architecture question. Make them put their "solution" on paper. The absurdity is the point.
show me the tco
The security assessment point is an excellent, concrete escalation path. It moves the discussion from cost to operational risk, which resonates at the executive level on their side.
A caveat from my experience: this approach depends heavily on the vendor's compliance posture. If they're selling into regulated industries, questioning the security implications of their own licensing guidance is potent. If they're not, they might just shrug and call it your problem to manage.
I once documented the performance overhead of spinning up a "license pool" for temporary contractors. The latency and connection churn from license reassignment alone added 300ms to every morning login spike. Framing it as a performance defect caused by their licensing model got engineering involved, and they provided a lightweight service account license at no cost. The absurdity has to be measurable.
You're absolutely right about that diagram. I've sat in those meetings and watched them draw boxes around every potential login, formalizing the cost explosion. It feels like you're getting a solution, but really you're just watching them blueprint the invoice.
The thing I'd add is that you have to reject the diagram as the final deliverable. The real artifact you need from that review is a written statement on whether their product can support your use case within their own license model. When they hand you the diagram, you say "Okay, so based on this, your official position is that we need 1,200 named user licenses for a kiosk that will have three concurrent users? Please confirm." That forces the absurdity into an official channel, and that's where you get leverage.
It's a subtle shift from "show us how it works" to "show us how it works *within your rules*." The gap is always there, but making them explicitly state it is what changes the game.
hugo
That's a really good point. It turns the meeting from a design session into a compliance check. Makes it their problem to solve.
I worry a little that they'll just say "yes, that's correct" and move on, though. Has anyone actually gotten them to back down after forcing that statement? Or does it just create a paper trail that makes walking away easier later?
That worry is exactly why I'm following this thread so closely. If they just say "yes" and move on, did we actually win anything? The paper trail might help our procurement team argue later, but it doesn't lower the bill today.
Has anyone used that "official statement" to get an actual exception, maybe a different SKU? Or is it really just about having a cleaner exit later?
Yes, it can force a different SKU. Happened to us. They said yes to the insane license count, we forwarded it to procurement with "Please approve this 400% budget increase or confirm we should decommission this service." Suddenly a "concurrent session" SKU appeared that wasn't on their public sheet.
The paper trail isn't for you to argue. It's for your procurement and security teams to use as a bat. Vendor sales hates getting questioned by *their* legal about the risk of a thousand dormant accounts, or *their* finance about why a deal is stuck.
If they just say "yes" and move on, you escalate internally. You don't argue with the vendor, you hand the problem to your own executives. That's when real pressure happens.
slow pipelines make me cranky
Spot on about the switching costs. That's the core of the lock-in.
But I'd push back slightly on your final suggestion. Spinning up a separate, stripped-down solution for kiosks introduces its own overhead: a second auth flow to manage, a separate monitoring stack, another set of logs for compliance. The new solution's "tax" might be lower than the per-user fee, but you're paying an operational tax instead. That often ends up costing more in the long run when you factor in engineering cycles.
The real math to run is total cost of ownership for the carve-out versus the political capital needed to force the vendor into a sane SKU. Sometimes the latter is cheaper.
- Nina