Am I the only one who thinks the licensing model is too complex?

You're definitely not alone. It's complicated by design.

> Has anyone found a good way to simplify the model internally for budgeting?
Yes, we doubled the initial sales quote. It's never accurate because you'll inevitably need a connector or module you didn't anticipate. The "granularity of control" they'll pitch is just granularity of billing.

Ask them for a single, all-in annual cost for your current setup and projected growth. Watch them squirm. The complexity isn't for your control, it's for their revenue protection.

Oh, you are absolutely not alone! My team went through the same headache last year. The spreadsheet comment made me laugh because we literally built a massive matrix comparing the license SKUs to our org chart and forecasted need.

On your question about simplifying for budgeting, I ended up creating a "persona-based" bundle internally. For example, "Level 1 Help Desk" gets Remote Support only, "Infrastructure Admin" gets the platform plus the specific connectors for our network gear, etc. This helped our finance team see it as role-based costs, even though the actual invoice from BeyondTrust is still that complicated list. It's a translation layer.

I do think there's some justification for the complexity, but maybe not *this* much. Having the option to license a specific connector for a legacy system you only manage once a quarter is powerful for cost control. But it feels like it's tilted too far toward nickel-and-diming for every single capability. My tip for the sales conversation is to bring your persona map and ask them to price each persona as a single unit. They can still build it from their SKUs on the backend, but it forces them to give you a stable, predictable price per user type. Let us know how it goes

You are not alone at all. That spreadsheet feeling is a huge red flag in enterprise software. I've been down this road with other platforms and it usually signals that the vendor's internal product teams aren't aligned with how their software actually gets consumed.

On your question about whether the complexity is justified, I'd say it's partially justified, but not to this degree. The core idea of licensing the platform, then adding modules for Remote Support or PPM, makes sense from an architectural standpoint. It's like buying a Kubernetes control plane and then adding ingress controllers or service meshes as needed. But licensing *each type of connector* individually? That's where it feels like revenue optimization, not technical necessity. In a cloud-native world, you'd expect a connector framework with a single license for the capability to connect to things.

For the sales conversation, I'd recommend treating it like a technical discovery session. Come prepared with a matrix of your target systems (e.g., 200 Windows servers, 50 network devices, 30 cloud accounts) and ask them to map those directly to license SKUs and line-item costs. Demand they explain the technical constraint that necessitates a separate SKU for, say, an AWS connector versus an Azure one. Their answer will tell you everything about where the complexity is coming from.