How to Handle Community Feature Requests Without Losing the People Who Send Them

The channel that went quiet

Open your suggestions channel and scroll back six months. Count how many ideas received an actual verdict.

For most companies the number is close to zero, and the recent silence in that channel is not apathy. It is a reasonable response to evidence. Members tried, nothing came back, and they stopped spending effort on a process with no output.

What makes this expensive is who leaves first. The members with the most specific, most useful observations are the ones who notice the silence quickest, because they invested the most in the message they sent.

What you are actually measuring

The number worth tracking is not how fast you ship. It is how many days pass between a member's idea and a decision that member can see.

Shipping speed depends on engineering capacity, competing priorities and a dozen things a community team does not control. Decision speed depends on one thing only: whether somebody owns issuing verdicts. That makes it a fair metric and a revealing one.

If nobody in your company can say who issues verdicts on member ideas, that is the whole problem, and it can be solved this afternoon by writing one name down.

One door, four questions

Accepting ideas everywhere guarantees losing most of them. So build one intake and route everything else into it.

Keep the form to four questions: what are you trying to do, what happens instead right now, how often this comes up, and what you currently do to work around it. Then stop. Do not ask members to prioritise your roadmap, propose an implementation or nominate an owner. They know their own experience precisely and your internal tradeoffs not at all, so ask for the first and keep the second.

When an idea lands somewhere else, whoever sees it moves it with one sentence: putting this in the intake so it gets a decision. That sentence teaches the route and promises a verdict at the same time.

Proof of receipt beats enthusiasm

A named person replies inside a published window. Three sentences: here is what I understood, it is logged, a decision will be visible by this date.

Notice what is missing. No promise that it will happen. No thanks, we will pass it along, which is the phrase that has quietly buried more good community ideas than any explicit rejection. Passing it along names no owner, no review date and no verdict, and members have learned to read it as a polite ending.

Three verdicts, one reason each

Every idea ends in one of three places, and each one carries a short reason.

• Yes. With a rough horizon, stated loosely and honestly rather than precisely and optimistically.
• Not now. With the condition that would change the answer. This should be most of your volume.
• No. With one clear sentence, no softening, no maybe.

Members can work with a no. They cannot work with a maybe that has no date attached.

Teams resist the middle option because it feels like a non answer. In practice it is the most respected thing a company can say, because it shows the constraint honestly and leaves the idea alive without pretending.

Return to the sender, then tell the room

Close the loop in two places.

First, reply directly to the person who raised it, using their words. That is what makes them raise something again. Second, post the verdict where the community can read it. That is what tells the quiet majority, the people who read everything and post nothing, that this room has output.

And when something ships from a member idea, name the idea and name the member. Public credit costs nothing and is the clearest possible evidence that participation here has consequences.

Keep the reasoning where people can read it

A decision log is one list: idea, verdict, reason, date, newest first.

It does four jobs at once. New members learn how your company weighs tradeoffs. Your team stops arguing about the same request every quarter. Leadership sees patterns instead of anecdotes. And the log itself becomes a reason for thoughtful people to take your community seriously.

A visible decision log is the cheapest credibility instrument a community team has, and almost nobody maintains one.

Reading the two numbers together

Median days to visible decision, alongside suggestion volume.

Falling latency with rising volume means the loop is trusted. Falling latency with falling volume means your verdicts are landing as dismissals, so reread your reasons. Rising latency means stage three lost its owner and you are collecting ideas nobody is deciding on, which is worse than not collecting them at all.

The layer this belongs to

Feedback handling sits alongside onboarding, support routing, escalation paths and reporting inside a community operation. It is the layer that determines whether your members remain contributors or quietly become an audience.

Everything else can be running well while this layer is missing, which is exactly why it goes unnoticed until the useful people have already stopped talking.

The order of work

1. Build one intake with four questions.
2. Publish an acknowledgement window you can keep.
3. Write down the name of the person who issues verdicts.
4. Give that person a weekly slot to issue them.
5. Start the decision log.
6. Go back and answer the ten oldest unanswered ideas.
7. Count median days to a visible decision from now on.

Step six is the one that feels uncomfortable and returns the most. A late answer still tells somebody they were heard, and the members you answer six months late are usually the ones you most want back. More at danieljeong.org.