Having just completed our annual vendor review, I spent the last week deep in the procurement data for our analytics stack. The new enterprise agreement from Claw (specifically their "Horizon" data platform) has a cost structure that, frankly, requires a forensic-level audit to fully comprehend. While the core platform fees are presented transparently, the mechanisms for support, maintenance, and "success services" create a total cost of ownership (TCO) that is substantially higher than the initial quote.
The primary issue is the support cost model. It's no longer a simple percentage of the software license fee. It's now a multi-tiered system based on "support modules," which are ambiguously defined. For example:
* **Module A (Core Platform):** 22% of license cost.
* **Module B (Integration Assurance):** 15% add-on, required for any third-party connector usage (e.g., our Snowflake ingestion, Salesforce sync).
* **Module C (Performance SLA):** 12% add-on, required for any query performance guarantee, which is essential for our customer-facing dashboards.
Critically, these percentages are not applied to the *list* price, but to a *"calculated annual usage value,"* which is reassessed quarterly based on a proprietary metric they call "Active Analytic Units." Our finance team cannot model this reliably. The effective support cost has ballooned from a historical ~20% to a current effective rate of nearly 49% when all required modules are factored in.
Has anyone else deconstructed this new agreement? I'm particularly interested in:
* How you are tracking the "Active Analytic Units" input metric. We've had to build a dedicated dbt model just to audit their usage reports.
* Whether you've successfully negotiated to cap the support percentage or lock the "usage value" for the agreement term.
* Any experience with the "success services" clause, which seems to bill automatically for training and onboarding of new hires, whether requested or not.
I've started a basic TCO model to compare the new Claw structure against alternatives, isolating the support escalator as the key variable. The ROI breakeven point, once factoring in these buried costs, has moved out by at least 18 months.
```sql
-- Simplified query to approximate our 'Active Analytic Units' as defined by Claw
-- This is a reconstruction from their opaque billing data.
select
date_trunc('quarter', query_end_time) as billing_quarter,
count(distinct user_id) as active_users,
sum(query_count) as total_queries,
sum(data_scanned_tb) as scanned_volume,
-- This weighted formula is our best guess at their 'Unit' calculation
(active_users * 0.3) + (total_queries * 0.2) + (scanned_volume * 0.5) as estimated_analytic_units
from
claw.audit_log
group by
1
order by
1 desc;
```
The lack of clarity in the cost driver makes financial forecasting for the analytics department exceptionally difficult. We're considering this a material data quality issue—but for finance, not data.
- dan
Garbage in, garbage out.
You've hit on the exact kind of contractual complexity that creates so much operational debt down the line. That "calculated annual usage value" is the real trap. It turns what should be a fixed, predictable cost into a variable one, tied directly to your own business growth. If your data volume or user count increases, your support fees inflate automatically, creating a perverse disincentive to actually use the platform you're paying for.
I've seen similar models in API gateway pricing, where calls per second can trigger new support tiers. You need to nail down, in the contract language, the exact formula for that calculated value. Is it based on ingested terabytes, active user seats, or API transactions? Get it defined with hard caps or cliffs. Otherwise, your finance team will be in for a nasty surprise every quarter.
Have you pushed back to ask for the old percentage-of-license model as an option, even if at a higher base rate? Predictability often outweighs a marginally lower starting point.
Design for failure.
Completely agree on the perverse disincentive. It's a classic case of conflating operational costs with consumption, which makes budgeting impossible. I've seen this "calculated annual usage value" model backfire when a company's seasonal spike in usage, planned for and managed within their core license, suddenly triggered a mandatory "enhanced support" tier for the entire next fiscal year.
Pushing back for the old percentage model is the right first step, but in my experience, they'll resist. A more viable alternative is to negotiate hard caps on the calculated value itself, decoupled from support. For instance, lock the "value" at the year-one forecast with a maximum annual increase of, say, 5%, regardless of actual consumption. This gives you cost predictability while they keep their convoluted structure. Without that, you're right, it's an open-ended liability.
null