Feedback Status Updates: What to Send and When
A feedback status update tells the person who made a request where it stands: received, under review, planned, in progress, shipped, or declined. The update that matters most is the one that reaches the original requester at the moment something changes. Teams that skip it get a familiar result: users stop submitting, because they assume nobody is reading.
This guide covers the status labels worth using, the emails that go with each one, how fast to respond, how to announce a release to the people who asked for it, and the policy that holds the system together.
TL;DR
- Use a short, fixed set of statuses (under review, planned, in progress, shipped, and a declined or closed state) and define each one publicly.
- Acknowledge new feedback within 24 to 48 hours, then notify people automatically whenever the status of their request changes.
- When a feature ships, email the people who asked for it, by name and with a reference to their own request, instead of relying on a generic newsletter.
- Publish a short feedback policy so users know how requests are reviewed and when to expect news.
- Tell people "no" too. A clear decline beats silence.
Table of Contents
- Why status updates decide whether people keep giving feedback
- Pick a small set of statuses and define them
- The emails that go with each status change
- Release emails: personal first, public second
- Choose the channel for each update
- Publish a feedback policy
- Ask for structure at the door
- A weekly routine that keeps updates moving
- Our perspective
- Running status updates on a Petĩra board
- Common mistakes to avoid
- FAQ
- Sources
Why status updates decide whether people keep giving feedback
Most feedback programs do not fail at collection. They fail afterward. A write-up on the feedback transparency gap describes users abandoning feedback portals when they feel their input disappears into a black hole, and recommends telling users specifically when their own requested feature ships instead of leaning on generic announcements.
The same piece frames feedback as a two-way relationship, not a data-gathering utility. Teams that reach customers by email or in-app message the moment a status changes turn a static list of requests into something that adds value to the product.
Think about it from the user's side. They typed out an idea, maybe voted on three others, and heard nothing for four months. The next time you ask for input, they have no reason to answer. A status update is cheap to send and is often the only visible proof that a human read the request.
Pick a small set of statuses and define them
Statuses are the vocabulary of your updates. Keep them few, and make each one mean a single thing. The set we see work best for a public board is:
| Status | What it tells the user | What you owe them |
|---|---|---|
| Under review | We read it and are weighing it | An acknowledgment, plus when to expect a decision |
| Planned | We intend to build it, with no promised date | A note on rough timing, if you can give one honestly |
| In progress | Someone is working on it now | Optional progress notes, a beta invite if relevant |
| Shipped | It is live | A personal notification and a link to the release notes |
| Closed or declined | We will not build it, or it duplicates another request | A short reason and, if possible, a workaround |
A few rules keep this honest:
- Never use "planned" as a polite no. If the request will probably never be built, say so. Users forgive a decline far more readily than a plan that goes nowhere.
- Merge duplicates visibly. Move the votes and tell the people on the duplicate that they now follow the main request.
- Do not attach dates unless you will hit them. "This quarter" is a promise. A status label is not.
If you need a way to decide which requests move from "under review" to "planned," our guide on how to prioritize feature requests without guessing walks through it.
The emails that go with each status change
Status emails are short. Each should answer three questions: what changed, what it means for the reader, and what happens next. Here are templates you can adapt.
Acknowledgment (within 48 hours)
Subject: We got your idea: [short title]
Hi [Name], thanks for suggesting [title]. It is now on our board with the status Under Review. We go through new ideas every week, and you will get an email when the status changes. You can add detail or follow other votes here: [link].
Industry guidance on closing the loop puts the sweet spot for acknowledging feedback at 24 to 48 hours, which leaves time for a thoughtful reply while the user is still engaged. After that window, the chance to build trust through responsiveness shrinks quickly.
The acknowledgment does not need to be long. The flagup piece notes that an honest, specific commitment, such as reviewing feedback weekly and updating the status within 14 days, builds more trust than a generic thank-you. Only promise a window you can keep.
Moved to planned
Subject: Good news on [title]
Hi [Name], we have moved your request, [title], to Planned. We do not have a release date yet, and we will not guess at one. When work starts, the status will change to In Progress and you will hear from us.
In progress
This one is optional but valuable for requests with many votes. A single line works: "Work has started on [title]. Want to try an early version? Reply and we will add you." Early testers give you sharper feedback than a launch ever will.
Shipped
Subject: [Title] is live
Hi [Name], you asked for [title] on [date]. It shipped today. Here is what it does and how to turn it on: [link to release notes]. If it does not work the way you expected, reply to this email and tell us.
Keep the date and the reference to their own request. The Koji playbook describes the same pattern: when a change ships, email back the specific people who reported the underlying issue and remind them what they told you.
Declined or closed
Subject: An update on [title]
Hi [Name], we have decided not to build [title] right now. [One honest sentence on why: it does not fit the direction of the product, or it overlaps with X.] Here is what you can do today instead: [workaround]. We have kept your request on file and will revisit it if our direction changes.
For support teams who answer these by hand, we have a longer set of feature request email templates with six ready replies.
Release emails: personal first, public second
A release announcement does two jobs for two audiences, and mixing them weakens both.
- The personal notice goes to people who requested or voted for the feature. It is short, references their request, and lands the same day the feature ships.
- The broadcast release note goes to everyone else: a newsletter, an in-app announcement, a changelog entry. It explains what is new and who it helps.
Many teams only do the second. The result: the person who asked for the feature in March learns about it from a list of eight other updates in a monthly email, or never notices at all.
A good broadcast release email contains:
- A subject line that names the feature, not the version number.
- One sentence on the problem it solves.
- A screenshot or short clip.
- A link to the full release notes.
- A line that credits user feedback, such as "Many of you asked for this."
HubSpot's guidance on launch emails also suggests listing major updates, like fixes or a pain point that has been relieved, in their own section. That structure works for release roundups as well.
Choose the channel for each update
Email is the default because it reaches people who are not in your product. It is not the only option, and the best setups combine a few:
- Email: best for requesters who may not log in often. Use it for shipped and declined notices.
- In-app message: best for active users. Pair it with a link to your public roadmap.
- Public board: the status label itself is an update. Anyone can check without asking.
- Slack, Discord or GitHub: best for internal triage and for open-source or developer audiences. Our guide to connecting user ideas to GitHub issues shows how a closed issue can become a status change.
Research from 2025 and 2026 summarized by flagup says high-trust teams automate notifications across the customer's preferred channels as soon as a status changes. Automation matters because manual updates are the first thing to slip when a team gets busy.
Publish a feedback policy
A feedback policy is a short public page that says how requests are handled. Practitioners at companies such as Atlassian and Pendo point to a transparent product feedback policy as one of the best ways to manage expectations, since it states how feedback is processed, prioritized and communicated. The Koji playbook calls it a foundational step that many teams overlook.
A useful policy is half a page, not ten. Cover:
- Where to submit ideas and what makes a good request.
- How often you review the board.
- What each status means.
- What you will always notify people about (shipped and declined, at minimum).
- What you will not promise, such as dates or that every request will be built.
Writing it down also forces your own team to agree on the process. If you want an example of how to keep decisions and their reasoning documented so they do not get lost, this piece on retention bands for team documentation is relevant to how long you keep policy notes and past decisions.
Ask for structure at the door
Status updates are easier to write when requests are easy to understand. A large empirical study of feature requests on GitHub found that requests that are overly long or poorly structured are harder for teams to triage and resolve. A short form with a title, the problem, and the situation where it comes up gives you something you can summarize in a status email without a back-and-forth.
We have collected four feature request templates that product teams can copy for this purpose.
A weekly routine that keeps updates moving
You do not need a big process. This one fits in an hour a week:
- Monday: review new ideas. Acknowledge anything that slipped past 48 hours. Merge duplicates.
- Midweek: change statuses based on what the team decided. Every change triggers the notification.
- On release day: move shipped items to "shipped," confirm the requester notifications went out, and publish the broadcast note.
- Monthly: scan "planned" items older than a quarter. Either move them forward or close them with an explanation.
If you want a fuller version of this routine, five steps teams can assign and verify lays out who owns each part of closing the loop.
Our perspective
We built Petĩra around a simple belief: a feedback board that never changes status is worse than no board. The status is the product. Votes tell you what people want, but status changes tell people you listened.
That is why every plan includes unlimited users, ideas and votes at a flat rate. We do not want a team to hesitate about inviting more voices because the bill grows with participation. More requesters means more people to notify when something ships, and that is where the value comes from.
In practice, we recommend teams start with four public statuses (under review, planned, in progress, shipped), add a closed state for declines, and let email notifications run automatically on each change. Pair that with a public roadmap so users can check on their own. Our guide to public product roadmap formats shows how to present it.
We also think moving between tools should not mean losing history. If you are coming from another board, you can import from Canny, Fider or a CSV, and you can export or delete all of your data at any time. Your feedback belongs to you and the people who wrote it.
— Aron
Running status updates on a Petĩra board
Petĩra gives you the public board, the status labels (under review, planned, in progress, shipped), the roadmap, comments, moderation, email notifications, and Slack, Discord and GitHub integrations in one place. You can start on the Free plan at €0 per month. Pro is €19 per month (or €190 per year) and Team is €49 per month (or €490 per year). See what each plan includes on the pricing page, or look at the Petĩra homepage to see how the board works.
If you also gather feedback inside your product, pairing timed surveys with a public board keeps everything in one status flow. And for the wider picture on where input comes from, see how teams collect user feedback through always-on channels.
Common mistakes to avoid
- Silence after "thanks." An automatic confirmation is a start, not an update.
- Statuses nobody defined. If "under review" means three things internally, users will read it as a brush-off.
- Only broadcasting. A monthly newsletter is not a substitute for telling the requester directly.
- Over-promising dates. One missed date does more damage than no date.
- Ignoring negative replies. Some users will push back on a decline. Answer calmly; our scripts for handling negative feedback help.
- Marketing in the update. A status email is about their request. Save the upsell for another message.
FAQ
How often should I send feedback status updates?
Send one whenever a request changes status, plus an acknowledgment within 24 to 48 hours of submission. Do not add a recurring "still working on it" message unless something has really changed. A weekly review of the board is enough to keep statuses current.
What should a status update email include?
Include the title of the request, the new status, what it means, and what happens next. For shipped features, add a link to the release notes and invite replies. Keep it to a few sentences and address the person by name.
Should I tell users when I decline a request?
Yes. A short, honest reason and a workaround, if one exists, keeps trust intact. Silence leaves people guessing and teaches them that the board is a black hole. Decline notices also stop the same request from being filed again.
What is the difference between a release email and a status update?
A status update goes to the people attached to one specific request and refers to what they asked for. A release email goes to your wider audience and describes what is new. Send both when a feature ships, since they serve different readers.
Sources
- The Feedback Transparency Gap SaaS Teams Miss
- Closing the Loop on Customer Feedback: The 2026 Playbook for Inner and Outer Loops
- Maximizing the value of customer feedback for product teams
- Understanding Feature Request Practice on GitHub via a Large-Scale Empirical Study
- How to Create a Product Launch Email