How to get product feedback from a Discord community
If your users hang out in a Discord server, they are already giving you feedback. Bug reports in #help, feature ideas in #general, complaints about a regression in a thread nobody on your team read. The problem is not getting feedback from Discord. The problem is that Discord is a conversation, not a record, and conversations scroll away.
So the work is structural: give feedback somewhere to land, make sure one person is responsible for reading it, and get it out of Discord into whatever system your team actually plans from. Here is a setup that does that without asking your community to change how it behaves.
#shared-customer-channel
Ranked topics1. Separate the places feedback lands
A single #feedback channel does not work well, because bug reports and feature ideas need different handling. Most communities that do this well end up with something like:
- #bug-reports — a forum channel, one post per bug
- #feature-ideas — a forum channel, one post per idea
- #help — regular channel, because half your bug reports will arrive here anyway
Forum channels matter more than they look. In a regular channel, the third message about the same bug is just more scrollback. In a forum channel it becomes a reply on an existing post, which means the thread accumulates evidence instead of scattering it. Community-run roadmap guides recommend the same basic split of ideas, bugs, and announcements with a pinned submission template (Influencers Time).
Do not expect discipline. People will still report bugs in #general. The structure is for the feedback you can route, not a rule you enforce.
2. Pin a template, but keep it short
In #bug-reports, pin a post with a template like:
- What happened
- What you expected
- Version / OS
- A screenshot or log if you have one
Four lines. If your template has ten required fields, people will skip the channel and complain in #general instead. The template is a nudge toward reproducibility, not a form.
For #feature-ideas, one pinned question is enough: "What are you trying to do that you currently can't?" You want the problem, not the proposed solution. "Add a --json flag" is less useful than "I'm trying to pipe your output into jq."
3. Assign one triage owner and a weekly pass
This is the step most teams skip, and it is the one that decides whether the rest works. One named person reads the feedback channels on a schedule — weekly is enough for most communities — and does three things per item:
- Tag it or thread it so duplicates land together
- Answer it, even if the answer is "known issue, tracked here"
- Move real issues into the team's tracker
Rotating this job across the team sounds fair and works badly, because triage quality depends on context that accrues to whoever does it repeatedly. Pick one owner, let them delegate.
4. Get feedback out of Discord
Discord is where feedback arrives, not where it should live. A feature idea with 12 replies in a forum post is invisible to the PM planning next quarter unless someone moves it.
The manual version: the triage owner copies real issues into Linear, Jira, or GitHub, with a link back to the Discord thread. This works and costs the owner an hour or two a week.
The automated version is where we should disclose: we build Modem, which subscribes to the channels you choose and classifies every message as it lands — bug, feature request, praise, churn risk — then clusters duplicates into topics and files tracked issues with the Discord context attached. Its context graph also links identities across platforms, so the community member who posts in Discord and later emails support shows up as one person, not two requesters. It removes the "read everything and copy it over" part of the triage owner's job, though not the judgment part. If your server is quiet enough that one person can read everything, you do not need it; a weekly manual pass is fine. If messages scroll past faster than anyone reads them, passive capture is the difference between having the data and not. We compared the options, including submission bots like Featurebase's /feedback command, in our Discord feedback tools guide.
5. Close the loop in the channel it came from
When you ship something a community member asked for, reply in their thread. Not just a changelog post — an actual reply: "This shipped in 2.4, here's the doc." A community that sees requests turn into shipped features and public replies produces more and better feedback, because members learn the channel works. A community that sees requests vanish learns to stop filing them.
This is the cheapest retention work you will ever do, and Discord makes it unusually easy because the original thread still exists. Keep the link from tracker issue back to Discord thread (step 4) and the reply takes thirty seconds. More on the mechanics at close the loop.
What not to do
- Don't add a voting bot as step one. Votes measure enthusiasm inside the server, not value across your customer base. They are fine later, as a signal among several.
- Don't make people file issues on GitHub instead. Every hop loses most of the feedback. Meet them where they typed.
- Don't run surveys before you've read what's already there. A survey asks questions you thought of; the scrollback answers questions you didn't.
The smallest version to start this week
Create two forum channels, pin a four-line template in each, and put a 30-minute weekly triage slot on one person's calendar. That is the whole system. Everything else — automation, dedupe, loop-closing at scale — is what you add when the weekly pass stops being enough.
