How to collect feedback from release notes

Why release notes are a good place to ask

Release notes are read by people who care about the product. Someone who opens the changelog is already interested in what changed, and they often have a specific opinion about one entry. They read the new export option and think "that is what I needed" or "that broke my workflow". Asking right there captures the opinion while the change is fresh.

The catch is that a single "tell us what you think" link at the bottom of a long changelog gets a single vague answer. Feedback is much more useful when each entry has its own entry point. The reader can point at the change they mean, and the answer carries the release it refers to.

Release notes also give you a natural rhythm. Each release has a version and a date, so feedback can be grouped by release, and the closing loop can happen in the next set of notes. That makes this moment easier to run than a general feedback prompt.

Give each entry its own feedback button

Add a small button or link to each changelog entry. The label should point at the change, not at the product in general. "Tell us about the new export" is specific. "Give feedback" is generic. Keep the label short so it does not compete with the entry text.

Use the widget without its floating button, so the entry points are the only way to open the form on the changelog page. Set data-trigger to none on the script tag, then add a button for each entry. The release version goes into metadata when the button is clicked, so each button needs a data attribute with the version.

<script src="https://escutaproduto.com/widget.js" data-key="pk_your_product_key" data-trigger="none" defer></script>

<article>
  <h2>Bulk export is here</h2>
  <p>Export many items to a spreadsheet at once.</p>
  <button type="button" class="release-feedback" data-release="2026.10.1">Tell us about bulk export</button>
</article>

Changelog pages are often static, so the same markup works in a Markdown or CMS template. The only requirement is that each button carries the release version as an attribute.

Mark the release in metadata

The release version is the key that links feedback to the change. Set it before the form opens, using the version number your team already uses.

document.querySelectorAll(".release-feedback").forEach((button) => {
  button.addEventListener("click", () => {
    EscutaProduto.setMetadata({ release: button.dataset.release });
    EscutaProduto.open({ kind: "idea" });
  });
});

Use the same version string in your release notes, your code and your metadata. A mismatch between "2026.10.1" and "v2026.10.1" makes the search harder later. Metadata holds up to 4 KB, which is more than a version number needs, so keep the data limited to the release and the entry name.

Escuta Produto's hosted feedback page does not accept metadata parameters. That is why the release tag has to come from the widget on the changelog page. A hosted link works for a general note at the end of the page, but it cannot say which entry the reader meant.

Pick the type for each entry

Each entry should preselect the type that matches the change. A new feature is best read with idea, because readers tell you what they want next. A fixed bug needs bug when the reader says the fix did not work. A change that broke a workflow usually needs bug as well, because it describes something that now fails.

A plain data-escuta-open attribute with a type is enough when you do not need the release tag, because the widget opens the form with that type selected. The click handler above is needed only when you want to tag the release, so choose the approach that fits each entry. Both open the same form, and the reader can still change the type.

Do not offer every type on every entry. A changelog is for reading, and a crowded set of choices makes people skip the link.

Read feedback against the release that prompted it

Review release feedback once the release has been out for a week. Filter the inbox by product, then group the items by the release value in metadata. For each release, read the bugs first, then the ideas, then the praise. A bug that appears only after a release is a regression, and it should move to the top of the queue.

Count distinct customers for each entry. A single enthusiastic reader can write three messages about one change, and that is still one person. The triage routine describes how to weigh requests by how many people asked and who they are.

Praise on a release entry is useful for copy. Ask permission before you quote it, and keep the wording close to the original. The guide to turning praise into testimonials covers the permission step.

Close the loop in the next release notes

Feedback from a release is only useful if you respond to it. In the next set of notes, mention the fixes and the ideas that shipped, and say which earlier feedback prompted them. A line such as "Thanks to everyone who reported the export timeout last week, it now completes for large files" tells readers that the feedback mattered.

Reply to the customers who asked for each change, too. The guide to telling customers their request shipped explains how to find those people with notes and search. Writing the changelog itself in customer language is covered in how to write a changelog customers read.

Do not promise a change in the release notes if it is not planned. A note that says "we are looking at this" is honest, and a note that promises a date you cannot keep is worse than silence.

How to link release notes to feedback in Escuta Produto

Create a product for the app, copy its public key and add the widget script to the changelog page with data-trigger set to none. Add one button per entry with the release version in data-release, then add the click handler above. Turn on the product's Slack or Discord webhook if the team wants to see feedback about a new release as it arrives.

The widget docs explain the open method and the metadata call. The notifications docs describe what each alert contains, so you can check that the release value shows up as expected. Use the status workflow to move items from new to planned and done as the next release ships.