Release notes are the one piece of product writing that almost every customer sees, and almost every team writes in a hurry. The pull request is merged, the deploy is green, and someone types "Bug fixes and improvements" into the changelog because the next sprint has already started.
That line costs you more than it looks. Customers who asked for a feature never learn it shipped. Support keeps answering questions the release already solved. And the people who voted on your roadmap stop believing their votes do anything.
A release notes template fixes the hurry problem. When the format is decided in advance, writing a good entry takes ten minutes instead of a blank-page half hour. Below are copy-ready templates for the five kinds of release most SaaS teams ship, plus a short checklist to run before you publish.
What good release notes do
Before the templates, agree on the job. A release note has three readers:
So every entry needs to answer the same four questions: what changed, who it is for, what the reader should do now, and where to learn more. If an entry does not answer those, it is a commit message, not a release note. Our post on changelog marketing covers why this matters for growth; this guide is about the format itself.
The base release notes template
Use this as the default. Every other template below is a variation of it.
Headline: the user benefit in plain words, under 70 characters.
Example: "Export any report to CSV in one click"
Type: New, Improved, Fixed, Changed or Removed.
Who it affects: all users, a plan, a role, or a platform.
Example: "Admins on Pro and Business plans"
What changed (2 to 4 sentences): the problem first, then the change.
Example: "Teams told us they were copying report tables into spreadsheets by hand. Every report now has an Export button that downloads a CSV with the filters you have applied."
What to do now: one clear action, or "Nothing, it works automatically."
Link: the help article, the original request or the roadmap card.
Date and version: so people can match the note to what they see.
Keep the headline about the reader, not the code. "Added CSV export endpoint to the reporting service" is accurate and useless to a customer. "Export any report to CSV in one click" tells them why to care.
Template 1: New feature
New features deserve their own entry. Never bury them in a list of fixes.
Headline: [Verb] + [what the user can now do]
Type: New
Who it affects: [plans, roles, platforms]
Why we built it: [the problem, ideally in a customer's words]
How it works: [two or three sentences, plus one screenshot or short clip]
How to start: [where to click, or the setting to turn on]
Requested by: [number of requests or votes, if you track them, and a link to the request]
Learn more: [help article]
The "Requested by" line is the most underrated part of a release note. If the feature came from your public roadmap or a feedback board, link the original request and mark it shipped. It is the cheapest way to show customers that asking works, and it is the core of closing the feedback loop.
Template 2: Improvement
Improvements are changes to something people already use: faster, clearer, fewer steps.
Headline: [Thing] is now [faster / simpler / clearer]
Type: Improved
Before: [one sentence on the old behaviour]
Now: [one sentence on the new behaviour]
Anything to relearn? [yes, with a pointer, or no]
The before-and-after pair does most of the work. "Before: you had to open each request to change its status. Now: you can change status from the board view by dragging the card." Readers understand that in two seconds.
Template 3: Bug fix
Most teams either hide fixes completely or list them as a wall of ticket titles. Neither helps. Group small fixes into one entry, and give the ones customers actually noticed a line of their own.
Headline: Fixes for [area] (or a specific headline for a notable fix)
Type: Fixed
What was wrong: [the symptom the customer saw, not the root cause]
Who was affected: [scope and time window, if known]
What we changed: [one sentence]
Do you need to do anything? [usually no; if data needs a refresh, say exactly how]
Describe the symptom in the customer's terms. "Vote counts could show one less than the real total on busy boards" is useful. "Fixed race condition in vote aggregation" is for your engineering log.
Template 4: Breaking change or deprecation
This is the template where a lazy entry does real damage. If customers have to change something, the release note is a notice, and it needs a date.
Headline: [Thing] is changing on [date]
Type: Changed or Removed
What is changing: [plain description]
Why: [the honest reason]
Who is affected: [be specific; if you can, tell people how to check]
What you need to do, and by when: [numbered steps and a deadline]
What happens if you do nothing: [the exact outcome]
Help: [contact or migration guide]
Publish this entry well before the change, then publish a second short entry on the day it happens. If the change affects an API or an integration, follow a versioning convention such as Semantic Versioning so developers can tell from the number alone that something will break.
Template 5: Small batch release
Weekly or fortnightly releases often contain a handful of small items. Batch them, but keep the structure.
Headline: [Month or week]: [the most useful item] and [n] more updates
Type: Mixed
Highlights: [one or two items with a sentence each]
Also in this release:
The headline names the best item instead of "Weekly update", so the entry is still worth opening. If you keep a developer-facing changelog as well, the Keep a Changelog convention of grouping changes under Added, Changed, Deprecated, Removed, Fixed and Security works well and maps neatly onto the types above.
A worked example
Here is an entry for an imaginary invoicing app, Acme Invoices, written with the base template:
Send recurring invoices automatically
New · Pro and Business plans · October 2026
Many of you bill the same clients every month and were copying last month's invoice by hand. You can now mark any invoice as recurring, choose how often it repeats, and Acme Invoices will create and send the next one on schedule. You can pause or edit a series at any time.
How to start: open an invoice, choose Make recurring, and pick a schedule.
This was one of the most voted requests on our public roadmap. Thank you for asking.
Notice what is missing: no internal ticket numbers, no technical jargon, no "we are excited to announce". It answers what changed, for whom, what to do and where it came from, in under 100 words.
Pre-publish checklist
Run this before every release note goes out:
That last point matters more than it seems. If a feature is rolling out gradually, say so: "Rolling out to all workspaces this week." Announcing something customers cannot find yet generates support tickets and erodes trust in every later entry.
Where release notes should live
Publish every entry in one public place that customers can find without asking, then point to it from wherever they already are: an in-app notice, a short email for the entries that matter, and the original request or roadmap card. Keep the changelog next to the roadmap so people can follow an idea from request to release in one place.
If requests reach you through support, sales calls and spreadsheets, a consistent feature request template upstream makes release notes easier downstream, because the "why we built it" line is already written by the customer who asked.
The ten-minute habit
Good release notes are not a writing talent. They are a habit backed by a template. Pick the base template above, paste it into your changelog tool or your pull request description, and make filling it in part of "done" for every customer-visible change.
Within a month, your changelog stops reading like a commit log and starts doing its real job: telling customers that the product is moving, and that their feedback is part of why.
Ready to build your public roadmap?
Roadmapr gives you a public roadmap, feature voting, and a changelog in one place. Start on the Free plan and upgrade when your team grows.
Get Started Free