# How to collect feedback on a new feature launch

> Put the feedback entry point inside the new feature, next to the control people use, and preselect the type you need most. Tag each item with the feature name in metadata so launch feedback stays separate from the rest of the inbox during the first weeks.

Source: https://escutaproduto.com/resources/feature-launch-feedback
Last updated: 2026-10-09

## Put the entry point where people use the feature

Feedback about a new feature is most useful when it comes from someone who has just used it. The best place for the entry point is therefore inside the feature itself: next to the button that starts the new flow, or in the empty result panel that appears after the first run. A banner on the dashboard that says "We launched something new, tell us what you think" gets vague praise and generic complaints, because the person has not done anything with the feature yet.

Look at how the feature is opened. If it lives behind a menu item, put the entry point next to the menu item's result, not next to the menu. If it changes an existing screen, put the entry point on the changed area. The rule is that the entry point should sit next to the thing the user is judging.

Escuta Produto does not show a floating button for each feature, so you decide where the entry points go. Set `data-trigger` to `none` on the widget script tag, then place `data-escuta-open` elements where the feature lives. The floating button can stay off for the whole product or for the launch period only.

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

<button type="button" data-escuta-open="idea">Tell us about bulk export</button>
```

## Preselect the type you need most

Every launch needs a different kind of feedback at different times. In the first days you usually need bugs, because edge cases appear as soon as real people use the feature. In the second and third weeks you usually need ideas, because people now know what is missing. Praise is useful for knowing what not to change, but you will have plenty of it if the feature works.

Choose the entry point's type to match the question you are asking. A "Report a problem" link can open with `bug` selected, and an "Ask for a change" link with `idea` selected. Both still show the other types, so people can switch if they picked the wrong one. The preselection is a hint, not a filter.

## Mark every item with the feature name

Launch feedback becomes hard to read when it mixes with the rest of the inbox. Six weeks later, nobody remembers whether the complaint about the export was about the new bulk option or the old CSV button. The fix is a feature name in metadata, set before the form opens.

```js
EscutaProduto.setMetadata({ feature: "bulk-export", featureVersion: "2" });
EscutaProduto.open({ kind: "bug" });
```

Use stable names that match your code, not the marketing name of the release. A version key helps when the feature changes in the second week and you want to separate answers for the first design from the second. Metadata holds up to 4 KB, which is far more than a feature name needs, so keep it small and consistent.

Escuta Produto has no tags. Metadata, internal notes and the CSV export are the tools for grouping launch items. Keep the feature name identical across the codebase, the metadata and the release notes so a search in the inbox finds every related message.

## Watch the first week closely

The first week after a launch is when the most important feedback arrives. Check the inbox daily for the feature's entries, and look at the 30-day chart and the counts by type on the product. A spike in new items or in bugs is a signal, and so is a drop in the average rating. A spike means the feature has an edge case you did not test, and it should move to the top of the queue.

Read each bug with the page URL and browser attached. Feature flags, screen sizes and browsers often explain why one person hit a problem that others did not. If a bug cannot be reproduced, close it with a note that describes what you tried, so the next reader does not repeat the same search.

## Separate launch noise from real problems

Some feedback is noise. A user who clicked the wrong button and wrote "this is broken" needs a short reply, not a fix. Other feedback is an early warning. The difference is usually visible in the detail: the message names a step, a data type or a result that is wrong.

Create a simple rule for the first two weeks. Any item that names a wrong result goes to planned work within 48 hours. Any item that asks how to do something goes to the help documentation or to a short reply that links the docs. Any item that asks for a new capability goes to the idea queue, where it waits for the weekly review. The [triage routine](/resources/how-to-triage-customer-feedback) describes how to run that review, and the [bug versus feature request guide](/resources/bug-report-vs-feature-request) helps when a message could be either.

## Closing the loop on a launch

When the first round of fixes ships, reply to the people who reported the problems. A short reply that says the fix is live, and thanks them for the detail, does more for future feedback than any form. The [guide to telling customers their request shipped](/resources/tell-customers-request-shipped) covers how to find who asked and what to write.

Keep the feature's metadata in the note when you close the launch. In three months, you will want to know which fixes came from the launch, and the note saves you from searching the whole inbox.

## How to run a feature launch feedback loop in Escuta Produto

Place one or two entry points where the feature is used, set the feature metadata on each click, and turn on the Slack or Discord webhook for the product during the launch period. Each new item then posts its type, rating and excerpt, which helps the team react quickly.

Use the [widget docs](/docs/widget) for the attributes and the JavaScript methods, and the [notifications docs](/docs/notifications) for what the alert contains. After the launch, leave the metadata in place. Items with the feature name stay searchable, so the history is still useful when you plan the next version.

## Frequently asked questions

### Where should the feedback entry point for a new feature go?

Put it inside the feature, next to the control people use or the result panel they see after using it. A banner on the dashboard gets vague answers because people have not used the feature yet.

### Which feedback type should a feature launch ask for first?

Bugs in the first days, because edge cases appear as soon as real people use the feature. Ideas after two or three weeks, once people know what is missing. Preselect the type on each entry point, but leave the other types available.

### How do you keep launch feedback separate from the rest of the inbox?

Set a feature name in metadata with EscutaProduto.setMetadata before the form opens. Keep the name identical to your code, then search or read the items with that name during the launch period.