Has anyone else here run into this? Our procurement team is pushing back on the OneTrust renewal, and I'm trying to build the case that the per-employee pricing model is fundamentally misaligned with value for technical teams focused on observability and data governance.
Our usage is almost entirely centered on automating compliance for our monitoring stack—think cookie consent for internal Grafana dashboards and data processing records for Prometheus metrics. The team using it is maybe five engineers. Yet, because the license cost scales with our total company headcount, which has grown with sales and marketing hires, our costs have tripled while our actual usage hasn't changed. We're essentially subsidizing other departments that don't even touch the tool.
It creates a perverse incentive. We want to expand automation for things like alert fatigue reduction by classifying incidents against SLO error budgets, but the cost of adding a single feature feels astronomical when viewed through the per-head lens. It’s like paying for a fleet of trucks when you only need a single toolbox.
I need concrete arguments. Has anyone successfully mapped their actual API calls, module usage, or data processing volumes to show the disconnect? Something akin to this:
```json
{
"licensedUsers": 1200,
"activeUsers": 5,
"primaryModules": ["CookieConsent", "DataMapping"],
"usageTrigger": "Automated pipelines, not employee logins"
}
```
How did you frame the value conversation? Did you find alternative pricing metrics (like events processed, APIs, modules) from competitors more palatable? Looking for any negotiation leverage or documentation approaches that worked.
owl
Per-user pricing is for collaboration tools. It's a garbage model for anything that automates infrastructure.
You need to show them the invoice for the last 12 months and the login report. If you have five active users and the cost is based on 500 employees, that's a 100x markup on actual usage. Procurement understands waste.
Pull the audit logs for API calls and logins. Graph it against the headcount growth. Show the flat line versus the skyrocketing cost. They'll get it.
Also check your contract for "indirect access" clauses. If sales people see a Grafana dashboard that had its cookies handled by OneTrust, the vendor might claim that counts as a user. That's the fight you need to have, because that's how they justify this model.
That's a really good point about the audit logs. I haven't checked ours yet, but I'm worried they'll point to those "indirect access" clauses. If a dashboard our team built is viewed by someone in sales, does that really make them a "user" of the compliance tool? That seems like such a stretch.
Is that kind of clause common in other platforms too, or is OneTrust particularly aggressive about it? Trying to figure out if this is a standard fight we'll have everywhere.
The point about wanting to expand into automation like SLO error budget classification perfectly illustrates the misalignment. Your cost of innovation becomes tied to an irrelevant macro metric, which actively discourages deeper, more valuable use of their own platform.
A concrete argument I've used is reframing the cost as a tax on data infrastructure, not a software license. Build a simple model showing cost per monitored system or per million API calls processed for governance, then show how that "unit cost" explodes under the per-employee model as headcount grows. Procurement responds to unit economics.
Regarding the audit logs, you must isolate administrator users from passive beneficiaries. Five engineers configuring rules are users; a salesperson viewing a compliant dashboard is a beneficiary of the output. That distinction is critical. If their contract blurs this, you're not buying a tool for your team, you're buying corporate insurance. That's a different budget line entirely.
Start with the question.