Downgrade offers: when a cheaper plan beats a discount

When a customer says “it’s too expensive,” the reflex is a discount: 30% off for three months, please stay. Sometimes that is right. Often a cheaper plan is better for both sides. The customer pays for what they actually use, and you keep a customer whose price does not jump back up in three months.

This guide is about that one choice. For the wider comparison of pauses, discounts, downgrades and calls, see pause vs discount vs downgrade.

The difference in one table

	Discount	Downgrade
What the customer gets	Same plan, lower price for a while	Smaller plan, lower price for good
What happens later	Price returns to normal	Price stays at the lower plan
What it signals	“The price is negotiable”	“Here is a plan that fits you”
Typical risk	Churn when the discount ends	Revenue lost on customers who would have stayed anyway
Best for	A temporary squeeze	A lasting mismatch between plan and use

The key question is whether the customer’s problem is temporary or lasting. A startup between funding rounds has a temporary problem. A team that bought ten seats and uses three has a lasting one. A discount on ten seats only delays the same conversation.

Compare them on expected revenue

You do not need a model to compare the two offers, just a simple formula and honest guesses that you later replace with your own data.

expected revenue over 12 months =
  sum over months m = 1..12 of
    price in month m × probability the customer is still subscribed in month m

Worked example (hypothetical numbers)

A customer on a $100/month plan clicks cancel and picks “too expensive.” Two possible offers:

Discount: 50% off for 3 months, then $100.
Downgrade: a $60/month plan with fewer seats.

Suppose, purely for illustration, that customers who accept the discount stay with probability 90% per month during the discount and 75% per month after it ends, and that customers who downgrade stay with probability 92% per month throughout.

Discount path, rounded:

months 1–3:  $50 × (0.90, 0.81, 0.73)         ≈ $122
months 4–12: $100 × 0.73 × (0.75, 0.56, 0.42, 0.32, 0.24, 0.18, 0.13, 0.10, 0.08)
             ≈ $100 × 0.729 × 2.77            ≈ $202
total                                          ≈ $324

Downgrade path:

$60 × (0.92 + 0.92² + … + 0.92¹²)
  = $60 × 0.92 × (1 − 0.92¹²) ÷ (1 − 0.92)
  ≈ $60 × 7.27                                 ≈ $436

With these made-up probabilities, the downgrade earns more over the year, even though its monthly price is lower than the discount’s eventual return to $100. Change the probabilities and the answer can flip: if customers really do recover after a short squeeze, the discount wins.

The point is not these numbers. It is that you should run the comparison with your own retention after each offer, measured over months, not the acceptance rate on the day.

When a downgrade is the better offer

Usage is well below the plan. Seats unused, limits far from reached, features never touched. Your product data tells you this before the customer says it.
The customer has been on the plan for a while. Long-tenured customers who say “too expensive” usually mean “too expensive for what I use now.”
A cheaper plan exists that still covers what they use. If the only cheaper plan removes the one feature they rely on, it is not an offer.
You do not want to train discount-seeking. Customers talk. A cancel button that always produces 50% off becomes a known trick.

When a discount is the better offer

The problem is temporary. Budget freeze, seasonal slowdown, a short gap between projects.
The customer uses the full plan. Downgrading would break their workflow.
You only have one plan. Then the alternatives are a discount, a pause or nothing.
The customer is on the cheapest plan already. Nothing to downgrade to.

Which plan to show

Show one plan, not the pricing page. Pick it from what the customer actually uses:

List the plans cheaper than the current one.
Remove plans that lack a feature the customer used in the last 30 days, or whose limits the customer exceeds.
Of what remains, show the most expensive one. It solves the price problem with the smallest drop in revenue.

Then say exactly what changes: the new price, what they keep, what they lose, and when it starts. “Switch to Team for $60/month. You keep all projects and history. Seats go from 10 to 5; you currently use 3. Starts at your next renewal on December 12.”

Setting it up in Stripe

A downgrade is a subscription update to a cheaper price. A few Stripe behaviours to know (from Stripe’s docs and customer portal configuration, accessed November 2026):

Proration. By default, an update creates prorations; for a downgrade that means a credit for unused time applied to the next invoice. Set proration_behavior to none if the change should simply take effect from the next period without a credit.
Downgrade at period end. The customer portal has an option to schedule downgrades for the end of the billing period instead of applying them immediately. Stripe implements this with a subscription schedule, and it only works between prices of the same product.
Coupons. If the customer had a coupon on the old plan, decide whether it carries over. A coupon calculated for the expensive plan may make the cheaper plan nearly free.

Applying the downgrade at period end is usually fairest: the customer has paid for the current period on the bigger plan and keeps it until then.

Guardrails

Make acceptance instant. One click, then a confirmation with the new price and date. No “our team will contact you.”
Keep “cancel now” visible. A downgrade offer is an option, not a gate. Rules on cancellation in several places require the cancel path to stay clear; see click-to-cancel rules.
Let them upgrade back easily. A downgraded customer who grows again should be able to return to the bigger plan in a click.
Do not show it twice in a row. A customer who downgraded last quarter and now cancels again has told you something; offer a pause or let them go.

Measuring downgrade offers

Downgrades do not stop all revenue loss; they turn churn into contraction. Measure both:

Metric	Formula
Downgrade acceptance rate	Downgrades accepted ÷ downgrade offers shown
Downgrade retention (N days)	Downgraded customers still subscribed after N days ÷ downgrades accepted
Revenue kept	MRR after downgrade, still active after N days
Re-upgrade rate	Downgraded customers who later upgrade ÷ downgrades accepted

Then compare with a holdout of customers who saw no offer, or with customers offered a discount, on the same reason. Look at 30, 60 and 90 days. A downgrade that keeps 60% of a customer’s revenue for a year beats a discount that keeps them for three months and then loses them.

Doing this with NoChurn

NoChurn’s cancel flows ask why the customer is leaving and show one offer per reason: a discount, a pause or a plan change. A one-click “Cancel now” stays visible on every step. You can use the hosted modal or build the screens yourself with the headless API in your web, desktop or mobile app. Your own usage data, sent by API, feeds churn drivers (correlation, not causation) and a churn score from 0 to 100 for each customer. Customers who still leave get win-back emails at day 30, 60 and 90 based on their reason. Every feature is on every plan, priced by MRR only (pricing).