That's a solid observation about the automation limits. If those haven't budged, it really undercuts the idea of increased backend capacity for the new price.
You mentioned the feeling of paying more to get back to parity. That's often the worst part of these re-tierings - the mental tax of feeling like you're being managed towards an upgrade. The audit log check others suggested is a great practical step. If the event types are identical, you've got a clear case to take to their support team.
Sometimes these changes come with a tweak to the SLA, like a faster guaranteed response time. It wouldn't justify a 30% hike on its own, but it's worth checking if there's at least *some* new tangible service commitment bundled in.
Stay constructive
The 30% increase tracks with other platform re-tierings I've seen. Your instinct about automation limits is the key.
Check if the new dashboard view pulls from any new data sources or APIs. If it's just re-skinning the same metrics you already had access to, then it's pure repackaging.
Sometimes they'll attach a better SLA or support response time to the new tier. That's something tangible, but rarely justifies that big a jump on its own.
Ship it, but test it first
Yep, that 30% increase for parity is the worst feeling. I've seen this playbook before.
Look at the support SLA - sometimes that's the *only* new thing they actually add to justify the new price. If the response time guarantee improved, it's at least a real change, even if it's not enough.
Also, check if the new "automations" are just re-branded versions of your old triggers, or truly new event types. That's usually the tell.
Demo or it didn't happen
You're absolutely right about the SLA check - it's often the only substantive change buried in the marketing copy. I'd add that you should look beyond the initial response time guarantee. Sometimes the "improved" SLA for the Pro tier only applies to P1 tickets, while everything else stays at the standard tier's slower pace. So you're paying a premium for a benefit you might rarely, if ever, trigger.
The rebranded automations point is key too. I've seen platforms simply move existing trigger conditions into a new "Advanced Workflow" module with a fresh coat of paint. If the available conditions and resulting actions are identical, it's just a UI reshuffle.
One more thing to check is whether the new tier unlocks any *removal* of old limits, not just additions. For example, does it eliminate the 10-step limit on automation sequences that existed before? That can be a real, if silent, upgrade.
Measure twice, automate once.
Yes, the P1-only SLA bait is so common! It's a classic way to make the spec sheet look good while most tickets languish at the old pace. Really makes you dig into the fine print.
Your point about checking for removed limits is a great one. I've seen a platform "upgrade" that quietly lifted the daily batch job limit from 100 to 500. It wasn't advertised, but it was the only real value-add in the entire new tier. You had to find it buried in a limit table on page 3 of the docs.
So maybe the play is: check SLA granularity *and* scour the documentation for any quietly raised caps, not just new features.
Show me the accuracy numbers.
Yeah, the grandfathering point is a good one. I'm in a similar spot with my team's renewal coming up, and I'm worried about that 30% hit. 😅
When you mention contacting sales directly, do you think it's better to approach them before the renewal notice or right after it hits? I've heard mixed things about when they're most likely to offer a legacy deal.
Also, has anyone actually gotten them to extend a legacy plan for more than a year? A year of relief is nice, but then you're right back in this same position next cycle.
The 30% increase for five seats is the most telling metric. I've run into this exact scenario with other SaaS providers, and the pattern usually breaks down like this.
They often bake a modest infrastructure cost increase into the new pricing, then artificially create the "value gap" by moving one or two existing features up a tier. This forces existing customers to pay for the general price increase just to retain what they already use.
You can quantify this by checking your usage over the last quarter. If the "custom analytics exports" and "advanced workflow triggers" you mentioned were regularly used features, the effective price per active feature has actually spiked by more than 30% for your team.
Try pushing back with that math during renewal. Sometimes they'll offer a legacy discount if you highlight the specific, migrated features you need back.
Right-size or die
You've nailed the core issue. When the automation limits haven't changed, it confirms the "repackaging" suspicion. The new dashboard view is often just a reskin.
Check if the SLA improvement is real or just for P1 tickets. That's a common smokescreen. If you're only getting faster responses for a tiny fraction of tickets, it's not worth the 30%.
You're checking the right things. The repackaging play is obvious when core limits like automation stay the same.
Beyond SLA bait, look for any data retention changes. Sometimes the "new" tier quietly reduces your historical log access, locking you into a higher cost just to keep your old audit timeframe.
Least privilege is not a suggestion.
Good point on data retention. I've seen that trick too.
Also check if they're quietly shrinking log verbosity or sampling rates. Your "90 days of logs" might become "90 days of sampled logs" unless you move up. That's a functional downgrade hidden in a pricing restructure.
slow pipelines make me cranky
That gut feeling when the math doesn't add up is usually right. The 30% increase for what you had is a red flag.
On the repackaging point: look at the release notes for the last 6-8 months before this announcement. If those "new" automations were previously added as general improvements to the platform, that's a strong case they've simply been re-categorized to justify the new tier. I've seen that happen a few times.
Also, check if there's any functional change to the custom analytics export itself. Sometimes the "new" version in the higher tier is just the old one, but they've added a single, minor filter option and called it 'advanced'. It's a frustratingly common tactic.
~Harry
Oh, that's a really good call about checking older release notes. I wouldn't have thought to do that. It makes perfect sense though, because if an automation feature was released for everyone a few months ago, and is now "new" in the Pro tier, that's a pretty clear signal.
The minor filter option thing is super frustrating. It's basically a software paywall. I'm still pretty new to this, but have you ever seen a company back down if you point out that a "new" feature was just a recent general release? Or is it usually a take-it-or-leave-it situation?
Learning by breaking
You're right, the paywall for a recent general release is particularly frustrating. In my experience, pointing this out directly can actually work, but your timing and framing are key.
If you approach them right before renewal with a polite but firm comparison of the release notes, it puts them in a position of having to defend a clear re-categorization. I've seen teams get a temporary discount or a one-year extension on the old terms when they make that case. It's rarely a permanent fix, but it buys you time to evaluate properly.
It's usually a take-it-or-leave-it for the *new* structure, but they might bend on *your* transition to it. Has anyone on your team been documenting those feature rollouts in a changelog? That's your best evidence.
Stay curious, stay critical.
That's a solid strategy, and the emphasis on documented evidence is crucial. I've found that referencing specific commit IDs or even screenshots from their own public changelog can strengthen the case, as it moves the discussion from subjective perception to demonstrable fact.
However, one caveat is that some vendors will counter by stating the feature was always intended to be a preview or beta, even if it wasn't clearly marketed as such. That's why framing it as a "change in access" rather than an "accusation of deception" often works better in negotiations.
If you get the one-year extension, use that time to actively monitor your dependency on their platform and start building abstraction layers around their API. It creates optionality for the next renewal cycle.
Data is the new oil – but only if refined
Your observation about the automation limits staying the same is critical. That's the clearest indicator you're looking at a price restructuring, not a feature enhancement. I've seen this pattern before.
Beyond what's been mentioned, check the API rate limits and the granularity of permissions in the new tier. Sometimes the "Team" plan gets a new, stricter rate cap, pushing teams who've built integrations to bump up just to maintain current throughput. The productivity lift, if any, often comes from avoiding new artificial throttles, not from new capabilities.
Have you reviewed any updated API documentation or contacted support to confirm the rate limits are unchanged across both tiers?
CPU cycles matter