A customer submits a sensible feature request, but the post includes employee email addresses, an internal deadline, and a screenshot of account data. Another customer submits the same idea under a different title, while a product manager has already discussed it privately with three larger accounts.
Publishing everything creates risk. Hiding everything makes the board useless. Upvoty helps teams operate between those extremes, but the rules still need to come from the product team.
Quick answer: how to govern public feedback boards
Use this workflow for every new submission:
- Define the publication policy before accepting public submissions.
- Screen each request for relevance, clarity, abuse, and sensitive information.
- Redact or privatize details that identify people, accounts, security controls, or confidential plans.
- Merge duplicate requests into a canonical post without erasing meaningful differences.
- Publish a normalized version that describes the user problem without making a delivery promise.
- Respond and update statuses consistently using rules shared by support, product, and customer success.
- Review the board regularly to close stale requests, correct outdated replies, and move shipped work into the changelog.
The rest of this guide explains each step using a fictional SaaS company called Meterly. Its team receives a request titled “Need SSO for our contractors by September,” complete with a customer domain, six employee email addresses, and an admin screenshot.
1. Define what belongs on public feedback boards
A public board is a publication channel, not a raw database of every customer conversation. Decide what can appear before the first request arrives. Otherwise, moderators will make inconsistent calls under pressure.
Start with purpose. A board might collect feature requests, usability improvements, integration requests, or ideas about an existing workflow. It should not become the default destination for billing disputes, urgent support incidents, security reports, legal complaints, or account-specific bugs.
Write a short submission policy covering four outcomes: publish, edit and publish, keep private, or reject. Make that policy visible near the submission form and repeat the most important restrictions in the form itself.
A workable policy might say:
- Describe the problem and the result you need, not confidential implementation details.
- Do not include passwords, API keys, personal data, private URLs, or customer records.
- Send security vulnerabilities and urgent account issues through designated private channels.
- Similar requests may be merged to keep voting and discussion in one place.
- Votes indicate demand but do not guarantee development or a delivery date.
- Abusive, promotional, unlawful, or unrelated submissions may be removed.
Keep this policy short enough to read. A detailed internal moderation guide can handle edge cases.
Meterly’s SSO submission belongs on the board because it describes a product capability that could help multiple accounts. The original version should not be published, however. The employee addresses and admin screenshot add privacy risk without helping other voters understand the need.
This boundary is easier to maintain when public requests and internal evidence are stored separately. The public post can say that contractor accounts need centralized authentication. Account identity, contract stage, expected seat count, and the requested deadline can remain in an internal note.
If you are still deciding how a board fits into your wider intake process, use the feature request management workflow to connect collection, review, prioritization, and follow-up.
2. Moderate public feedback board submissions before publication
Moderation should happen before a post becomes searchable, shareable, or visible to other customers. A five-minute delay is easier to explain than a screenshot that remains indexed or copied after deletion.
Run each submission through the same sequence. First, confirm that it concerns the product. Next, identify the underlying user problem. Then inspect the title, description, attachments, links, and comments for information that should not be public. Finish by checking for duplicates.
Do not judge the request only by how well it is written. Customers often describe solutions because they do not know your architecture. “Add an Okta button” could represent a broader need for SAML authentication, automated provisioning, or centralized access control. A moderator should preserve the need while removing assumptions that would distort later prioritization.
Reject spam, harassment, impersonation, and content that creates a credible legal or safety concern. Move support cases into support. Route vulnerability disclosures to the security process rather than asking the reporter to discuss them in public.
Use a response that explains the next destination. “This looks like an account-specific login issue, so we have moved it to support” is better than silently deleting the submission. The customer needs to know whether someone will act on it.
For Meterly, the moderator identifies three actions. Remove the screenshot, replace the customer-specific title, and send the affected account a private note confirming that its deadline has been recorded as context rather than accepted as a commitment.
The new public title becomes “SAML SSO for external and contractor accounts.” The body explains that administrators need to apply their identity provider’s access policies to people who are not full-time employees. That version is useful to other customers.
A documented moderation process also limits internal bias. Without one, a familiar customer may receive careful editing while a less polished request gets rejected. Apply the same publication criteria regardless of account size. Commercial importance belongs in prioritization, not in basic publication standards.
3. Keep sensitive customer feedback private
Sensitive information is broader than passwords and payment details. It includes anything that could expose a person, customer account, security posture, private commercial plan, or unreleased operational change.
The following governance matrix gives moderators a practical default. Adapt it with legal and security teams for your product and customer base.
| Submission detail | Public treatment | Private treatment | Moderator action |
|---|---|---|---|
| General workflow problem | Publish | Add account context if useful | Rewrite for clarity without changing intent |
| Employee names or email addresses | Remove | Retain only when needed and permitted | Redact before publication |
| API keys, tokens, or credentials | Never publish | Follow the security incident process | Remove access, escalate, and request rotation |
| Customer-specific screenshot | Usually remove | Store only in an approved support system | Replace with a generic description |
| Contract value or renewal deadline | Do not publish | Record for prioritization with restricted access | Acknowledge privately without promising delivery |
| Security vulnerability details | Never publish before coordinated handling | Route to the security team | Hide the post and contact the reporter privately |
| Unannounced product or partnership plan | Do not confirm publicly | Verify internally | Use a neutral response and avoid speculation |
Collect less data where possible. The European Union’s GDPR includes data minimization among its principles for processing personal data, requiring personal data to be adequate, relevant, and limited to what is necessary. Even when a specific law does not apply, collecting unnecessary identifiers creates avoidable work and exposure.
Redaction must cover attachments as well as text. Screenshots often contain names in navigation menus, browser bookmarks, workspace URLs, notifications, or records behind the highlighted area. Downloading and cropping an image can also leave hidden metadata or overlooked content. Recreate a generic example when the visual itself is not essential.
Do not copy secrets into an internal note merely because notes are private from customers. Credentials should not live in feedback software. Follow the organization’s incident procedure and ask the customer to rotate exposed credentials. The OWASP guidance on secrets management explains why secrets require controlled storage, rotation, auditing, and restricted access.
Account context can be useful internally, but access should follow job responsibilities. Support may need the original ticket. Product may only need the customer segment and affected workflow. An executive reviewing demand rarely needs the names of individual employees.
Meterly retains a private note stating that an enterprise account needs contractor authentication before its next access review. It does not copy the six email addresses. The original screenshot remains in the restricted support case, not on the feedback board.
4. Merge duplicates on public feedback boards without losing context
Duplicates split votes, fragment discussion, and make demand look smaller than it is. Aggressive merging creates a different problem: related requests can be combined even when users need distinct outcomes.
Search by problem, object, affected role, and desired result. Titles alone are unreliable. “Okta for contractors,” “SAML guest access,” and “Apply SSO to external users” may describe the same need. “SCIM deprovisioning for contractors” is related but not identical because provisioning and authentication involve different product behavior.
Choose the canonical post with care. Prefer the version that describes the broad shared problem clearly, has an accurate scope, and contains a useful discussion. The oldest post is not automatically the best one.
Before merging, preserve any evidence that will not fit the canonical public description. Put customer-specific constraints in internal notes or linked support records. If one duplicate reveals a distinct requirement, add that requirement to the canonical post or keep it separate.
Meterly finds two existing requests. One asks for SAML login for guest accounts. Another asks for Okta support across every user type. The team merges the new contractor request into the broader SAML post because the authentication problem is shared. It keeps SCIM lifecycle management separate.
The public post is updated to mention external and contractor accounts. The internal notes retain the fact that one customer uses Okta and another has a September review. Voters now gather around one request without exposing which account has which deadline.
Tell the submitter what happened. A concise message works: “We merged your request into the existing SAML access post so votes and updates remain in one thread. Your account-specific context is still available to our team.”
Do not claim that ten merged posts represent ten customers. One customer may submit the same request through chat, email, a call, and the board. Separate request volume from unique accounts when analyzing demand. For a fuller scoring method, see how to prioritize feedback by revenue, segment, and demand.
5. Publish requests without turning votes into promises
Once a request is safe and deduplicated, publish a version that another customer can understand without knowing the original account. Include the affected workflow, the user who experiences the problem, and the desired outcome.
Avoid language that implies approval. “Planned for Q3” is a commitment. “Under review” should mean the team is actively evaluating the request, not that it passed moderation. If every published request is automatically marked under review, customers will reasonably assume more progress than exists.
Use a small status vocabulary with written entry and exit criteria. For example, Open can mean accepted for discussion, Under review can mean product discovery is active, Planned can mean the team has approved work for a defined planning window, and In progress can mean implementation has started. Reserve Shipped for functionality customers can actually use.
Statuses should describe product reality, not calm an unhappy account. Never move a request to Planned because a salesperson wants a stronger renewal message. Record commercial pressure privately and let the established planning process decide.
Votes are evidence of stated demand. They are not a queue. A request with fewer votes might address severe churn risk, regulatory requirements, strategic fit, or a blocked customer segment. A popular request may be expensive, conflict with product direction, or represent a symptom better solved another way.
Meterly publishes the canonical SAML request as Open. Product has not completed discovery, so Under review would be premature. The public response says the team is collecting authentication requirements across member types and invites voters to explain which identity providers and user roles they need. It does not mention September.
When a request does move onto a customer-facing plan, give customers enough context to interpret it. The guide to building a public product roadmap customers can trust explains how to show direction without presenting uncertain dates as guarantees.
6. Respond consistently on public feedback boards
Customers compare replies. If one moderator says “great idea,” another says “we will consider it,” and a third promises to send the request to engineering, the board starts communicating accidental differences in priority.
Create response patterns for common decisions, but allow moderators to write naturally. Each response should do three things: confirm what happened, explain what the current status means, and tell the customer what comes next.
For an accepted request, state that it is open for feedback rather than implying approval. For a duplicate, identify the merge and confirm that the vote or context was retained. For a private redirect, name the correct channel without repeating sensitive information. For a declined request, give the product reason when it can be shared.
A useful decline is specific: “We are not planning separate per-project billing because billing is managed at the workspace level across the product.” A vague “not on our roadmap” response gives customers no basis for adjusting their workflow.
Set ownership and a response target internally. A board with unanswered posts feels abandoned even when product teams read every request. Support can acknowledge intake, but product should own status meanings and decisions. Security and legal teams need clear escalation paths rather than access to every routine post.
Do not provide a public date unless the team is authorized to communicate it. If a customer asks when something will ship, explain the status and the condition for the next update. “Discovery is active, and we will update this post when scope is approved” is clear without inventing certainty.
Meterly uses the same response on all merged SAML submissions. When discovery starts, the canonical request moves to Under review and every voter sees the same explanation. Private account conversations can address implementation dependencies, but they cannot contradict the public status.
7. Run the public feedback board workflow in Upvoty
Governance policies become easier to follow when the software reflects them. Inside Upvoty feedback boards, the workflow begins with where and how customers submit a request, then continues through moderation, internal handling, status communication, and release follow-up.
Start by deciding whether the board or a specific collection flow should be public or private. A public board supports visible discussion and voting. A private setup is better for a closed beta, an internal team, or a customer group whose requests routinely include confidential context. Upvoty provides private or public board options so teams do not need one exposure rule for every audience.
Configure the submission form around information moderators can safely use. Ask for the problem, affected workflow, and desired result. Avoid requesting customer records or credentials. Then use moderation controls to review what appears and keep unsuitable content off the public board.
The board shown below gives customers a clear place to submit requests, find related ideas, and vote publicly.
!Public voting board for customer feedback and feature requests
When overlapping requests arrive, Merge AI can help identify and consolidate duplicates. A person should still confirm that the requests share the same problem and scope. Automation can reduce search work, but it should not decide that SAML authentication and SCIM provisioning are equivalent.
Next, place sensitive commercial or account context in internal notes rather than the customer-facing description. Apply team roles so publishing decisions and internal context are available to the people responsible for them. Assignees and priorities can then support internal review without converting those internal decisions into public promises.
As Meterly’s SAML request progresses, the team changes its public status only when the status criteria are met. Voters can be notified when relevant updates occur. Once the work is available, the team moves from request handling to release communication through the Upvoty changelog.
This closes the loop in the order customers experienced it: request, vote, status change, release. The practical guide to closing the customer feedback loop with a changelog covers how to turn the final update into a useful release message rather than a generic announcement.
8. Review and audit public feedback boards
Moderation does not end when a post is published. Product direction changes, links expire, employees leave, and comments can introduce sensitive details long after the original review.
Set a recurring review based on board volume. Check posts with no response, requests stuck in transitional statuses, declined items still presented as active, old comments containing personal data, and roadmap entries with outdated timing. Export board data when you need a broader audit trail or want to examine status age across many requests.
Inspect permissions too. Remove access for people who no longer moderate the board. Confirm that internal notes remain internal and that integrations do not send sensitive content into broad chat channels. The NIST Privacy Framework provides a structured way to consider data processing, governance, control, communication, and protection across systems.
Archive carefully. A low-vote request may still document an important workflow, so deletion should not be the automatic answer. Decline it with a reason if the product decision is settled. Keep it open if the need remains valid but lacks enough evidence. Merge it if demand is scattered across related posts.
Meterly reviews its SAML request after discovery. The team approves authentication for external accounts but excludes automated provisioning from the first release. It updates the public scope, leaves the SCIM request separate, and records the reasoning internally. When SAML support ships, voters receive an update and the changelog links back to the original need.
Measure governance quality through operational signals rather than vote totals alone. Review how long submissions wait for moderation, how many posts require privacy corrections after publication, whether duplicate merges are reversed, and how many status updates miss the team’s review target. Those signals expose process problems before customers lose trust.
Common mistakes with public feedback boards
Publishing submissions automatically is the most serious failure mode. A single exposed token, customer list, or vulnerability report can create more work than weeks of manual moderation would have required.
Another mistake is editing requests until they match the product team’s preferred solution. Moderators should improve clarity and safety, not remove inconvenient constraints. Preserve the original intent privately when substantial rewriting is necessary.
Teams also merge requests based on keywords. Two posts can mention “permissions” while referring to unrelated needs such as role templates and document access. Read the desired outcome before merging.
Status inflation causes quieter damage. When Open, Under review, and Planned all mean “someone saw this,” customers cannot interpret the board. Define each status operationally and correct old posts that do not meet the definition.
Finally, do not leave declined and shipped requests without explanation. A closed post can still help future visitors understand the product decision, find the released feature, or choose a supported alternative.
Public feedback boards FAQ
Should every feature request be public?
No. Publish requests that describe reusable product needs and can be discussed without exposing customer or security information. Keep account incidents, contractual discussions, vulnerabilities, personal data, and confidential research private. A private request can still contribute to aggregate demand and prioritization.
Can moderators edit a customer’s request?
Yes, when editing improves clarity, removes sensitive information, or makes the request useful to a broader audience. Do not change the underlying problem without confirming the revised meaning. For substantial edits, retain the original context privately and tell the submitter what changed.
What should happen to votes when duplicate requests are merged?
Move engagement to one canonical request where the platform supports it, then notify submitters about the merge. Check for repeated submissions from the same account before treating combined activity as unique customer demand. Preserve distinct requirements instead of forcing every related idea into one post.
Does a highly voted request have to go on the public roadmap?
No. Votes show interest, not feasibility, strategic fit, urgency, or commercial impact. Use voting alongside customer segments, qualitative evidence, product strategy, effort, risk, and dependencies. Explain that policy publicly so customers know what a vote does and does not mean.
How often should a public feedback board be reviewed?
Review new submissions according to a defined response target, then audit the full board on a recurring schedule. High-volume boards may need weekly status checks. Smaller boards can use a monthly review, provided urgent privacy and security reports have a separate immediate escalation path.
Should declined feature requests stay visible?
Usually, yes. A visible decline with a concise reason prevents repeat submissions and demonstrates that the team makes decisions. Hide the post if it contains unsafe content, concerns a confidential matter, or creates an ongoing legal or security risk.
How do public boards connect to a roadmap and changelog?
The feedback board captures and discusses demand. The roadmap communicates approved direction at an appropriate level of certainty. The changelog confirms what customers can now use. Keep those stages separate so an accepted request is not mistaken for planned work.
A public board earns trust through careful publishing, consistent statuses, and visible follow-up. Set up your feedback workflow with Upvoty when you are ready to moderate requests, protect private context, merge duplicates, and keep voters informed from submission through release.
