Price Increase Experiments Without Losing Existing Customers

How the AI pricing shift is reshaping increases

SaaS vendors raised prices well ahead of broader inflation in 2025. Zylo's research found 79% of IT leaders hit a price increase at renewal in the past year. That's the baseline condition of running procurement in 2026, and most vendors are still executing it like renewal cycles work the way they did five years ago, before AI features got bundled into every plan.

Treating AI as invisible is the mistake underneath most of this year's price increases: vendors fold it into the base plan instead of pricing it as something customers choose, which is how the increase lands without anyone actually deciding on it. Vendors aren't pricing AI as a line item customers opt into. They fold it into the base plan and raise the plan price, so the increase lands without anyone choosing anything. The bill goes up. No one sends an email that says "this is a price increase," because technically nobody touched the sticker price. They just changed what's underneath it, and that's worse than a straightforward hike, because a customer who feels tricked churns harder than one who just feels overcharged.

Atlassian's structure shows how tangled this gets. Standard plans now include 25 Rovo AI credits per user per month, and its Virtual Service Agency layers on $0.30 per conversation once a customer exceeds that allotment. That's a subscription, a bundled entitlement, and a consumption overage, stacked into one contract. HubSpot runs a parallel model: $10 per 1,000 AI credits beyond the plan's allotment, billed as incremental usage that shows up mid-cycle rather than at renewal.

Zylo's research names the actual mechanism behind the bill shock: mid-term price changes on variable, consumption-based components adjust the invoice between billing cycles, with no renewal conversation to trigger a heads-up. There's no calendar event where the customer expects to hear from the vendor, so the charge just appears. Research found 78% of IT leaders reported unexpected charges tied to consumption-based or AI pricing models, a metering system with no warning built into it. That's a metering system with no warning built into it.

The Cursor incident is the sharpest illustration on record. A single developer's usage on an annually-billed plan burned through the allotment and generated an unexpectedly large bill that spread widely across social media. The developer read the plan. The plan just had no mechanism to warn anyone before the meter ran out. Fixing that isn't a matter of a clearer email. It takes decisions about metering, caps, and visibility made before the price ever changes, not after the invoice goes viral.

Treating a price increase as a controlled experiment, not an announcement

Zylo's research found that companies running pricing experiments on a regular cadence grow 25% faster than companies with static pricing. Only 24% of SaaS companies do this consistently. Most vendors still treat a price increase as one decision made once a year and rolled out to everyone the same Tuesday, which is closer to a coin flip than a strategy, and the gap between that 25% growth number and 24% adoption is sitting there unclaimed for anyone willing to run this differently.

Test new pricing on new customers first. Churn and conversion should be watched before that pricing ever touches an existing account. Only then does the increase move to the base, and even then it should move through a structured rollout, not a blanket announcement.

A real experiment has a few load-bearing pieces. New-customer cohorts absorb the new pricing before anyone else sees it. Existing accounts get grandfathering with a defined runway long enough that customers feel the change was handled fairly. Customers get segmented by how hard the increase hits them before a single email goes out. Usage data flags at-risk accounts before the change reaches them, not after. Communication leads with value delivered, never with the number.

L.E.K. Consulting reported that AI tools capable of reading customer behavior in real time and testing elasticity across segments make this kind of experimentation operationally realistic now in a way it wasn't previously. The cadence has picked up industry-wide too, with a large share of SaaS businesses adjusting pricing or packaging more frequently, many doing so on a quarterly basis. At that pace, the billing infrastructure produces the pricing outcomes just as much as the strategy does, and that's how tightly the two are linked.

Segmenting your customer base before the increase goes live

Not every customer feels the same increase the same way. A legacy account with heavy usage might see a jump that dwarfs what a new customer on standard pricing pays. Map that gap before any communication goes out. Discovering it afterward, through a support ticket, means the account is already halfway out the door.

Two thresholds are worth building process around. Larger increases warrant personal outreach and a phased transition rather than a form email. Steeper increases call for individual retention plans; Kyle Poyar, VP of Marketing Strategy at OpenView Labs, recommends stair-stepping these accounts up gradually rather than letting them absorb the full jump in one billing cycle.

Four things belong on the table before rollout starts. The exact dollar delta between legacy and new pricing, calculated per account rather than averaged across a segment. Usage patterns, since heavy users are often the safest bet while low-engagement accounts carry the highest churn risk regardless of how big the increase is. Contract status, mid-term versus approaching renewal. Revenue concentration, since a handful of large accounts deserve individual handling no matter what percentage they're facing.

What comes out the other end should be three separate lists: standard rollout, personal outreach, individual retention, each running its own timeline. None of this works without real-time usage data. A plan tier alone says nothing about actual consumption; billing infrastructure that surfaces account-level usage is what makes the segmentation possible.

Grandfathering logic (how to structure the runway without creating a permanent discount class)

Grandfathering means existing customers keep their current price for a set window while new customers land on the new pricing. Handled well, it's a transition. Handled poorly, it turns into a permanent two-tier system nobody planned for and everybody resents, including the sales reps stuck explaining it on every call.

The grandfathering window needs to be long enough that customers feel the change was handled fairly, yet short enough that the vendor isn't leaving revenue on the table indefinitely. Research citing a $49-to-$79 price increase, roughly 61%, found a churn rate of just 3.2% at the transition point, alongside substantial net revenue growth. A jump that large, given a real runway, barely moved churn.

Grandfathering breaks in three predictable ways. Leaving it open-ended with no stated expiration causes customers to start treating it as the permanent price, so they churn in anger when it finally ends. Roll it out without clear communication, and customers get blindsided by a changed invoice they were never told to expect. Applying it uniformly across every account gives the high-impact customers facing the steepest jumps the same treatment as everyone else, which defeats the entire purpose of segmenting them.

For those high-impact accounts, stair-stepping beats a cliff at the end of the grace period. Rather than one jump from old price to new, the increase runs in increments, the approach Poyar recommends for accounts facing the steepest jumps. Grandfathering buys time. It was never meant to replace the actual case for the price change, and the customer still needs a reason, coming from somewhere other than the runway itself, to believe the new price is fair.

Communication sequencing (what to say before you say the number)

The pricing announcements that land best don't open with the number. They start weeks earlier, reminding the customer what they've already gotten out of the product, before the price comes up.

The sequence runs in four stages. Weeks before the announcement, reinforce value by surfacing the product updates shipped, the outcomes achieved, and the features unlocked since the last renewal. At the announcement itself, lead with that value framing, ideally from a founder or senior leader, then state the new price, then lay out the timeline with sufficient advance notice. During the runway, keep checking in on usage and outcomes, so attention stays on value rather than dollars. Just before the transition, restate the exact end date of the grandfathering period, what changes when it hits, and what support looks like on the other side.

For the high-impact segment, a broadcast email doesn't cut it. It takes a person, someone from account management or customer success, having an actual conversation instead of triggering a template. The announcement should carry a concrete anchor, such as a new feature, a raised limit, or a shipped capability the customer can point to, rather than an abstract line about market conditions.

Abrupt changes are harder to absorb than gradual ones. Even when the pricing shift itself happens as a single step on the books, the communication around it can be staged so the customer experiences it in stages rather than all at once.

Real-time usage data's effect on the rollout

Without usage data, segmentation is a guess dressed up as strategy. There's no way to tell which accounts are heavy users, which are barely logging in, or which are about to see the largest effective jump in cost, and guessing wrong on any of those gets expensive fast.

Real usage visibility changes what's possible at every stage. Before rollout, it identifies at-risk accounts by actual consumption, not by whichever plan they happen to sit on. During the runway, it flags accounts that have gone quiet, haven't hit a usage milestone, or are trending toward cancellation for reasons that have nothing to do with the price change. At the moment of transition, it flags accounts about to see their first invoice at the new rate, so someone can reach out before the invoice lands rather than after the support ticket arrives.

The Cursor incident is the cautionary version of this. When billing infrastructure can't surface consumption to the customer in real time, usage can outpace expectations and produce a large unexpected invoice, with fallout that spreads rapidly across social platforms. Cost forecasting is now cited as the top challenge by 90% of CIOs deploying AI tools, so giving customers spend visibility during a price increase is the thing they were already asking for. It's the thing they were already asking for.

This comes down to stream processing versus batch billing, and the choice has real consequences. A batch system that updates hours or days after usage happens can't support real-time spend alerts, live dashboards, or hard usage limits, and all three are now customer-facing expectations during a rollout. Dashboards and alerts work as retention mechanisms because they replace the shock of a surprise invoice with something a customer can watch happen, dollar by dollar, before it ever becomes a bill.

What pricing infrastructure must support to run increases at scale

Running a price increase as an actual experiment puts demands on billing infrastructure that most generic tools were never built to handle. Multiple pricing configurations need to run at once, new-customer pricing sitting alongside grandfathered legacy pricing, on the same engine, without forking into separate billing code paths for each. Account-level pricing transitions need to trigger automatically on a schedule, since different accounts move to new pricing on different dates depending on their segment.

Usage-based overages need real-time metering, which the Atlassian and HubSpot consumption models illustrate in practice, rather than a reconciliation pass at the end of the month. Customers need spend dashboards and adjustable alert thresholds so they can watch consumption climb before the invoice arrives. Prepaid credit wallets need to sit on the same engine as postpaid invoicing, since AI-era pricing tends to blend both, and no rollout should require standing up a second billing system just to support credits.

A vendor running different grandfathering timelines across several segments is, in effect, running several pricing experiments at once. That's exactly where teams relying on in-house billing, or a metering tool stitched to a separate invoicing tool, start losing the first week of every month to invoice corrections. The infrastructure was never built to hold this much pricing complexity at once, and no amount of process discipline fixes an engine that can't do the job.

L.E.K. Consulting's findings on elasticity testing only matter if the billing system executing those adjustments can carry them out without an engineering ticket for every tier change or grandfathering date. Pricing should be something product and finance teams adjust directly, not something that requires a code change every time a new tier gets introduced.

Purpose-built billing infrastructure, the kind that ingests usage events fast, models subscription and consumption pricing on the same system rather than as two bolted-together tools, and surfaces usage data in real time, is what turns everything above from a plan on paper into something a team can actually run.