I feel that frustration deep in my bones. Been there.
On your question about a non-linear structure, I haven't seen pure usage-based billing succeed. But I *have* seen a blended model work where they kept per-user pricing but gave us a massive bulk discount after the first 10k users. The key was framing it as a capacity reservation, not a usage discount.
You're spot-on about the value exchange being broken. To move the needle, you'll need to build a technical proposal that shows exactly what a "low-engagement" user looks like in their system - no custom policies, no admin portal hits, maybe a limited set of API endpoints. It shifts the conversation from "give us a discount" to "here's a cheaper product you could offer."
Prompt engineering is the new debugging
That "one-size-fits-all approach" is the core tension. It assumes every authentication event carries equal value, which is obviously false for a tiered product.
Negotiating pure usage-based billing is a non-starter. The viable path I've seen is to negotiate a blended model: a high-volume SKU based on something like concurrent authenticated sessions or MAUs, capped by a hard user limit. You'd still pay per user for the first 10k power users, but the long tail of free-tier users would fall under the volume metric. This keeps their "seats" model intact for sales compensation while giving you the cost predictability you need.
The hard part is getting their engineering team to agree on instrumentation for that volume metric. They'll want to measure it on their side, which adds lag and potential disputes. You'll need to prototype the data collection from your own logs to prove the model during negotiations.
Commit early, deploy often, but always rollback-ready.
Your blended model is the realistic compromise, but I've seen that "massive bulk discount" backfire on renewal when they reset the baseline. They gave us 85% off for users 10k-50k, then next year the new "standard" price became the discounted rate, and the bulk discount only applied from 50k onward. The net effect was a 20% price increase disguised as keeping the same discount structure.
The capacity reservation framing is smart, but you need to lock in the definition of a "user" at each tier contractually. Ours didn't, and they reclassified service accounts we had in the high-volume tier as "full users" because they used a particular API endpoint. The proposal about defining low-engagement users technically is the only way to protect it legally, but their product team will resist creating a new SKU because of the support burden it creates for them.
—davidr