--- title: "How to Close the Feedback Loop With Customers" summary: "[Closing the feedback loop](/glossary/closing-the-feedback-loop) means telling customers what happened to their request. Three steps, what to say when the answer is no, and a one-week plan." date: 2026-11-05 author: "Swaathi Kakarla" canonical: https://featureos.com/blog/how-to-close-the-feedback-loop markdown: https://featureos.com/blog/how-to-close-the-feedback-loop.md lastUpdated: 2026-11-05 categories: ["customer-feedback"] readingTime: 3 --- Closing the feedback loop means collecting a customer's feedback, deciding what to do with it, and telling that customer what happened. Most teams do the first two and skip the third. The third step is the one that makes it a loop. Skip it and customers learn that feedback goes nowhere. They stop sending it, and you lose the signal you were collecting in the first place. Here is how it usually goes. A customer asks for CSV export. Support logs it. Four months later engineering ships it in a big release, and nobody connects the release to the customer who asked. That customer never finds out. The next time they have an idea, they keep it to themselves. Nothing went wrong in that story. Every person did their job. The loop broke because no step in the process said "tell the customer." ## Why teams skip the last step It is usually a process problem, not laziness. A request comes in through Intercom, gets triaged, lands in a backlog, and ships six months later inside a bigger release. By then nobody goes back to find who asked. So the fix is not "remember to follow up." Remembering fails. The fix is to make telling customers a step in shipping, the same as writing the release note. ## Step 1: Collect it in one place You cannot tell people what happened to their request if you cannot find it. Feedback arrives through email, support chats, sales calls and Slack. Pick one home. - Log feedback against the customer who gave it. Do not paste it into a doc. - Let customers submit and vote on a public board, so the request has their name on it. - Merge duplicates (see [feedback aggregation](/blog/feedback-aggregation-analysis)). Ten people asking for the same thing should become one request with ten voters. The last point is what makes the loop cheap. When duplicates are merged, one status change reaches all ten people. ![Three steps. Collect: ten requests. Merge: one request with ten voters. Tell: one status change notifies all ten voters.](/blog-images/how-to-close-the-feedback-loop/loop-diagram.png) ## Step 2: Decide, and say it out loud Every request ends in one of three answers. Give one, every time. - **Yes, planned:** "This is on the roadmap. We'll tell you when it moves." - **Not now:** "We're not building this soon, because [reason]. We'll revisit it in [month]." - **No:** "We won't build this, because [reason]. Here is what to use instead: [workaround]." Always give the reason, and keep it to one or two sentences. A clear no earns more trust (more in [the art of saying no to feature requests](/blog/the-art-of-saying-no-to-feature-requests)) than a request that sits in "Under review" for a year. ## Step 3: Tell them when it ships 1. Link each request to the work item that will ship it. 2. When the work ships, change the status of the request. 3. Voters and subscribers get notified. In FeatureOS this is a choice you make when you change the status, so tick "Notify customers". If your engineers work in GitHub, sync statuses so nobody updates two tools by hand. In FeatureOS, when a linked GitHub issue changes status, the feedback post updates and, with notifications on, its voters and subscribers are told. For requests that need several PRs, you can wait until all linked issues change status. See the [GitHub integration](/integrations/github). ## How this works in FeatureOS FeatureOS keeps all three steps in one place. Customers submit and vote on your [feedback boards](/collect-feedback), so every request has a name on it. Your team sets a status on each request. When a linked GitHub issue changes status, the request updates and your voters and subscribers can be notified. The [release notes](/release-notes) (see [how to write release notes](/blog/how-to-write-release-notes)) live next to the board, so customers can see what shipped without leaving. ## A one-week starter plan - **Day 1:** Pick the one place all feedback goes. Tell support and sales. - **Day 2:** Merge the duplicates on your top 20 requests. - **Day 3:** Give each of those 20 an honest status: planned, not now, or no. - **Day 4:** Send the "no" and "not now" messages, with reasons. - **Day 5:** Add one line to your release checklist: "notify the voters." Related: [from feedback to roadmap](/blog/feedback-to-roadmap), [building a customer feedback system](/blog/customer-feedback-system) and [public roadmaps](/roadmaps).