Announcing pricing changes: writing the update everyone actually reads
No changelog entry will ever be read as carefully as the one that changes what people pay you. Users who have ignored two years of release notes will read this one twice, with a calculator, and then paste a screenshot of it into their team chat. Prospects will find it years later while deciding whether to trust you. Whatever your normal readership numbers look like, a pricing announcement is the one update with a read rate near 100% of paying customers — which makes it the best-written or the most expensive paragraph you publish this year.
This guide covers announcing pricing changes of every kind: increases, decreases, plan restructures, and the most underestimated one — changes to a free tier. The mechanics borrow from the breaking-change playbook (announce early, date precisely, never surprise), but the reader’s state of mind is different: a breaking change threatens their code, a pricing change threatens their budget, and budgets have owners who were never your users at all.
The reader’s questions, in order
Every reader of a pricing announcement asks the same four questions, in the same order. Answer them in that order, in the first screen, before any context or narrative:
1. What do I pay now, and what will I pay after? Exact numbers, for the reader’s own plan, in the reader’s billing period. Not a percentage, not “most customers will see a modest change,” not a link to a pricing page they have to diff by hand.
2. When does it take effect — for me? A date, plus the rule that maps the date onto their billing cycle. “Effective March 1” is ambiguous for someone whose annual plan renews in November; “your price changes at your first renewal on or after March 1” is not.
3. Do I have to do anything? Usually the answer is no, and saying “no action is required — your subscription continues at the new price at renewal” costs one sentence. If the answer is yes (a plan is being retired, they must choose a successor), that instruction outranks everything except the numbers.
4. Why? Last, and honestly. The reader doesn’t owe you a sympathetic reading, and a “why” paragraph placed before the numbers reads as a wind-up — the longer the preamble, the worse the reader assumes the number will be.
Lead with the number
The single most common failure in pricing announcements is hiding the number. Percentages hide it (“a 10% adjustment” forces every reader to do arithmetic on a price they may not remember). Ranges hide it (“plans start at”). Vague scopes hide it (“some plans will see updated pricing”). Every hidden number gets computed anyway — by your angriest customer, in public, with a screenshot.
The honest format is old price → new price, per plan, per billing period:
Pro (monthly): $12/user → $15/user Pro (annual): $120/user → $144/user Team (monthly): $24/user → $28/user Free: no change
A table like this does something subtle: it proves you’re not hiding anything. The reader finds their row, does no math, and moves on to the date. Note the last line — say explicitly which plans don’t change. Silence about the free tier in a price-increase announcement reads as “they’re coming for it next.”
Grandfathering is a message, not just a policy
Whether existing customers keep their old price is the second thing every reader looks for, so state it explicitly whichever way it goes. There are only three honest positions: existing customers keep the current price permanently; existing customers keep it for a defined window (name the date it ends); or everyone moves to the new price at renewal. Any of the three can be fair. What’s not survivable is ambiguity — or announcing a grandfather window and later shortening it, which converts your most loyal cohort into your most vocal critics in a single email.
If a segment is entirely unaffected, tell them so in the shortest message you have ever sent: “We’re changing prices for new customers. Yours doesn’t change. That’s the whole email.” Unaffected customers who read a long anxious announcement to discover they could have skipped it remember the anxiety, not the reprieve.
The “why” paragraph: your changelog is the receipt
There are exactly two honest reasons prices go up — your costs rose, or the product is worth more than it was — and most real increases are some of both. Say which, plainly. What readers punish is not the reason but the fluff around it: “to continue delivering the value you expect,” “to serve you better,” “as we continue to invest in innovation.” Every one of those phrases is a number the reader can’t verify wrapped in a feeling they don’t have.
If your case is “the product is worth more,” you have a receipt: the changelog itself. “Since our last price change in 2024, we’ve shipped X, Y, and Z — here’s the full history” with a link to two years of dated entries is the one form of this argument that doesn’t require trust, because the reader can audit it. This is the quiet payoff of a maintained changelog: on the day you most need credibility, you either have an unbroken public record of shipped work or you have adjectives. (It’s also a reason the entries should be specific rather than enthusiastic all year — enthusiasm doesn’t compound, but a list of real improvements does.)
Timing: the next-renewal rule
Three timing rules cover nearly every case:
Announce at least 30 days before anyone pays the new price. Monthly customers get at least one full billing cycle’s notice; annual customers get notified well before their renewal, not discovered on an invoice. In several jurisdictions and in most enterprise contracts, advance notice of price changes isn’t etiquette, it’s an obligation — check yours before picking dates.
Nobody’s bill changes mid-cycle. The new price applies at the next renewal after the effective date, never retroactively, never prorated onto a period the customer already paid for. This rule is so widely expected that violating it reads as a billing error even when it’s policy.
Ship the announcement like a launch, not a leak. Same canonical-URL discipline as any tier-1 announcement: one permanent public entry, published on a weekday morning in your main market, with email, in-app notice, and support macros ready the same hour. Pricing news travels faster than feature news; if your support team learns the details from an angry tweet, the rollout failed regardless of the policy’s fairness.
Free-tier changes are pricing changes
Lowering a free tier’s limits, removing features from it, or adding a paywall in front of something that was free is a price increase from $0 — experienced by the audience with the least invested and the most to say. Treat it with full pricing-change discipline: exact old → new limits, an effective date with real notice, and an explicit statement of what happens to existing data or projects that exceed the new limits (read-only? deleted after a window? grandfathered?). The silent free-tier nerf — discovered by a user hitting a wall that wasn’t there last week — produces the angriest thread your product will ever star in, and the anger is about the silence, not the limit.
The same applies in reverse to trials and promotional pricing: if the promo price ends, the announcement of the promo should have said so, with the date and the price it becomes. An “introductory price” that was never labeled introductory is, from the reader’s side, a price increase with a cover story.
Price cuts get announcements too
Good pricing news still needs the same structure, for less obvious reasons. Customers on annual plans who prepaid at the old price want to know whether they get a credit, the new price at renewal, or nothing — answer it before they ask. A price cut announced with too much marketing gloss makes readers hunt for the catch (“what did they take away to fund this?”), so the old → new table matters here too: it shows the cut is real and complete. And plan restructures that are “a price cut for most customers” contain, by arithmetic, a price increase for the rest — find that segment and address them directly instead of hoping averages will comfort them.
A template
## Pricing update: what changes and when **The numbers.** On <date>, prices change as follows: Pro (monthly): $<old> → $<new> per user Pro (annual): $<old> → $<new> per user Free: no change **When it applies to you.** Your price changes at your first renewal on or after <date>. No bill changes mid-cycle, and nothing is retroactive. Monthly customers: your <month> invoice is the first at the new price. Annual customers: your current price holds until your renewal date. **Existing customers.** <State the grandfather policy in one sentence, whichever it is.> **Do you need to do anything?** No — unless <plan being retired> applies to you, in which case: <instruction + deadline>. **Why.** <One honest paragraph. Link your changelog history if the case is “the product grew.” Costs, if the case is costs.> Questions: <support channel>. Full details: <pricing page>.
Six anti-patterns
1. The buried lede. Four paragraphs of company narrative before the number. Readers interpret preamble length as bad-news padding — because it usually is.
2. Percentage-only framing. “About a 12% adjustment” makes every reader do arithmetic and makes the announcement quote terribly. The screenshot going around your customers’ Slack will have the dollar numbers in it; better they be yours.
3. The ToS smokescreen. Announcing a price change inside a “we’ve updated our terms” email, linked from paragraph six. It technically counts as notice and is universally read as hoping nobody notices.
4. The silent free-tier nerf. Limits lowered with no entry, no date, no migration note — discovered in production by the people most likely to write about it.
5. Effective immediately. Any pricing change without a notice window, including “new signups only” changes that also quietly catch plan switches, upgrades, or seat additions by existing customers. Map every path a current customer can take onto the new price sheet before you publish, or the edge cases become the story.
6. The reneged grandfather. Promising existing customers their price “forever” (or for a window) and revisiting it later. Whatever the new announcement says, its actual text is “our commitments have expiry dates we don’t disclose.”
Where the announcement should live
Email is mandatory for a pricing change — it’s one of the four emails that always earn a send, because the audience includes dormant customers who will otherwise meet the new price on an invoice. But email is the notification, not the record. The canonical announcement belongs on your public changelog at a permanent URL: support links it in every reply, the in-app notice points at it, and — because pricing rumors outrun pricing facts — anyone can check the primary source against the screenshot they were just sent. A public dated entry also builds the long-term record: the next time you change prices, “our last change was in <year>, here’s the entry” is a sentence that buys real goodwill.
How this works in Wakelog
Wakelog gives a pricing change the infrastructure it needs: a permanent public entry with
a stable URL for the email and support macros to point at, the announcement tag
so it stands out from routine entries and is filterable later, and scheduled publishing
(publish_at) so the entry, the email send, and the in-app notice can go live in
the same hour without anyone hand-refreshing the publish button. Your shipped history — the
receipt for the “why” paragraph — is already there as dated, permalinked entries, exportable
anytime. Honest caveats: Wakelog doesn’t send email, so pair the entry with your email tool
via the RSS-to-email workflow; and Wakelog
itself is free while we build it out, so this is one guide where we’re sharing the
literature rather than our own scar tissue — the craft above is how we’d want to be told.
Give your announcements a permanent home Next: product update emails →
Related guides
- Announcing rate limit and quota changes: when the breaking change is a number
Tighten a rate limit and no schema changes, no endpoint moves, no version bumps — every diff tool in the world reports nothing happened. Then the month closes, traffic peaks, and integrations that ran flawlessly for two years start throwing 429s at the exact moment their owners can least afford it. Limit changes are the API break nothing can detect, which makes the announcement the only interface you have. - Payment and fintech release notes: announcing changes when money is on the line
A renamed report column in a payments product isn’t a cosmetic change — it’s the reason someone’s books don’t close on the 31st. Fintech release notes answer for money, not just software: approval rates, settlement dates, fees, and the reconciliation spreadsheets built on top of every field you expose. What to write when your reader’s revenue depends on the answer. - Marketplace seller updates: announcing fee and policy changes to sellers
A fee-schedule edit for you is a margin change for thousands of small businesses — and sellers can’t churn, so distrust becomes megathreads, trade press, and regulators instead of quiet departures. The discipline for announcing changes to the people whose income runs on your platform.
Last updated 2026-07-28 · All guides