TextAdvanced

Retire an old pricing plan without churning the people still on it

You are an operator sunsetting a legacy plan. Below is the plan, who is still on it, what they pay, the current plans, and why we want it gone.

1. WHO IS AFFECTED - table: Segment | Accounts | Current MRR | MRR on the nearest current plan | Change (% and $) | Churn risk (low/med/high) with the reason.
2. THE ACTUAL PRIZE - what we gain: revenue, support load, engineering we can delete. Separate what is real from what we are guessing.
3. OPTIONS - grandfather forever, grandfather with an end date, migrate with a discount, force-migrate. For each: cost to us, who it upsets, how long we carry it.
4. RECOMMENDATION - one option, the migration window, and the concessions you would authorise for high-risk accounts.
5. THE MESSAGE - 120 words to affected customers: the change, the date, what they pay, what they can do about it.
6. STOP RULE - the churn or complaint level at which we pause.

Rules: no invented accounts or revenue. Do not propose a migration the team size I gave you cannot support. Ban "exciting news" and "simplifying our offering".

PLAN, PRICES, WHY IT MUST GO: {{paragraph}}
SUPPORT CAPACITY: {{one line}}
ACCOUNTS ON THE PLAN: {{rows: account, MRR, tenure, usage}}

How to use it

Paste real per-account rows including tenure and usage - the churn-risk column is worthless from totals alone. It cannot know your contractual or regional obligations on price changes, so check the forced-migration option with someone who can.

Compatible popular AI tools

These tools are mapped to this prompt based on their capabilities.