How to collect feedback in a beta program

Decide whether beta gets its own product

Beta testers report differently from regular customers. They expect rough edges, they are curious about what is coming, and they often write longer messages about things they have not finished testing. If their feedback lands in the same inbox as everyday customer messages, it can drown out the people who depend on the product today. Keeping the two groups apart is the first decision.

You have two options. The first is a separate product in Escuta Produto for the beta. Its inbox, statistics and notification webhook stay independent from the main product, so the beta team can read it on its own schedule. The second is a metadata flag on each item, such as channel: "beta", filtered by hand in the main inbox. The separate product is simpler when the beta has a distinct audience and its own team. The metadata flag works better when a few testers use the same product and you want their reports close to the rest.

Choose one and stick with it for the whole program. Switching in the middle makes the history hard to read.

Flag beta testers in metadata

If you use one product, set the beta flag when the tester is identified. The identify call stores any key you pass beyond email and name as metadata. That means a beta flag set once at login follows every feedback item from that tester.

EscutaProduto.identify({
  email: user.email,
  name: user.name,
  id: user.id,
  beta: true,
  betaCohort: "2026-autumn",
});

Use a cohort name when you run more than one beta over the year. It lets you compare the first cohort with the second without guessing from dates. Keep the names stable and short, and document them in your team notes.

Metadata is stored with each item, and it holds up to 4 KB, which is plenty for a beta flag and a cohort name. Escuta Produto has no tags, so this is the way to mark testers. Use internal notes on each item for anything the team needs to remember about the tester.

Set expectations before the first message

Testers behave well when they know what you want from them. Before the first session, tell them three things: what the beta is for, what kind of feedback helps most and how quickly they can expect a reply. A short welcome email or an in-app note works well. Avoid promising features or dates you cannot keep.

A helpful expectation sounds like this in plain words: "We want to know where the new reports confuse you and what you expected to see. Bugs with the steps to reproduce them help the most. We read every message, but we cannot reply to all of them within a day." Each sentence sets a boundary the tester can rely on, which is the point of setting expectations at the start.

Ask testers to say what device and browser they used, if they are willing. The widget saves the browser automatically, so you may not need to ask, but a description of the workflow they were trying helps more than a list of browsers.

Give testers a link that needs no login

Not every tester will open the app every day. Some will only read the email that invited them, and others will use a second device. A hosted feedback page at /f/<product-slug> works without a login or an installed script, so it is the simplest way for a tester to send a note from wherever they are.

Add ?lang= for the language and ?email= to prefill the address. The page uses the product's accent color, so testers recognize it as part of the program. The hosted page docs list every parameter.

Keep the hosted link for testers who need it and the widget for testers who already use the app. Both write to the same inbox, so you do not need to combine them later.

Run a weekly beta review

Beta feedback needs its own rhythm. Read every new item once a week, in one sitting of about an hour. Sort bugs first and reproduce each one with the page URL and browser saved on the item. Then read the feature messages and the praise, and write a short note on each item that says whether it is planned, closed or needs more detail.

Ask a follow-up question when a report is unclear. A message that says "it broke" needs the steps, the screen and the time. Ask for those details once, politely, and move on if the tester does not reply. Escuta Produto does not send automatic emails to customers, so write the follow-up from your own address.

Share a short summary with the team after each review. Three lines are enough: the bugs fixed this week, the bugs still open and the one idea the team should discuss. A regular summary makes the beta feel like a conversation rather than a pile of messages.

What to do when the beta ends

When the beta closes, decide what happens to the items. Bugs that were fixed get a reply to the tester who reported them. Ideas that were not built get a short note saying why. The guide to telling customers their request shipped describes how to find the people who asked for a feature.

Testers who helped a lot deserve a thank you. The guide to thanking customers for feedback covers specific thanks that avoid promises you cannot keep. If you plan to ask a tester for a public quote, do it after the beta ends and only with their permission.

How to run a beta inbox in Escuta Produto

Choose the separate product or the metadata flag, then set up the widget or the hosted page for the beta testers. Use the product's Slack or Discord webhook if the beta team wants to see reports as they arrive, and read the rest in the weekly review. The widget docs describe the identify call and the open method.

Filter the inbox by status while the beta runs, so each item moves from new to planned, in progress and done as the team works through it. The status workflow guide explains how to define who moves each item and when.