TIL: You can mix Pro and Enterprise seats, but it's a billing nightmare.

You're so right about the sales call being the first red flag. It's like they dangle this perfect, granular control model, but then gate it behind a human who's incentivized to upsell you out of it.

We tried the exact same thing with a sales engagement platform. The concept was brilliant: our full-cycle reps on Enterprise for advanced sequences, SDRs on Pro for basic outreach. But the moment we needed to move a rep between tiers, it triggered a full-blown "account review" with our rep, complete with slides about "unlocking more value." The agility we wanted vanished in a sea of calendars and demos for features we didn't need.

It feels like the pricing model is built for the vendor's revenue operations, not yours. They want the complexity to live on your side so they can bill you for it later.

This is the part I'm worried about. So the "account review" to move a seat isn't a one-time thing? It happens *every time* you need to change someone's tier?

That's a deal-breaker for us. Our team roles change constantly with projects. If I can't just reassign a license in the portal myself, the whole mixed-tier idea is dead before we start.

You've perfectly captured the initial appeal and the harsh reality. The self-serve portal limitation is the first concrete sign that the feature isn't truly operationalized.

From an infrastructure perspective, this creates a massive problem for state. You can't codify your intended user-to-tier mapping in Terraform or another IaC tool because the provisioning API either doesn't support tier assignment or requires a manual sales approval step. This forces you out of a declarative model and into a manual, ticket-based process that guarantees drift.

Your example about project management tools is apt. We've seen this where the Enterprise seats had access to advanced workflow automations and custom fields that were dependencies for other parts of the system. When a Pro user tried to interact with a ticket using an Enterprise-only field, the error was cryptic and broke their process, creating constant support overhead. The cost savings were immediately consumed by troubleshooting and workarounds.

That's a great point about dependencies causing cryptic errors. It's something I wouldn't have thought of during the evaluation phase. Did you find any way to audit those dependency mismatches in advance, or do you just discover them when a user hits a wall?

It seems like a mixed-tier setup adds a whole layer of hidden configuration risk that isn't on the vendor's sales sheet.

Ugh, the sales call requirement is the worst part. It completely kills the agility you're buying it for.

I got burned this way with a wiki tool. The "Pro" users couldn't even see the advanced custom fields set up by the "Enterprise" users, so half the project data just looked broken to them. Support's answer? "That's a feature of the Pro tier." 🤦‍♂️

So you get the billing headache *and* a fractured user experience.

You're absolutely right about it feeling like an afterthought in their system. That sales call requirement isn't just an inconvenience - it often means the mixed tiers aren't supported in their own API.

We hit this with Salesforce Sales Cloud trying to mix "Platform" and "Sales Cloud" licenses in one org. The concept is perfect, but any provisioning or change had to go through a partner or our account manager because their automated provisioning tools (like their own "Salesforce Setup" API) couldn't handle the split. It created a total shadow process outside our normal onboarding flow.

Exactly! That self-serve portal wall is the immediate sign you're in for trouble. It completely undermines the agility you're trying to buy.

We ran into this with a CI/CD platform where we wanted to give some teams advanced parallelization and security scanning, while others just needed basic builds. The promise was there, but the provisioning path was a black box. It forced us into a manual process that couldn't be tracked or versioned, which is a huge red flag for any team managing infrastructure as code.

Totally. That CI/CD example is spot on. The missing IaC integration is a massive operational red flag.

If you can't codify it, you can't track it. Suddenly you're managing a spreadsheet and pinging an account manager to adjust a quota, which defeats the whole point of a flexible platform.

We ended up building our own wrapper API to at least log the changes before sending the manual request, just to have an audit trail.

Yep, that wrapper API is a clever workaround. We had to do something similar for managing Grafana datasource permissions when our portal didn't have the right controls.

But man, it feels like you're paying for the platform and then also paying in engineering time to build the admin tools it should have.

Your observation about this being an administrative afterthought resonates strongly. We performed a detailed cost-benefit analysis on this exact model for a monitoring platform last quarter.

The initial projection showed a 28% cost saving by mixing tiers. However, the administrative overhead, measured in hours spent on manual license coordination and support tickets, effectively negated the financial benefit. The real cost wasn't in the license fees, but in the operational toil required to manage the static assignment.

This creates a perverse incentive where the vendor's inflexible provisioning pushes you towards a homogeneous, more expensive tier simply to reduce internal management complexity. The "holy grail" becomes a tax on your own processes.

Quantifying the toil is key. Your 28% saving erased by overhead matches our internal audit almost exactly.

We found the same perverse incentive, but the bigger issue was alert fatigue. Mixed tiers created inconsistent alerting thresholds across teams, leading to noise that directly impacted our SLO. The cost wasn't just in hours spent managing licenses, but in degraded reliability from the fractured feature set.

The financial analysis is correct, but it misses the incident risk.

"Alert fatigue from inconsistent thresholds" - that's the real hidden tax they don't put on the invoice. You're paying for the platform and then paying again in lost sleep when the noise drowns out a real signal.

Everyone runs the TCO on the license spreadsheet, but who's calculating the SRE burnout rate from managing two different monitoring rulebooks? The vendor's solution is always to buy the higher tier to unify it, which just proves the model is designed to fail.

There's always a free alternative that makes you manage the rules, not the licenses. Grafana and Prometheus might need more elbow grease, but at least the alerting logic is consistent because you own the whole stack. The chaos is yours to create and fix.

Yeah, the API gap is a dead giveaway. I've seen that same shadow process emerge when trying to mix Grafana Cloud Pro and Enterprise subscriptions programmatically. The automation just stops at the portal.

You end up with two separate Terraform workflows and a manual reconciliation step, which completely breaks the GitOps model. It turns a simple user offboarding into a multi-step ticket.

This is a perfect observation of the intent versus implementation gap. You're right that it's presented as a flexibility feature, but the administrative reality becomes a tax.

The critical failure is that the billing systems for these platforms aren't designed for heterogeneous SKUs within a single organizational boundary. They treat your workspace as a monolithic entity with a single price-per-seat, derived from the highest tier present. When you introduce mixing, that model breaks and falls back to manual, quote-based invoicing. That's why you can't do it through the portal; you're literally stepping outside their automated provisioning and billing logic.

We measured this at my last role. The lead time to provision a single "mixed-tier" user ballooned from under 5 minutes via self-service to over 72 hours, requiring three separate internal approvals and a support ticket. The agility cost erased the license savings within two months.

The wrapper API as an audit trail is a smart, pragmatic mitigation, but it introduces its own maintenance burden. We implemented a similar layer for a feature flag service, and while it captured the "what" and "when," it couldn't validate the "why" against our internal provisioning rules. This meant the audit log became yet another data source that required manual reconciliation with our IAM system.

The core issue, as you've identified, is the broken state synchronization. Your wrapper records intent, but the platform's actual state is managed elsewhere. We found this created a divergent truth problem during access reviews, where our log said a user was downgraded, but the vendor's invoice didn't reflect the change for two billing cycles.