Product Feedback Decision History for Owners
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. VoteWant is positioned as customer request tracking for product owners. VoteWant public request pages include a Decision history section, and approved VoteWant-owned demo content can show provenance and visible owner decisions. A developer may choose an existing interface element for the VoteWant launcher with the widget's data-target option.
Without a data-target option, the VoteWant feedback button appears immediately after the widget script tag. VoteWant documents data-theme, data-shape, and data-color options for the widget launcher while retaining VoteWant attribution and the standard modal behavior. The VoteWant feedback button opens a modal that visitors can close with its Close button, the Escape key, or a click outside the modal. 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.
Product details
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. A VoteWant property stays private while its owner prepares it, and its installed feedback button becomes available to visitors after public activation. VoteWant has an onboarding route at https://votewant.com/onboarding for owner-controlled setup. VoteWant calculates lexical duplicate suggestions before a public request is submitted, and its owner inbox can show duplicate clusters for review.
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. VoteWant publishes widget installation documentation at https://votewant.com/docs/widget. The widget's data-board value is the VoteWant property identifier and the documentation instructs developers to keep the generated value unchanged.
Product details
VoteWant's current widget accepts light or dark themes, square, rounded, or pill shapes, and six-digit hexadecimal accent colors. A property setup page can provide coding-agent instructions that add the exact widget snippet, avoid unrelated scripts, and verify the modal's Close button, Escape key, and outside-click behavior. VoteWant documents public board reads through its API and a read-only public TypeScript client; owner and agent write access remains separately gated. 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. A verified VoteWant owner can merge duplicate requests on the same board; the merge records an audit and preserves distinct verified-human vote attribution on the surviving request. VoteWant renders public board visitors as anonymous until they authenticate, while public request submission and voting require a verified human identity; a verified human can vote once per request. 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.
Product details
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.