How VoteWant Works for Product Owners
VoteWant provides a feedback board that a product owner can place on a website, app, or game. Each product property in VoteWant has a generated widget snippet. A VoteWant property has a generated widget snippet that is installed immediately before a site's closing body tag. When a browser loads the installed VoteWant script, it sends a minimal installation observation to VoteWant; the setup evidence check reads that server record and does not mark installation complete merely because a button was clicked.
The feedback board belongs to the product property named in VoteWant. VoteWant provides a feedback board that a product owner can put on a website, app, or game. A VoteWant property has a generated widget snippet. VoteWant presents one board for each product property. VoteWant's product page describes customer feature requests, bug reports, and votes as feedback inputs for an owner's product decisions. The board belongs to the product property named in VoteWant, while the widget supplies the feedback entry point on the product's own interface.
Widget Installation and Placement
Without a data-target option, the VoteWant feedback button appears immediately after the widget script tag. A developer may choose an existing interface element for the VoteWant launcher with the widget's data-target option. The data-target option accepts a CSS selector for an existing page element; an invalid or absent target preserves placement immediately after the script tag.
VoteWant's current widget accepts light or dark themes, square, rounded, or pill shapes, and six-digit hexadecimal accent colors. VoteWant does not support custom widget scripts, arbitrary widget CSS, or removal of VoteWant attribution; the standard template and modal controls remain part of an installation. The VoteWant feedback button opens a modal that visitors can close with its Close button, the Escape key, or a click outside the modal.
Board Activation and Public Access
A VoteWant property stays private while its owner prepares it, and its installed feedback button becomes available to visitors after public activation. Documentation for widget installation is available at https://votewant.com/docs/widget.
VoteWant documents public board reads through its API and a read-only public TypeScript client; owner and agent write access remains separately gated.
VoteWant provides a public, CORS-enabled API at GET /api/v1/boards/{board-slug}. GET /api/v1/boards/{board-slug} returns an activated board's public name, owner name, and public request summaries; the endpoint is CORS-enabled and requires no secret. Private, depublished, and otherwise non-public VoteWant boards return 404 from the public board API, which follows the same publication rules as rendered board pages.
VoteWant instructs owners to keep scoped, revocable owner tokens in a server-side secret manager and not in a browser, app bundle, or game client; the current owner API creates private properties while setup progression and activation remain separately gated.
Getting Started
VoteWant has an onboarding route at https://votewant.com/onboarding for owner-controlled setup.
Start by naming the decision you need to make. Write a narrow request title, describe the observed problem, and separate the requested outcome from a proposed implementation. This keeps your review focused on customer need instead of locking your team into the first solution someone suggests.
Ask contributors to include concrete context from the moment the problem occurred. Record the task they were attempting, the result they expected, and what happened instead. Avoid collecting sensitive information. Clear context helps you compare requests without treating every submission as equally urgent.
Review related requests together before you prioritize them. Compare the underlying need, the affected workflow, and the evidence attached to each item. Keep distinct problems separate even when they share vocabulary. Combine records only when they describe the same decision and would lead to the same product response.
Use votes as one signal rather than an automatic roadmap. Look at who is affected, how often the problem occurs, and whether the request supports the direction you have chosen. Consider whether a smaller group with a severe recurring problem deserves attention before a larger group expressing casual interest.
Record your decision after review. State whether you will investigate, defer, decline, or build the request, and explain the evidence that mattered. Use a visible rationale to help contributors understand the tradeoff and give your team a durable record when similar feedback appears later.