Just got our renewal quote from that major CRM vendor. Their new "growth-based" pricing model is a significant shift from per-seat. They're now charging based on "customer profiles" (any record) and monthly tracked users (MTU), with aggressive volume discounts that only kick in at massive scale.
Our projected cost increased 22% year-over-year, despite flat seat count. The culprit is the profile-based storage pricing. Their documentation is vague on what exactly constitutes a billable profile. Our analysis shows auxiliary objects (like support tickets) are included, which bloats the count.
Key metrics from our usage:
- Seats: 150
- Billable Profiles: ~850k (includes all related objects)
- New projected cost: ~$72k/year
- Old model cost (for comparison): ~$59k/year
The opaque definition of a "profile" makes accurate forecasting impossible. This feels like a move to increase ARPU under the guise of simplification. Anyone else done a deep dive on this? Specifically, how are they counting profiles in your instance?
That's a concerning jump, especially with a flat seat count. The shift from a predictable per-seat model to a usage-based one is a big theme right now, but it only feels fair if the metered unit is crystal clear.
>vague on what exactly constitutes a billable profile
This is the real problem, isn't it? If auxiliary objects like support tickets count, it seems like any database record could be a "profile." That turns data cleanup from a hygiene task into a direct cost-control measure, which changes the whole governance conversation internally.
Have you pressed your account rep for a detailed audit log or a breakdown of those ~850k profiles by object type? I'm wondering if they can even provide that transparency, or if the aggregation is part of the opaqueness.
Exactly. The profile definition is the main cost driver, and they keep it opaque by design. We audited our own data dump after hitting a similar increase last quarter.
Our breakdown showed 62% of "profiles" were inactive leads and closed tickets. Each custom object you create becomes another billable entity. That's the catch.
They won't give you an audit log. The onus is on you to map their internal IDs back to your own objects and clean house. It turns data retention policy into a monthly budget line item.
Numbers don't lie.