Website Feedback Widgets: Setup & Research Guide

A website feedback widget gives visitors a way to share an experience without leaving the site to find a separate research invitation. It can collect a short form response, open a conversation, or connect someone to support. Choose the behavior based on what the visitor needs and what your team wants to learn.

For customer research, start with a specific question. “Collect more feedback” does not tell you where to place the widget, what to ask, or how to decide whether the answers were useful. “Understand what blocked new administrators during setup” gives you a clearer starting point.

Separate the purpose from the interface

A floating button and an inline panel are presentation choices. The underlying experience could be a fixed survey, a branching form, or an adaptive AI interview. Be explicit about what happens when someone opens it.

If the experience is for research, say that. If it cannot resolve account issues, provide a clear route to actual support. A person reporting an urgent problem should not have to complete a research interview to discover that no one can fix it there.

For the difference between questionnaire and interview behavior, see conversational surveys vs. traditional surveys.

Choose a placement with relevant context

Consider when the visitor has enough experience to answer the question. A new visitor on a home page can describe expectations, but may know little about a product workflow. Someone who just completed or abandoned a setup step can offer a more relevant account of that experience.

Possible research placements include:

After setup: Ask what helped or slowed the first attempt.
Beside a newly released feature: Invite people who have used it to describe a recent task.
On a cancellation confirmation page: Offer an optional explanation after the account action is complete.
Within a help area: Ask what the person was trying to understand, while preserving access to support.

These are proposed study designs, not claims that the product automatically detects those events. Your website or application determines where the embed appears. Decide whether the placement is appropriate for the audience and context.

Avoid obstructing the primary task. A feedback invitation that covers a form control or repeatedly interrupts someone may affect both the experience and the kind of response you receive.

Write a clear invitation

A useful invitation identifies the subject and the action. For example: “Tell us about your setup experience. You can answer by voice or text.” If the interviewer is AI, make that clear before someone starts.

Use a time estimate based on testing your own guide. Explain how the information will be used and provide relevant privacy information. Do not promise anonymity if you pass an account identifier or collect identifiable information.

Here is starting copy to adapt:

Help us understand your setup experience. An AI interviewer will ask about what you tried and what happened. Participation is optional. Please review how we use the conversation before starting.

The GOV.UK informed consent guidance is useful background on explaining research participation. Use your actual arrangements when finalizing the invitation.

Keep the conversation focused

For an onboarding study, a small topic set could cover:

What the visitor was trying to accomplish.
What they tried first.
The point at which something became difficult or unclear.
What they did next.
Whether they reached the outcome they needed.

Follow a useful detail rather than introducing every topic on your product roadmap. Keep suggestions and opinions distinguishable from accounts of what happened. The customer discovery question bank contains follow-ups you can adapt.

Decide what the interview should do if someone asks for help, skips a question, or wants to stop. Rehearse those paths before the widget is visible to customers.

Embed a Stetos.co interview agent

Create and test an agent in Stetos.co, then obtain the agent identifier from its distribution settings. The public documentation describes the supported embed configuration.

For a floating launcher, the basic script is:

<script
  src="https://www.stetos.co/widget/stetos-widget.js"
  data-agent-id="YOUR_AGENT_ID"
  data-mode="bubble"
  defer
></script>

Replace the placeholder with your own agent identifier and place the script on the page where you want the launcher. Stetos.co also supports an inline embed; use the generated configuration and current documentation for that layout.

You can share the agent’s link when adding code is inconvenient. The research question, invitation, and participant experience still need the same review.

Test the complete visitor experience

Check more than whether a button appears. Run a rehearsal on desktop and mobile, with keyboard access and each language you intend to use. Verify that:

the launcher can be found and opened;
the feedback panel does not obscure an essential task;
the visitor can choose an available voice or text experience;
the conversation starts only after the visitor chooses to participate;
the panel can be closed and the original task resumed;
completed sessions appear in the intended project;
summaries and configured measures make sense against the transcript.

Test voice permissions on the devices relevant to your audience. Do not assume that successfully loading the widget proves microphone behavior or interview quality.

Measure participation and usefulness separately

Record the relevant exposure or invitation, starts, and completions. Define the units clearly. Unique visitors, page views, accounts, and sessions produce different denominators.

Use your own site measurement to establish widget exposure if you need it; do not assume a session count provides that number. In the research workspace, review whether completed conversations contain specific experiences and information relevant to the decision.

Also note who responded. People who volunteer feedback can differ from the rest of your audience. If the widget reaches only active users, it may miss those who stopped visiting. Pair it with a separate invitation strategy when the research question requires those experiences.

Close the loop with a reviewable action

At the end of a pilot, document what the team learned, the conversations supporting it, and what remains unanswered. Assign an owner to the next investigation or experiment. Preserve the distinction between a support issue that needs resolution and a research theme that needs further work.

Use the interview analysis worksheet to write that decision record. To see the participant experience before installing a widget, try the Stetos.co demo, then review current pricing and allowances for your planned study.