How to collect feedback in a SaaS product

Why logged-in users give the best feedback

Feedback from a signed-in customer is worth more than a message from an anonymous visitor. The person pays, uses the product every week and knows the workflow. They also tend to describe problems in the terms your team uses, which saves time when you triage.

The widget can collect that feedback from inside the app. The trick is to make sure each message arrives with enough context to act on: who sent it, which plan they pay for, and where in the product they were when it happened. The widget already saves the page URL and browser for you. This article covers the rest.

Load the widget once in the app shell

Put the script in the layout that wraps every logged-in page, not in each screen. In most single-page apps this is the root layout or the component that renders the navigation. Use the public key from your product settings:

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

A route change inside a single-page app does not reload the script, so the widget stays available as customers move between screens. Add your production domain and any staging domain to the allowed origins in product settings. Without that, the widget will not submit from those sites.

If your interface already has a help menu, you do not need the floating button. Set data-trigger="none" and open the form from your own menu item. The next sections show how.

Identify users after login

The widget can fill the form for you when it knows who is using the app. Call identify once you know the user, using the queue form below. The queue works even if your code runs before the widget script has finished loading:

window.EscutaProduto = window.EscutaProduto || { q: [] };
(window.EscutaProduto.q ||= []).push([
  "identify",
  [{ email: user.email, name: user.name, id: user.id, plan: user.plan }],
]);

Email and name fill the form fields. When an email is known, the form hides the email field, so the customer is not asked to type it again. Any other key, such as plan or id, is stored as metadata on the feedback item.

Call identify again whenever the plan changes, for example after an upgrade. Otherwise the next feedback item will show the old plan, and you will read the wrong context.

Choose metadata that explains the feedback

Metadata answers the questions you would otherwise ask in a follow-up email. A short set of keys works well for most SaaS products:

Key	Example	Why it helps
plan	"team"	Shows whether the report comes from a paying segment
accountId	"acc_8841"	Links the item to your admin tools
role	"admin"	Separates people who manage the account from members
area	"exports"	Records the part of the app the person was using

For example, if a customer on the team plan reports that exports time out, the item already shows the plan and account id. You can check how large their data set is before you answer.

Keep the list short and stable. Do not send passwords, tokens, card data or full records of your customers' customers. Metadata is for context, not for storing private data. Escuta Produto has no tags, so use metadata for the context you want to filter by later, and internal notes on each item for your own labels.

Place entry points where the work happens

People send better feedback when the form is close to the problem. Three places tend to work well in a SaaS dashboard:

1. Settings and billing screens, with a "Send an idea" link. Ideas about pricing and account features show up here.
2. Reports and exports, with a "Something is wrong with this report?" link that opens the form with the bug type preselected.
3. Error screens, where a short "Tell us what happened" button sits next to the error message.

The HTML for a preselected entry point is a plain button:

<button type="button" data-escuta-open="bug">Report a problem</button>

The value after data-escuta-open chooses the type: bug, idea, praise or other. You can also open the form from JavaScript with EscutaProduto.open({ kind: "idea" }).

Avoid a permanent floating button over the primary action of a screen, and avoid opening the form automatically. A form that appears after every login trains customers to close it. Let people choose when to write.

Keep feedback from interrupting the work

Timing matters more than placement. Ask for an opinion after the customer finishes something, such as a successful export or a completed setup, not while they are still in the middle of a task. The article on asking for feedback after a first success covers how to pick that moment.

Keep the number of entry points small. Two or three well-placed links usually collect more useful messages than a button on every screen.

Set up Escuta Produto for your SaaS app

Start with one product for the app. Copy its key from the dashboard, add your domains to the allowed origins, and paste the script into the app shell. Add the identify call after login and test it with your own account: send a bug and an idea, then check that the item shows your email, plan and page URL.

Then connect a Slack or Discord webhook for the product, so new items reach the team that answers them. Each alert shows the type, the rating, the sender and a dashboard link. The notifications guide explains the setup, and the widget reference lists every option.

If you run a mobile companion or an API alongside the web app, the same product can accept those messages too. The mobile app guide shows how to send feedback from native code, and the REST API reference has the full request format.