Pricing Change to Support Readiness Loop

A grandfathered plan transition record documents how existing customers are treated when a product changes pricing or plan structure. It is useful because the most sensitive pricing questions usually come from customers who joined under older terms.

The record should begin with the original promise. What plan did the customer buy, what limits were visible, and what language was used at the time? This prevents the team from rewriting history after the pricing model changes. If the old plan was experimental, promotional, beta-only, or time-limited, that should be recorded too.

Next, define what stays the same. Some grandfathered plans keep the old price but not old feature access. Some keep feature access but lose future upgrades. Some remain until cancellation, while others remain until a renewal date. These distinctions should be explicit because customers will interpret “grandfathered” differently.

Then define what triggers a change. Common triggers include upgrading, downgrading, changing billing interval, canceling and reactivating, exceeding usage limits, adding seats, changing workspace ownership, or missing payment. If a trigger moves the customer to current pricing, say so before the trigger happens.

The record also needs a support rule. Support staff should know whether they can make exceptions, extend a grace period, restore a legacy plan, or only explain the policy. Without this, different customers may receive different answers.

Finally, log customer-facing wording. A clear sentence such as “Your current price remains active while your subscription stays uninterrupted, but changing plans will move the account to current pricing” is better than vague loyalty language. The transition record protects both sides: customers can understand their options, and the product team can answer consistently.

Grandfathered Plan Transition Record

// COMMENTS

ON THIS PAGE