Closing the loop
How to close the feedback loop with users
· 4 min read · By the Sikia team
On this page
Users who see their feedback acted on keep giving it. Users who hear nothing stop. Closing the loop is mostly a record-keeping problem, not a writing problem.
What does closing the feedback loop mean?
It means the person who gave feedback hears back at each point where something changes:
- Acknowledged: you saw it and logged it.
- Decided: it's planned, or it isn't.
- Shipped: it's live, and here's how to use it.
- Declined: you won't build it, and here's why.
The first and third steps are the easy ones to remember, at least for big launches. The loop usually breaks in between, and when the answer is no.
What do you need to record to close the loop later?
You can't reply to someone you can't find. For every request, keep:
- Who asked: handle, email or account.
- Where they asked: a link to the Slack thread, Discord message, ticket or board post.
- Their exact words, so your reply can refer to their actual problem.
- Everyone who asked since. When you merge a duplicate, its author becomes a vote on the request you keep instead of disappearing. See how to handle duplicate feature requests.
What should each message say?
Short, specific and honest. These examples follow one fictional request for a habit-tracker app:
| Moment | Example message |
|---|---|
| Acknowledged | "Thanks, @mira. Logged as 'Export streak history as CSV.' Three others asked for this too. I'll update this thread when it moves." |
| Planned | "CSV export is now planned. No date yet. You can follow it on the roadmap." |
| Shipped | "CSV export is live: Settings, then Data, then Export CSV. Let me know if it covers what you needed." |
| Declined | "We're not building a smartwatch app this year. We're focusing on reminders and sync instead. Closing this so it doesn't look planned. Your vote stays if we revisit it." |
Notice what the acknowledgment doesn't say: "We'll build this." Only promise what's decided.
How do you close the loop at scale?
- Make it part of "done." A request isn't finished when the code merges. It's finished when the people who asked have been told.
- Use the changelog as the trigger. When you publish an entry, notify everyone who voted for the requests it ships. See how to write a changelog people actually read. The release notes writer can turn PR titles into a user-facing draft.
- Reply where they asked. A reply in the original Discord or Slack thread reaches the requester and anyone who finds the thread later.
- Send email to people outside your community. Not everyone who votes is in your chat.
- Notify on status changes, not only ships. Moving to Planned is good news worth a line. Keep your public roadmap in sync so the status users see is the real one.
- Personalize the important ones. For a customer who pushed hard for a feature, a direct note beats a template.
How do you say no without losing the user?
- Give the real reason. "It serves a small group and would take a quarter" is a reason. "Not a priority right now" isn't.
- Offer a workaround if one exists.
- Close it publicly. A request left open for a year is a no that nobody admits to.
- Leave the door open honestly. Say what would change your mind, if anything would.
What are the common mistakes?
- Announcing only in a newsletter. The people who asked may never read it.
- Saying "it's on the roadmap" for things that aren't planned. It sounds kind and creates a promise you'll break.
- Long silences. An acknowledgment followed by a year of nothing feels worse than no reply.
- Deleting duplicates. Each deleted duplicate is a person you can no longer notify.
- Templates that sound like templates. Use the person's name and their problem in their words.
Doing this with Sikia
When you publish a changelog entry in Sikia, it emails everyone who voted for the requests it ships and replies in the original Slack or Discord threads. When a teammate approves a suggested merge, the duplicate becomes a vote with the person's quote attached, so people who asked in different places all hear back. When someone asks "is this on the roadmap?" in Slack or Discord, Sikia answers in the thread from the current roadmap.
FAQ
How quickly should I acknowledge feedback?
Within a day or two is a good target for a small team. Speed matters less than consistency: every request gets a reply.
Should I tell users when I decline their request?
Yes. A clear no with a reason keeps more trust than silence, and it stops the request from looking planned.
Do I need to reply to every message?
Reply to every request and bug report, even with one line. General chatter and thanks don't need a logged reply.
What's the difference between closing the loop and publishing a changelog?
A changelog announces changes to everyone. Closing the loop tells the specific people who asked, in the place they asked. You need both.
Free tools for this
Do this without the spreadsheet
Related guides
- Roadmaps & changelogsHow to write a changelog people actually readWrite each entry for the person using the product, not the person who wrote the code: a plain title that names what users can now do, one to three sentences on what changed and where, and a screenshot when the UI changed. Publish on a steady rhythm, lead with the biggest change, and tell the people who asked for it.
- Collecting feedbackHow to handle duplicate feature requestsMerge duplicates into one request and keep each duplicate as a vote with the user's original words, so you get an accurate count without losing context or the people to notify. Merge only when the underlying problem is the same, and split requests that bundle several problems.
- Roadmaps & changelogsHow to run a public roadmap users trustUsers trust a public roadmap that is current, honest about uncertainty and tied to what they asked for. Show only what you're committed to, use a few clear statuses instead of exact dates, review it every couple of weeks, and tell voters whenever their item moves.