Why Every SaaS Needs a Public Changelog (and How It Improves Retention)

You shipped forty improvements last quarter. A customer emails to ask whether the product is still being worked on.

This is not a rare failure. It is the default outcome. Software improves invisibly — the bug you fixed is now simply the absence of a problem, and the feature you added is a menu item nobody happened to open. Unless you tell people what changed, the honest experience of using your product is that nothing ever does.

A changelog is the cheapest fix for that, and it does considerably more than announce releases.

What a changelog actually buys you

It proves the product is alive. For anyone evaluating you, a public changelog with entries from this month answers a question they were going to ask anyway. It is the difference between a landing page and evidence.

It closes the feedback loop. The person who requested something six weeks ago does not know it shipped. Telling them is the moment they learn that talking to you produces results — which is what makes them do it again.

It re-engages people who drifted. Someone who stopped using your product did so for a reason. If the reason was a missing feature, a note saying that feature now exists is the single most relevant message you will ever send them. Not a newsletter. Not a win-back campaign. A one-line fact about the thing they wanted.

It reduces support. A visible list of recent changes absorbs a real share of "did this break?" and "is this new?" tickets before they get written.

How to write entries people read

Lead with what the user can now do. Not "refactored the export pipeline" but "exports now include archived items and finish in seconds instead of minutes." Internal accuracy is not the goal; recognisability is. The reader should be able to tell in four words whether this entry is about them.

Label every entry. Three buckets are enough: New for things that did not exist, Improved for things that got better, Fixed for things that were broken. Readers scan for the label that matters to them, and skimmers who only care about bugs can find the bugs.

Keep entries short and split them up. One entry per change, three sentences each, beats one monthly post covering everything. Short entries can be linked to individually, quoted in a support reply, and skipped without losing the thread.

Show it when it is visual. A screenshot or a five-second clip does more than a paragraph for anything involving a screen. Skip it for backend work — a picture of nothing is worse than no picture.

Write for the person who has not used the feature. Assume no context. Name the screen. If it needs setup, say where.

Do not batch out of embarrassment. Small entries are not a weakness. A changelog with eleven modest items last month reads as momentum. One heavily-designed post per quarter reads as a company that ships quarterly.

Get it in front of people

A changelog nobody visits is a diary. Distribution is most of the value:

• Email subscriptions. Let people opt in and send on publish. This is the channel that reaches lapsed users, because it does not require them to open your app first.
• RSS. Cheap to offer, and the developer audience genuinely still uses it.
• In-product. A link in your nav or an unobtrusive badge on your account menu catches active users at the moment they can try the thing.
• Notify the requesters specifically. The highest-value message is not the broadcast — it is the one that tells the eleven people who voted for something that it now exists.

Where SupDesk fits

SupDesk ships a changelog module on your portal, on your own domain if you want one.

• New / Improved / Fixed labels on every entry, so the page stays scannable as it grows.
• Email subscriptions and an RSS feed. Publishing an entry emails your subscribers, with unsubscribe handled for you.
• Automatic notification of requesters. Link a changelog entry to the feedback posts it resolves, and everyone who voted on those posts is told when you publish. That is the loop closing without you keeping a list.
• Machine translation. Entries can be translated into the locales you support using Cloudflare Workers AI, and the translation is yours to review and edit before it goes live — machine speed, human final say.
• Audience targeting. Publish an entry to everyone, or only to your beta program, when a change is not general yet.

One honest note on scope: entries publish when you publish them. There is no scheduled-send, so a release that goes out at 6am goes on the changelog when you press the button, not before.

The habit is the hard part

The mechanics of a changelog take an afternoon. The discipline of writing three lines every time you deploy is what actually produces the retention effect, and it is the part that lapses first.

Make it part of shipping rather than a task after shipping. The entry gets written while you still remember why the change mattered, which is also when it is easiest to write.

Set up your changelog, subscribe your first users, and let the next release announce itself. Get started at supdesk.app