TIL some vendors charge for 'inactive users' - check your contract.

Oh, it's completely normal in the worst possible way. That "provisioned user" clause is the classic move. They're selling you seat licenses like it's still 1998 and you're installing Oracle on a Sun box. You pay for the name in the system, not the actual usage.

Your checklist is a good start. Let me add a few from the school of hard knocks:
* **Concurrent user limits.** You might get 10 "seats," but if the fine print says only 5 can be logged in at once, your ops lead gets locked out during the morning reporting scramble.
* **"Read-only" or "viewer" roles that still count as full-price seats.** Sometimes they're 50% off, which feels like a trick, not a deal.
* **API call limits** that are buried in the SLA doc, not the pricing sheet. Hit that limit and your automated dashboards break, or you get a nasty surprise on the next invoice.

Always, always get the full contract and SLA, not just the shiny marketing PDF. Search for "fee," "charge," "limit," and "minimum."

You're right to focus on that "provisioned users" line. It's incredibly common, especially in tools built for enterprise sales. They're counting on you setting up a few extra logins "just in case," and then you're on the hook.

Adding to your list, watch for **"instance" or "pod" fees**. Some vendors charge extra to spin up a dedicated environment for your data, which sounds secure but can double your bill without much added value.

The best defense is to push back during the sales call. Ask them to explicitly define an "active user" and if you can have a pool of licenses to assign, rather than named seats. They'll often have a process for that, but you have to ask.

That push for a license pool is such good advice. I've had success with that exact strategy when we were onboarding a new CRM. The sales rep initially said it was "named users only," but when we made it a sticking point, their solution was a simple quarterly true-up process. We just report who's actively using it and adjust the count. Saved us a few seats right there.

The "instance" fees are another trap, especially with customer data platforms or marketing automation suites. They'll sell it as a security must-have, but for a team under 50 people, a well-configured shared environment is often just as compliant. Always ask for the shared tier's security white paper before agreeing to a dedicated pod.

One thing I'd add to your list is to watch for "minimum commitment periods" on those user seats. Even if you drop from 10 to 5 active users, you might be contractually locked into paying for 8 for another year.

Spot on about the API call limits. That's where the real operational risk lives, far more than the user seat drama. A "provisioned user" is a predictable, fixed cost, even if it's infuriating. An opaque API quota is a variable cost tied directly to your business activity, and hitting it can cause an immediate outage.

You'll often find these limits defined in a completely separate document, like an "API Fair Use Policy," which isn't even part of the master service agreement. I've seen vendors throttle requests to a crawl instead of hard-breaking, which is worse because your data pipelines just silently degrade.

The concurrent user limit is another brutal one, especially for global teams. That "10 seats" becomes effectively 5 if your east coast and west coast analysts are working at the same time. Always ask for the concurrency model: is it named, floating, or session-based? The sales rep will know exactly what you're asking and it forces clarity.

You're right about the operational risk of API limits, but I think you're underselling the damage of the "provisioned user" model. A predictable cost can still be a fatal one for a growing company.

It creates a tax on experimentation. If you need to pay for every seat you provision, you stop giving access to that junior analyst who might find a killer insight, or to a contractor for a short-term project. It actively discourages broad adoption within your own company. An API limit is a technical problem you can monitor and scale for. The seat tax is a cultural poison that stifles usage from the start.

And let's not forget, that "predictable" cost only stays predictable if your team size stays static. Grow or restructure, and you're locked into renegotiating or paying for ghosts.

Ah, the quarterly true-up. That's the sales rep's favorite trick because it turns you into their accounts receivable department. You've now got to internally police usage and report on it, which most teams will forget to do after the first cycle. Suddenly you're paying for the "named" count again by default, and the process to reduce it is mysteriously cumbersome.

It can work, but you have to get the mechanics in writing: a clear definition of "active," a simple reporting format, and a guarantee the adjustment happens automatically upon your report, not after a "review period." Otherwise it's just a discount for the first quarter.

Oh, it's worse than normal, it's the entire business model. That "per user" line on the pricing page is the honey trap. The "provisioned users" clause in the contract is the spring-loaded bear trap you step in six months later.

You're thinking like an engineer - you want to give people access to data. They're thinking like a SaaS CFO - they want to bill for every entry in their `users` table, because headcount is the easiest vanity metric to sell to VCs. Your list is a good start. Let me add the one that burns me the most: **automated service accounts counting as users**. You set up a service account to pull data into your data warehouse nightly? Congratulations, that's a "provisioned user" and you're paying another full seat for a headless cron job. Always ask for an explicit carve-out in writing.

And on data export fees, don't just ask if they exist. Ask *how* they exist. Is it a per-GB charge? Is there a "convenience fee" for a full SQL dump versus their proprietary format? I've seen vendors charge more to get your own data out than they do to store it, which tells you everything you need to know about their opinion of vendor lock-in.

The mention of "instance" or "pod" fees really resonates with my own experience in the supply chain space. We looked at a logistics visibility platform last year that proposed a dedicated pod for our shipment data. The sales pitch was all about security and performance isolation, which sounded great. But when we asked for the specifics on the shared environment's architecture and compliance certifications, they were identical for all the standard SOC 2 controls. The pod felt like a pure pricing tier, not a technical necessity.

Asking for the pool of licenses is excellent advice, though I've found its success depends entirely on the tool's internal permission model. Some systems, especially older ones adapted for the cloud, have their billing tightly coupled to individual user IDs in a database. They physically can't do a floating license pool without a major re-architecting. The workaround I've seen is a manual de-provision/re-provision process that falls on the admin, which is its own kind of tax.

Do you think the push for a license pool works better with newer, cloud-native platforms?

The throttling vs. hard break distinction is so critical for data pipelines. A hard break at least triggers alerts. Silent degradation means your streaming aggregates are wrong for hours before anyone notices.

You've hit on a key question: always ask for the concurrency model. But I'd push further and ask *where* that limit is enforced. Is it at the load balancer, the application tier, or the database connection pool? The answer tells you if it's a genuine scaling concern for them or just a billing lever.

And on API quotas being in a separate doc, yes. Always insist the "Fair Use Policy" is incorporated as an exhibit to the main agreement, with clear notification thresholds. If they refuse, that's a major red flag for how they'll handle incidents.