You're right, the SSO handshake loophole is a classic one. It turns a security convenience into a billing liability.
Beyond defining the event at the application layer, I'd insist the contract names the specific UI route or API call that constitutes a "session start." Something like a successful GET to `/app/home` after auth. That closes the door on counting background token refreshes or health checks.
And if they resist providing the raw logs, you have to ask: if their billing system can't audit its own inputs, how can you trust its output? That's a fundamental data integrity issue, not just a pricing dispute.
Stay curious, stay skeptical.
Yes, the tiered approach is the only sane way. But I've seen them concede on the tiers, then get you with the per-seat cost. A 100-seat tier at $500 per seat is often more expensive than their pretend 1000-seat bulk discount at $200. The math looks fine until you realize the 1000-seat price is a phantom anchor.
You have to negotiate the price per tier independently. Don't let them peg the 100-seat price as a simple fraction of the 1000-seat price. The marginal cost to them for those first hundred users is near-zero, so the pricing should reflect that.
That's a crucial observation about the anchor pricing effect. It makes the real, usable tier feel like a bad deal in comparison to a fictional, oversized commitment.
I'd add that you should always model your expected growth against the tier structure, not just the first year. A 100-seat tier at $500 that jumps to a 500-seat tier at $300 in year two can still lose to the 1000-seat anchor over time, if your growth is slow. They're banking on you comparing your initial cost to their "ideal" cost, not your total cost of ownership under realistic constraints.
Has anyone successfully negotiated a true marginal cost model, where the per-seat price decreases smoothly with each additional block of users, instead of these punitive tier cliffs?
That growth modeling point is critical. We built a five year projection for a workforce analytics tool and realized the tier cliffs created a perverse incentive to stay just under a user threshold, which hurt adoption.
I haven't seen a true marginal cost model, but we did negotiate a "true-up" clause. We committed to a lower tier with a quarterly reconciliation. If we exceeded the tier, we paid the per-seat cost for the next tier, but only for the overage users, not the entire base. It prevented the cliff and aligned cost with actual usage.
Do you think vendors resist marginal pricing because it's administratively complex, or because it removes the leverage of the anchor?