I discovered something today that, while technically permitted by our platform's pricing model, has created a significant administrative burden for our integration team. It is indeed possible to have a single team subscription where some users are on a Pro plan while others are on an Enterprise plan. The sales engineering team confirmed this is a supported configuration, designed to accommodate teams where only a subset of members require advanced features like custom data retention policies, advanced SSO, or higher webhook concurrency limits.
However, the implementation is where the complexity—and the "nightmare"—truly begins. The billing system does not treat this as a single, coherent subscription with two seat types. Instead, it creates two separate subscription line items on the invoice, each with its own proration cycle and renewal date. This leads to several operational challenges:
* **Invoice Fragmentation:** Our monthly invoice is now a document with multiple line items for the same service, making cost allocation and internal chargeback a manual, error-prone process.
* **Proration Chaos:** When we need to add a new Enterprise user mid-cycle, only the Enterprise line item is prorated. If we also remove a Pro user in the same transaction, that is handled on a separate proration calculation. There is no netting across the two seat types.
* **Access Management Overhead:** User provisioning is not unified. The admin panel requires you to assign the specific plan tier to each user, and there is no bulk "downgrade/upgrade within team" function. We manage this via the API, which adds another layer of necessary automation.
```json
// Example of the API call needed to change a user's seat type within the team.
// This must be done before the billing change can be correctly applied.
PUT /api/v1/team/{teamId}/users/{userId}
Authorization: Bearer {admin_token}
Content-Type: application/json
{
"seat_type": "enterprise" // or "pro"
}
```
The core issue is a disconnect between a flexible feature-access model and a rigid billing infrastructure. From an integration consultant's perspective, this mixed-seat approach is logically sound for cost optimization, but the resulting need for custom scripts to track seat changes, reconcile invoices, and sync statuses with our internal HR system has eroded much of the projected savings in productivity.
I am now evaluating whether consolidating onto a single tier—despite the cost increase for some users—would be more efficient when factoring in the hidden administrative tax. Has anyone else navigated this specific scenario and developed a streamlined approach, perhaps using a middleware platform like Workato or Zapier to synchronize our internal directory with these seat assignments and forecast billing changes? I'm particularly interested in the webhook events emitted for subscription changes; the documentation seems unclear on whether seat-type switches trigger a `subscription.updated` event.
- Mike
- Mike