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

📌 How to handle community feature requests: run four stages in fixed order. One intake, an acknowledgement from a named person inside a stated window, a decision that is yes, not now, or no with a reason, and a reply that goes back to the person who asked. Keep a public decision log and track median days to a visible decision. Saying no costs you almost nothing. Saying nothing costs you the next idea.

---

Run the loop in order, or the loop does not exist

Capture, acknowledge, decide, reply. Four stages, always in that sequence, no stage skipped. Everything below is what each stage requires and what breaks when it is missing. The order matters more than the tooling. Teams with a spreadsheet and a habit outperform teams with a dedicated feedback platform and no habit, because the value being delivered is not organisation. It is the experience of being answered.

Stage one: capture in exactly one place

Ideas arrive everywhere. In a general channel, in a support thread, in a private message to whoever seems senior, in a reply to an announcement. If you accept them everywhere, you are accepting that most of them will be lost, because nothing scattered gets reviewed. One intake. A single channel or form, short enough that a member finishes it, structured enough that ideas arrive comparable. INTAKE FORM

	Question	Condition
1.	What are you trying to do?	one sentence
2.	What happens now instead?	one sentence
3.	How often does this come up?	daily / weekly / occasionally
4.	What do you do to work around it?	optional

DO NOT ASK
- how we should build it
- how important it is on a scale
- which team should own it

The three things you do not ask for are deliberate. Members are excellent at describing their own situation and unreliable at prioritising your roadmap, so ask for what they know and take the judgement back to your side. Everything that arrives anywhere else gets moved by whoever sees it first, with one line: adding this to the intake so it gets a decision. That single sentence does two jobs, it teaches the route and it promises a verdict.

Stage two: acknowledge, by a name, inside a window

An acknowledgement is not agreement. It is proof of receipt. One named person replies inside a window you have published. Not the team, not a reaction emoji, not a bot. Three sentences is plenty: what you understood the idea to be, that it has been logged, and when a decision will be visible.

The window is a commitment, so pick one you will keep during the hours you actually staff. A window you meet every time is worth more than a shorter one you miss twice a month.

The acknowledgement also protects the idea from the most common failure mode in feedback handling, which is a moderator saying they will pass it along. That sentence sounds helpful and creates nothing. Passed along to whom, reviewed when, decided by what date. If the answer to those is unclear, the idea has entered a drawer.

Stage three: decide, with a reason, in one of three ways

Three verdicts. Every idea gets one, and every verdict carries a reason short enough to read.

Verdict	What it commits you to	What the member hears
Yes	A rough horizon, stated loosely and honestly	This is happening and roughly when
Not now	Naming the condition that would change the answer	My idea was understood and it is still alive
No	One sentence of reasoning, no hedging	The company has a direction and it told me straight

The middle row is where most of your volume should land, and it is the one teams avoid because it feels weak. It is not weak. Not now with a condition attached is the most trusted thing a company can say to a community, because it treats the member as somebody capable of understanding constraints.

A no with a reason keeps the relationship. A maybe with no date ends it slowly.

Stage four: close the loop, twice

Go back to the person who asked. Use their name, reference their words, tell them the verdict and the reason. Then tell the room, briefly, in whichever channel carries decisions. Both parts matter and they do different work. The reply to the individual is what makes them suggest something again. The note to the room is what makes everybody else believe that suggesting is worthwhile, including the many members who never post but read everything. When something ships, close it a third time. Say which idea it came from and who raised it. Credit is free and it is the strongest signal available that this room changes the product.

The decision log

Keep the reasoning where anyone can read it. A simple list, newest first: the idea in one line, the verdict, the reason, the date. This is quietly one of the highest value documents a community team can maintain. New members read it and learn how the company thinks about tradeoffs, which is the sort of credibility no announcement can manufacture. Your own team reads it and stops relitigating the same request every quarter. Leadership reads it and sees pattern rather than anecdote.

The number to track

Median days from idea submitted to visible decision. Not time to ship, which depends on engineering capacity you do not control. Time to a decision the member can see, which depends only on whether you run the loop.

What you observe	What it means
Median falling, suggestion volume rising	The loop is trusted and working
Median falling, volume falling	You are deciding fast but the decisions read as dismissive, check your reasons
Median rising	Stage three has no owner, someone is collecting ideas nobody decides on

Suggestion volume is the honest companion metric. Members vote on whether the loop works by using it or abandoning it.

Where this layer sits

Feedback handling is one layer of a community operation. Onboarding decides whether a member ever gets far enough to have an opinion. Support routing keeps questions out of the suggestion intake. Escalation paths decide what leaves the community layer. Reporting is how the decision log becomes something leadership acts on. Without the feedback layer, all of the others still function and the community slowly becomes an audience rather than a contributor. That shift is hard to notice month to month and very hard to reverse once it has happened.

Start this week

• Pick one intake and write the four question form
• Publish the acknowledgement window for the hours you actually staff
• Name the person who issues verdicts, and put a weekly slot on their calendar
• Create the decision log with the last ten ideas you can still reconstruct
• Go back and close the loop on those ten, even the old ones
• Start counting median days to a visible decision

---

The step people skip is the last one, going back to old ideas nobody ever answered. It feels awkward and it works better than anything else, because a late answer still tells a member they were heard. Start with the backlog of silence. More at danieljeong.org.