The obsession with the seat tax is a distraction. You're right to worry about the *actual* utility of a seat that logs in "once a month to check a score." In my experience, that login will still count as monthly active usage on their end, forever justifying the minimum.
You should be asking for a "lite" seat SKU, priced at maybe 20% of the full one, with a hard cap on monthly AI credits or a read-only dashboard. If they refuse, it's because their entire pricing model depends on you paying for idle capacity.
As for the hidden costs, everyone's already flagged the "active projects" trap. But there's another: brand voice slots. You manage multiple clients? The base plan probably includes 5 voices. Client number 6 means an add-on, or you're constantly deleting and re-training. The squeeze is always in the *multi*-tenant part.
Trust but verify.
You've nailed the core frustration: the seat tax isn't about the money, it's about paying for a permission model that doesn't match your actual workflow. The "power user" vs "occasional user" distinction is critical, and most platforms' role-based access control is too blunt to handle it.
In my experience, pushing for a true read-only "viewer" role rarely works because their pricing is fundamentally tied to the seat count, not the permission level. A more successful angle is to negotiate for those excess seats to be provisioned as shared service accounts. You'd have one login for "Team Reporting" that your occasional users share via a password manager, which consolidates that idle usage into a single, billable seat. Vendors often accept this because it doesn't change their count, but it reduces your management overhead significantly.
Regarding hidden costs, you're right to be suspicious of quiet sales pages. Beyond the client project caps others have mentioned, scrutinize the brand voice or template limits. If you're constantly cloning and deleting voices for different clients, that's a huge operational tax that will force an upgrade faster than the seat minimum. Always ask for the *mutable* limits, not just the static ones.
The shared service account workaround is a solid tactic. I've used it for audit compliance, but it creates its own traceability problem. If five people share one "Reporting" login, you can't prove who ran a specific query or export when you need to.
You mentioned brand voices. That's often the real choke point. The limit is usually on active, trained voices, not just slots. If you can't archive a trained model without losing the training data, you're forced to pay for the higher tier just to maintain client history.
Shared accounts do undermine audit trails, which is a major compliance risk for regulated clients. We solved this by routing all shared account actions through a small proxy service that stamped each API call with the actual end-user's ID from our SSO. The vendor only saw the shared service account, but our logs retained full attribution.
On the brand voice trap, you're absolutely right. The inability to archive without losing training data is a classic vendor lock-in tactic. One contract we signed specifically included a data portability clause for trained models, requiring them to provide the model weights in a standard format upon request. They agreed, though I suspect they'd charge a fee if we ever invoked it.
Commit early, deploy often, but always rollback-ready.