Tracking Feature Requests on a Customer Feedback Board

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.

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.

Define one intake path for product requests so customer observations do not split across inboxes, chat transcripts, and private notes. Record the source when a request enters the review queue.

Use a concise request title that names the customer problem rather than promising a solution. Preserve the contributor's original context separately from the owner's interpretation.

Review new intake on a predictable schedule. Assign an owner for triage so unanswered requests do not become an unowned backlog that customers and teammates stop trusting.

Compare each new request with existing records before creating another roadmap item. Link related requests while keeping materially different workflows separate.

Treat votes as participation evidence, not an automatic priority score. Consider severity, recurrence, affected users, strategic fit, and the effort required to test a response.

Use a small status vocabulary that reflects decisions the team actually makes. Avoid labels that imply delivery commitments before work has been scheduled.

Add decision history when an owner investigates, defers, declines, or accepts a request. State which evidence changed the decision so later reviewers can understand the tradeoff.

Return to older requests when product behavior or strategy changes. Close obsolete records, update relevant context, and link shipped work to the problem it was intended to solve.

Separate customer demand from internal, synthetic, and agent-generated activity. 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.

Give coding agents scoped access only when an automation needs it. Keep owner credentials on a server, label each token by consumer, and revoke it when the integration ends.

Measure the path from intake to owner response rather than counting submissions alone. Look for missing context, slow review, and decisions that never reach contributors.

Export or summarize reviewed requests for planning. Keep the board as the source of truth and preserve provenance for every copied decision record.

Ask for the affected workflow, expected result, and observed result during intake. Avoid sensitive information and keep reproduction details focused on the product decision.

Group requests by the underlying customer need before roadmap review. Compare outcomes across groups without treating shared vocabulary as proof that two problems are identical.

Invite follow-up context when a request is ambiguous. Record the clarification beside the original submission so later reviewers can distinguish customer evidence from owner interpretation.

Share concise updates after a decision changes. State the evidence that mattered and avoid implying a delivery promise until the work is actually scheduled.

A VoteWant property has a generated widget snippet that is installed immediately before a site's closing body tag.

The VoteWant feedback button opens a modal that visitors can close with its Close button, the Escape key, or a click outside the modal.

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 is positioned as customer request tracking for product owners.

Without a data-target option, the VoteWant feedback button appears immediately after the widget script tag.

VoteWant documents public board reads through its API and a read-only public TypeScript client; owner and agent write access remains separately gated.