Website feedback widget

Collect the request without losing the page, customer, or next step.

Install one branded customer surface for feedback, voting, comments, history, roadmap, changelog, surveys, chat, search, tours, highlights, and web messages.

08
Razuna application with the Managani Feedback drawer open beside the active workspace
Real embedded Managani experience in Razuna: search, chat, feedback, and product updates stay inside the application.
The answer first

A feedback widget should remember where the request came from.

A website feedback widget gives visitors or signed customers a way to report a problem, ask for an improvement, vote, or continue a discussion without leaving the product. The valuable part is not the floating button. It is the context the workflow retains after someone submits.

Managani connects signed Widget users to stable customer profiles. Their feedback can retain identity, account metadata, page context, votes, comments, attachments, subscriptions, approval, visibility, status, assignee, roadmap placement, and a linked changelog release. The same installation can also expose chat, public roadmap, changelog, search, surveys, tours, highlights, and web messages.

One installation

Choose the customer surfaces each deployment should expose.

01

Feedback and history.

Let signed customers submit, upload supported attachments, vote, comment, subscribe, and review the requests connected to their identity.

02

Roadmap and changelog.

Show approved public direction and shipped updates, then let customers move between the original request and the release that addressed it.

03

Guidance and conversation.

Use chat, public knowledge search, surveys, tours, highlights, and Web Messages without installing an unrelated script for every experience.

Installation workflow

Install the public key. Keep customer signing on the server.

  1. 1

    Create a site and deployment.

    Choose the allowed domains, experience type, layout, launcher behavior, wording, and visible sections. Create separate deployments when products or environments need different rules.

  2. 2

    Add the public script.

    Load the Managani script with the public site key. The site key identifies the public configuration and is safe for browser code; it is not the signing secret.

  3. 3

    Identify signed customers.

    Generate the user token on your server with a stable external ID and trusted account metadata. Expose only the signed token to the browser.

  4. 4

    Choose public and private behavior.

    Anonymous visitors can browse approved public content and start chat. Signed identity is required for participation, customer history, personalized targeting, surveys, and customer-linked tracking.

  5. 5

    Test the actual product surface.

    Verify the launcher, drawer, inline, or framed layout across routes, modals, drawers, mobile widths, signed-out visitors, and each customer segment you intend to target.

Brand and deployment

One site can support different experiences.

The marketing site, application, and customer portal do not need identical launcher behavior.

1

Choose the layout.

Use an overlay drawer, inline experience, framed surface, or chat-focused presentation based on the surrounding page and job.

2

Control visible sections.

Expose the complete customer home or only the feedback, roadmap, changelog, search, or chat paths relevant to that deployment.

3

Match the product.

Configure theme, logo, color, type, spacing, navigation wording, empty states, forms, and the launcher so the surface feels intentional.

Limitations

Not a visual bug-annotation tool.

Managani does not position the feedback widget as a replacement for screenshot markup, automatic console capture, browser diagnostics, issue-tracker delivery, or agency proofing. Use a specialist when the primary job is pointing at a pixel and generating a technical bug report.

Product boundary

Identity makes the loop useful.

A public form can collect text. Managani is strongest when the signed customer, account, product activity, request, roadmap decision, release, and follow-up remain connected. That requires a trusted server-side identity integration.

What to verify before launch

Test the widget as a customer, not only as an administrator.

Open every enabled surface in a signed-out browser, with a newly signed customer, and with an established account. Confirm that public requests expose only approved information, private history belongs to the correct identity, and the launcher does not cover navigation or form controls at narrow widths.

Submit one real test request and follow it through moderation, a merged duplicate, roadmap status, changelog publication, and customer notification. Check keyboard focus, screen-reader labels, slow network behavior, script blocking, content-security policy, and single-page navigation. Document who owns incoming requests and how quickly the team will respond. A technically installed feedback button without an operating habit becomes another silent inbox.

FAQ

Website feedback widgets, answered plainly.

What is a website feedback widget?

It is an embedded customer surface that lets someone share feedback without leaving the current website or product. Depending on the tool, it may also support voting, comments, public boards, surveys, or customer history.

Can anonymous visitors submit feedback?

Anonymous visitors can browse approved public content and use chat. Feedback participation and customer-linked history require a signed user token so identity is stable and controlled.

Can the Widget show more than feedback?

Yes. One deployment can expose chat, feedback, roadmap, changelog, public search, surveys, tours, highlights, Web Messages, and product tracking.

Is the site secret safe in JavaScript?

No. Never put the site secret in browser code. Use the public site key in the script and generate signed customer tokens on your trusted server.