Release notes template

Copy the template

---
owner: "[accountable person]"
reviewer: "[subject-matter expert]"
status: draft
last_verified: "[YYYY-MM-DD]"
next_review: "[YYYY-MM-DD]"
locale: en
source_article_id: "[stable identifier]"
---

# [What changed for the customer]

> **Short answer:** [Explain the new behavior, who gets it, and whether action is needed.]

## Available to
- Plans or versions: [scope]
- Rollout date or status: [verified date / staged rollout]
- Required action: [action, or explicitly none]

## Before and after
| Before | Now |
| --- | --- |
| [Old behavior] | [New behavior] |

## Use the change
[Short steps and a link to the updated permanent help article.]

## Existing content to update
- [Affected article]
- [Embedded FAQ]
- [Translation]
- [AI knowledge source / integration]

## Known limitations
[Explain real limits. Remove this section if there are none.]

## Author's preflight (remove before publishing)
- [ ] I tested the steps with the intended role.
- [ ] All UI labels match the product.
- [ ] The short answer includes important limits.
- [ ] No placeholder, secret, or real customer data remains.
- [ ] Related links and screenshots are current.
- [ ] An owner and review date are assigned.
- [ ] Any translations or embedded copies are queued for review.

This is the release notes blueprint from the free Compass kit, unchanged. View the Markdown file on GitHub ↗

How to fill in each section

• Title. Describe the change from the customer’s side, such as “CSV exports now include custom fields”, not the internal project name or a version number alone.
• Short answer. Say what is new, who gets it, and whether anyone needs to act. Many readers stop here.
• Available to. List the plans or versions, the rollout date or status, and the required action. Write “None” when nothing is needed, so readers do not have to guess.
• Before and after. One row per behavior that changed. This table answers “what is different for me?” faster than paragraphs do.
• Use the change. A few steps, plus a link to the permanent help article that explains the feature in full.
• Existing content to update. Your own checklist of articles, embedded FAQs, translations, and AI knowledge sources that now describe the old behavior.
• Known limitations. Be specific about what the change does not cover yet. Delete the section if there are none.

The front matter and the author’s preflight checklist keep the note owned and checked. Remove the checklist before publishing.

A filled-in example

Here is the template completed for Acme, the fictional product used across Compass. Replace every detail with your verified release information.

Every product detail above is invented for the example.

Release notes and changelogs are different jobs

A changelog lists every change in a release, often for developers, in the order it shipped. A customer release note explains one change that affects the reader: what is different, whether they need to act, and where to learn more. Teams often keep both and link the changelog entry to the release note.

Publish the release note where customers already look for answers, such as your help center, and link to it from the in-app announcement or email. Then update the permanent articles on the checklist, so search and support answers stop describing the old behavior.

Common questions