How to Collect Feedback During SaaS Onboarding Without Interrupting Setup

Make feedback available on the onboarding pages where users may get stuck, but let them choose when to open it. Keep the form short, enable only relevant Issue, Idea and Question types, and decide whether visitors can request a reply. Page and device context can help you understand a report without adding a long technical form. This approach gives users a way to speak up while keeping the main setup flow in their hands.

Put feedback where onboarding happens

If onboarding happens across several pages, make the widget available on those pages rather than asking users to find a separate contact form. A floating launcher can stay closed while someone works through setup, then be opened if they have a problem or suggestion. Avoid interrupting progress with a modal or a required survey at every step.

Choose placement with the task in mind. On a page for connecting an integration, for example, feedback should be available there if the connection fails. On a first-project screen, users might have a question about what to do next. A single feedback button can serve both pages, while the page context helps you tell where a message came from.

A widget is one option, not a fit for every onboarding flow. If users already have a clear support route, keep it visible. If a step involves sensitive information or a focused task, consider whether a feedback launcher would distract or create uncertainty. For more on placement decisions, see the guide to where to place a feedback widget on your SaaS website.

Choose feedback types and wording with care

Enable the categories that make sense during setup. Issue is useful for bugs, errors or confusing behaviour. Question gives users a way to ask for clarification. Idea can capture a suggestion about the onboarding experience. You do not need to enable every type if some are unlikely to help you make a decision.

Keep the form prompt plain and specific. A visitor who has just encountered a setup problem should not have to work out what kind of detail you want. For instance, ask what they were trying to do and what happened. A short message is a starting point for investigation, not a substitute for testing the issue yourself.

Example widget copy

The following is a hypothetical example, not tested or proven best practice. Adjust it to match your product’s onboarding steps and tone.

• Heading: “Feedback on setup”

• Supporting text: “Tell us what you were trying to do and what happened. We read every message.”

• Message label: “What should we know?”

• Placeholder: “For example, I tried to connect… and…”

• Submit button: “Send feedback”

Avoid asking for information the page context already provides. A visitor may still need to describe the action they took, what they expected, and what happened, but they should not have to copy the page URL or identify their device if the widget records that context.

Decide whether to allow reply requests

An optional reply request can help when a user is reporting an issue you may need to clarify. It also asks for an email address, so consider whether you can follow up and whether that is useful for the feedback you expect. If you do not need to contact users, you can leave reply requests off. An email address need not be required for an ordinary feedback submission.

If you allow replies, set expectations in the form wording. Do not imply that every message will receive a personal response unless your team can deliver that. Feedback collection is not a live-chat or support-ticket system.

A hypothetical onboarding flow

Imagine a small SaaS product that guides a new account through creating a workspace, connecting an integration and importing its first project. The widget is available on those setup pages, but it does not open automatically. A user who cannot connect the integration can select Issue and describe the error. Someone unsure what to do next can choose Question. A suggestion about making the import step clearer can be sent as an Idea.

When reviewing a message, the founder can see the page title, page path, full URL and received time. Available browser, operating system, device and display details may add context. This can reduce basic follow-up questions, but it does not explain the user’s intent or reproduce the problem on its own. The message still needs enough detail to investigate.

Review feedback without treating every request as a task

After collecting feedback, look for the issue behind the message. One report may point to a defect; several similar messages may suggest a recurring obstacle. Neither automatically means you should change the product. Check the report against your product goals, what you can reproduce, and other evidence available to you.

A lightweight review routine helps keep useful messages from disappearing in email. Read new items in Needs review, save messages worth considering for later, and archive those that need no further attention. If you decide to act on related feedback, connect several messages to one outcome-focused planned change. Keep the original customer wording intact and move the change through Planned, Building and Shipped as the work progresses.

Set up an unobtrusive feedback widget

With Feedback Bubble, go to Dashboard > Bubbles > New bubble to create a widget, then set the website where it will appear. In the editor, choose an accent colour, launcher icon and corner position; select the enabled feedback types; and customise the form and success wording. The live preview lets you inspect the open and closed states while you adjust the settings.

The widget records page and device context when available, so visitors can send a message without filling in a long diagnostic form. After saving ordinary design or wording changes, the existing site key continues to load the updated configuration; the installation script does not normally need to be added again. See the guide to customising a feedback widget for more on the settings.

Before publishing a setup guide that describes current editor controls, have an editor verify them in the live product and capture a screenshot of both the configured widget and its visitor view. Interface details can change, and a screenshot should show the actual current setup rather than an assumed example.

To start, pick one onboarding step where feedback would be useful, configure a short form for that page, and review the first messages before expanding it across the flow.