Feedback Board Launch Announcement Template
Copy a feedback board announcement for a new launch or tool switch. Explain participation, existing requests, review cadence, and support with a fictional example.
By Feedbackly · Updated
Product walkthrough
See how public requests, votes, comments, and visible statuses work before writing the participation instructions.
Watch the product walkthroughShow customers the request workflow
Practical context for Feedback Board Launch Announcement Template
A feedback board announcement should tell customers where to go, what belongs there, and what happens after they submit. Copy the version that matches your situation: opening a first board or moving from an existing tool. Replace every placeholder and verify each statement before sending it through your normal customer communication channel.
This is a communication template, not a changelog entry or a delivery commitment. The board can show demand and progress, but a vote does not guarantee that a request will be built. Choose a review cadence your owner can maintain and give account-specific support its own destination.
Announce a first feedback board
Lead with the customer task: suggesting improvements and checking existing ideas. Share a direct board link and explain the difference between adding a vote, providing context, and reporting an account problem. Avoid making customers choose between several unowned feedback destinations.
Describe the next review step rather than promising a response time you have not tested. If the board is public, say so before inviting detailed submissions. Ask customers to describe their task and desired outcome; they do not need to design the implementation for your team.
Subject: Help shape [product] — our feedback board is open You can now suggest improvements and explore existing ideas at [board URL]. Search for your idea first. If it is already there, add a vote or explain the task you need help with. For a new request, describe what you are trying to do, what gets in the way, and the outcome you want. The board is public. Keep account details and confidential information out of requests. For an account problem, contact [private support URL]. [Owner/team] reviews new requests [verified cadence]. We use votes alongside customer context, impact, and delivery effort. Submitting or voting does not guarantee a release or a delivery date. Start here: [board URL] Thank you for helping us understand what would improve your work.
- +Verify the board link from a participant session.
- +Name the person or team reviewing requests.
- +Replace the support link with your actual private support channel.
Explain a move from another feedback tool
A tool-switch announcement needs continuity information. Customers may wonder whether they need to resubmit a request, whether votes moved, and where an existing conversation remains available. Give an accurate answer for each; use a verified archive or support path rather than implying that every historical record appears on the new board.
For Feedbackly CSV migration, selected request text, mapped statuses, and dates can move through the dashboard importer. Historical votes and follower subscriptions do not move automatically. Invite customers to check the new request and follow it if they want updates. Only promise email follow-up after testing a verified subscription and configured delivery.
Define when the new queue becomes the primary intake path and who checks the old one during the transition. A customer-facing message should contain the useful destination and next step; keep row counts, field mappings, and internal migration decisions in the owner's records.
Subject: Our feedback board is moving to [new destination] From [verified cutover date], use [new board URL] for product ideas and feature requests. Existing requests: [Explain which requests moved and how to find them.] Previous votes and discussions: [Explain what transferred and where retained history can be found or requested.] Following progress: [Explain the tested participation and follow-up steps.] Please check for an existing request before creating another. If your earlier idea is missing or its status looks wrong, contact [support URL] with the old request link. The new board is public. Use [private support URL] for account issues or confidential evidence. [Owner/team] will review incoming ideas [verified cadence]. Votes help us understand demand; they are not a promise to build a feature by a particular date. New feedback destination: [new board URL]
- +State what happened to existing requests and votes.
- +Verify any old-request or archive link you include.
- +Explain the primary intake path from the cutover date.
Use a specific example and check the handoff
The fictional example below describes a small product moving selected requests. Its board and support addresses are placeholders, not real destinations or an observed migration. It acknowledges missing historical votes and gives the customer a useful next step without asking them to rebuild the whole archive.
Before publishing your announcement, open the board link, search for a migrated request, and test participation from the intended audience's view. Confirm that the support path works and that someone owns the promised review cadence. After sending, sample incoming requests and support questions to find confusing instructions. A click on the announcement establishes interest, not that customers successfully submitted or understood the switch.
FICTIONAL EXAMPLE — REPLACE PLACEHOLDERS BEFORE USE Subject: Northstar Notes has a new place for feature ideas Our new public feedback board is at [new board URL]. Use it for suggestions about your product workflow. We moved selected active requests and checked their statuses. Historical votes and discussions have not been copied into the new board. If you have a question about an earlier request, send its old link to [support URL]. Search for your idea before posting. You can vote on an existing request and add context about the task you need to complete. Our product owner reviews new ideas every Friday; votes inform that review without guaranteeing a delivery date. Account problems and confidential details belong in [private support URL], not the public board. Explore the new board: [new board URL]
- +Remove all placeholders before sending.
- +Check the message against actual published records.
- +Keep any unresolved transfer limitation visible.
Keep exploring this topic
These next reads help you move from the concept on this page to a framework, tool, template, or deeper comparison you can apply right away.
Questions teams usually ask
Is this announcement sent automatically?
No. Copy the text, verify it against your setup, and send it through your normal communication channel. The template does not create a campaign or notify customers for you.
Should customers submit all their old requests again?
First explain which requests moved and how customers can find them. Invite a support question for missing records rather than requiring everyone to recreate history and produce duplicates.
Can we promise that the highest-voted feature ships next?
Only state a commitment your team has actually made. Votes express demand; review the customer problem, impact, effort, and current priorities before scheduling work.
Prepare the destination before inviting customers
Create a public Feedbackly board during the seven-day trial, verify the participant path, and adapt the announcement to your actual review process.