How to get product feedback from a Discord community
Short answer. Don't move your community somewhere else. Collect feedback where members already talk: decide which Discord channels count as feedback, have one person read them on a schedule, move real issues into Linear, Jira, or GitHub with a link back to the thread, and reply in that thread when the work lands. Bots that need a /feedback command, like Featurebase's, help when members will use them. If messages scroll by faster than one person can read, Modem (our product) reads the Discord channels you subscribe it to, including their threads and forum posts, and groups reports about the same problem into topics alongside Slack, support, and GitHub. When someone asks, or an automation your team set up runs, its agent drafts a Linear, Jira, GitLab, or GitHub issue with customer quotes, and in Slack and, by default, in the dashboard an issue on a public repo waits for your approval first. It does not read DMs, voice, or emoji reactions.
The problem isn't getting feedback from Discord. Your users are already giving it: bug reports in #help, ideas in #general, a regression mentioned in a thread nobody on your team opened. The problem is that Discord is a conversation, not a record. The same question gets asked by four different people, a good request ends up 200 messages up, and eventually someone writes "I suggested this six months ago and nothing happened."
Most teams' first fix is a feedback board. That often goes badly for a Discord-first product, because the board is a new place members have to visit, and they don't. Discord is where they already are. The setup below keeps the community where it is and moves the work, not the people.
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clustered1. Decide which channels count as feedback
Pick the channels you will read, and say so in your server. Typical candidates:
- #help or #support, because many bug reports will arrive here whatever you name the other channels
- #bug-reports and #feature-ideas, if you want dedicated places to send people
- Any private or business server where customers and partners talk to you directly. For many teams this is where the most useful feedback is, and it's the one most likely to be left out of the process.
Forum channels or regular channels? A forum channel gives every bug or idea its own post, so the third person hitting the same bug replies on the existing post instead of adding scrollback. Some teams find that works well. In a large public server it can backfire: a channel full of structured posts reads as a form, members ignore it, and they keep reporting in #general. If your community is big and casual, keep regular channels and plan to read them where people actually talk. For a deeper comparison, see Discord forum channels vs a dedicated tool.
Don't 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 short template
In #bug-reports, pin a post like this:
- What happened
- What you expected
- Version and OS
- A screenshot, clip, or log if you have one
Four lines. If your template has ten required fields, people skip the channel and complain in #general. Ask for media: Discord members share screenshots and screen recordings freely, and a clip of a bug is often worth more than the text around it. Keep the link to that message when you move the report on, so nobody has to hunt for the attachment again.
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. Give one person the weekly pass
This is the step most teams skip, and it 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:
- Groups duplicates, so five reports of one bug become one item with five reporters
- Answers it, even if the answer is "known issue, tracked here"
- Moves real issues into the team's tracker
Make sure that person can see every server and channel you chose in step 1, including private ones. Rotating the job sounds fair and works badly, because triage quality depends on context that builds up in whoever does it repeatedly. Pick one owner and let them delegate.
4. Move real issues out of Discord, with a link back
Discord is where feedback arrives, not where it should live. A feature idea with 12 replies in a forum post is invisible to the person planning next quarter unless someone moves it. Whichever way you move it, the tracker issue should carry:
- The problem in one line, in the reporter's terms
- A link to the Discord message or thread
- Who reported it (Discord usernames are fine) and how many times it came up
- Links to any screenshots or clips
Three ways to do the moving:
| Approach | How it works | Where it fits |
|---|---|---|
| Manual copy | The triage owner copies each real issue into Linear, Jira, or GitHub | Quiet servers; the hours grow with volume |
| Submission bot | Members run a command that sends feedback to a board | Communities that will use a command and visit a board |
| Passive capture | A bot reads the chosen channels and groups what it finds | Busy servers where reports land in every channel |
Submission bots. Featurebase's Discord integration adds a /feedback command that sends feedback from Discord to a Featurebase board, lets admins send an existing message to Featurebase, posts new-post notifications into Discord, and supports Discord login. That fits if you want a public board and roadmap alongside the server. The tradeoff is the one this guide started with: it captures what members choose to submit, and the board is one more place to check. Canny's Discord integration sends board notifications into Discord text channels.
Passive capture. This is where we should disclose: we build Modem. You install its bot and turn on the channels you want read; nothing is read until you do. It reads text, forum, and announcement channels, including the threads and forum posts in them, backfills 30 days of each channel's history when you subscribe, and keeps up with new and edited messages in real time. Thread and forum history from before you subscribed isn't backfilled. In private channels, the bot's role needs permission to view them.
Modem doesn't use keyword or channel-name rules. It reads every human message in those channels, skips conversations that aren't about your product (logistics chatter, bot notifications), lets passing remarks go, and groups real concerns into topics by meaning. A Discord forum post, a Slack thread, and a GitHub issue about the same bug land on one topic. Each topic is typed as a bug report, feature request, complaint, praise, or discussion and gets an AI-assigned priority that weighs who is affected, how many customers and companies, whether it keeps recurring, and whether it's already being handled.
Nothing goes into your tracker on its own. You ask Modem's agent (from the dashboard, Slack, or by mentioning @Modem in Discord) to file a Linear, Jira, GitLab, or GitHub issue, or your team sets up an automation, such as creating a Linear ticket when a topic is scored high priority. Automations and Discord chats run without an approval step, so they act on what you configure; in Slack and, by default, in the dashboard, anything public or customer-facing, like an issue on a public repo, waits for your approval first. For Linear, the agent writes the problem, the context, a few customer quotes, and a link back to the topic; for the other trackers, the body is what the agent drafts from the topic.
We built it for products that run their community on Discord, where customers can surface a broken release at any moment. Our bet is that messy conversations should become structured topics without anyone tagging them, so members don't have to change how they talk. Filing and posting wait for a person, because an issue in a public repo or a reply in your server is a statement in your team's name, and a human should see it first.
Its limits: it doesn't read DMs, voice, or emoji reactions, so reaction votes don't count. Discord doesn't share email addresses, so a Discord member isn't matched automatically to the same person in Slack or support; you can merge them by hand. If one person can read your whole server each week, you don't need it. We compare it with the other options in our Discord feedback tools guide.
5. Reply in the thread it came from
When you ship something a member asked for, reply in their thread, not only in #announcements: "This is in 2.4, here's the doc." Members who see requests turn into replies keep reporting. Members who see requests vanish stop, and the "nothing happened" messages start.
Discord makes this unusually cheap because the original thread still exists. Keep the link from the tracker issue back to the thread (step 4) and the reply takes thirty seconds. Modem's agent can draft and post that reply in a connected server when you ask. Discord chats have no approval card, so read the draft before you tell it to post. More on the mechanics in how to close the feedback loop with customers.
What not to do
- Don't start with a voting bot or a board. Votes measure enthusiasm among members who found the board, not need across your customers. They're fine later, as one signal among several.
- Don't make people file issues on GitHub instead. Every hop loses feedback. Meet them where they typed.
- Don't run a survey before you've read what's already there. A survey asks the questions you thought of; the scrollback answers the ones you didn't.
Start with a few channels and a weekly slot
Pick your feedback channels, pin a four-line template, and put a 30-minute weekly triage slot on one person's calendar, with access to every server you chose. That is the whole system. Automation, deduplication, and loop-closing at scale are what you add when the weekly pass stops being enough.