Nobody Told Me: Why Your CMS Needs Release Notes (Even With a Tiny Web Team)

Every small web team has a version of this conversation. Someone tweaks a template on Tuesday. By Thursday an editor is asking why the call-to-action button has moved, why a field has vanished, or why an approval step now needs two clicks instead of one. The change was sensible. The communication was missing.

At OnlineCCMS, we think CMS changes should be treated like product releases — even if your product is an internal publishing tool used by twelve people. You do not need a product manager, a roadmap tool or a fortnightly sprint review. You need a release note habit that is short, regular and written for editors.

The problem with 'just a small change'

Small changes are exactly the ones that cause trouble. A template tweak feels obvious to the person who made it. A new required field feels like a sensible governance improvement. A workflow update fixes a real bottleneck. But editors experience these changes as interruptions to work they already know how to do.

The result is predictable: workarounds, support messages, duplicated content, and a quiet loss of trust in the CMS. People start asking 'is this broken?' when the answer is 'no, it changed on purpose'.

Release notes fix that by making change visible. Not in a technical changelog buried in a repository. In a place editors actually look.

What belongs in a CMS release note

Keep it to five lines if you can:

• Date and version. A simple date is fine. 'September update' is fine too. The point is that changes have a marker.
• What changed. Describe the editor-facing change, not the code change.
• Why it changed. One sentence. 'To reduce broken links in campaign pages' beats 'template refactor'.
• What editors need to do. If nothing, say 'no action needed'. If training is required, link to it.
• Who to ask. A named person or a shared inbox.

Here is a template you can copy:

CMS update — 14 October Changed: News article template now has a separate summary field. Why: Search results and social previews were pulling the first paragraph, which was often unsuitable. Action: Add a one-sentence summary when publishing. Existing articles will keep using the first paragraph until edited. Questions: [email protected]

That is it. No jargon, no release number unless it helps, no list of every ticket closed.

Where to keep it

The best place is wherever editors already are. A pinned page in your intranet. A section in the CMS dashboard. A shared document linked from your publishing guidance. A monthly email is fine too, but do not rely on email alone; people search for things later.

The second-best place is a simple changelog page on your internal wiki. The worst place is a private Slack channel that new starters never see.

Make it a ritual, not a project

You do not need a new tool. You need a ten-minute habit at the end of each change cycle. Before you close a piece of CMS work, ask: 'Would an editor notice this? If yes, has it been noted?'

Batch small changes into a monthly note. Publish urgent changes immediately. Keep the same structure every time so people know where to look. And write it in plain English. 'Field label updated' is less useful than 'The headline field is now called title'.

Tell people what did not change

This is the underrated bit. If editors are worried that a template tweak will affect every page, say that it only affects new pages. If permissions have not changed, say so. A good release note reduces uncertainty as well as announcing news.

The payoff is cultural

Release notes do more than stop support emails. They signal that the CMS is maintained, that changes are deliberate, and that editors are part of the process. That matters in small UK teams where the web person is often also the person doing SEO, analytics and a bit of design.

You will still get the occasional 'nobody told me'. But it will be rarer. And when it happens, you can point to the note, not in a gotcha way, but as a shared record. That is a healthier place to be than a team that communicates through rumour and hurried emails.

Start with one note this month. One page, five lines, written for the people who actually publish.