Can Emoji Reactions in Slack Replace a Feature-Request Voting Tool?
Mostly no, past a small team. A 👍 on a Slack message can tell you that eight people agree with a specific request in that specific thread, and for a single message that's a real signal, cheap to read and cheap to give. What it can't do is add itself up. Slack has no view that ranks messages by reaction count, no report that rolls reactions up across a channel, and nothing that treats "👍 on this message" and "👍 on that other message about the same feature" as the same vote. Every reaction lives and dies on the one message it's attached to.
That's not a workaround waiting to be discovered. It's how the feature is built. Slack's own help article on reactions describes them purely as a per-message action: hover or tap-and-hold to see who reacted, click to add or remove your own. Neither that article nor Slack's search modifiers page mentions counting, ranking, or exporting reactions, because reactions were designed to replace a one-word reply, not to run a poll.
What Slack's reaction system is actually built for
Reactions are a conversational shortcut. Someone posts "shipping this Friday," five people react 🎉 instead of typing "nice," and the thread doesn't fill up with five copies of the same sentiment. That's the entire design intent, and it's a good one for what it is.
The one piece of infrastructure that gets closest to counting is Slack's search operator has:, which takes a colon-wrapped emoji code on both sides, so has::thumbsup: pulls up every message anyone has reacted to with 👍 (Slack's own example searches has::eyes:). It's a real, documented modifier, and it's the whole toolkit: it returns a list of messages, not a count, and it can't tell you that three of those messages are actually the same feature request phrased three different ways. You still read every result and add it up by hand.
The manual system teams actually build
Given that ceiling, most teams that try to vote by reaction converge on the same workaround: post each candidate feature as its own message in a dedicated channel, something like #feature-votes, and ask people to react with 👍 for "want this" and maybe 👎 for "don't." Because each message is its own poll, this actually works, as far as it goes. Hovering over the reaction shows exactly who voted, which beats an anonymous form.
The system holds together as long as three things stay true: someone is disciplined about posting one request per message instead of letting five asks pile into a single post, someone manually tallies which messages have the most reactions since Slack won't rank them, and nobody's asking the same question two different ways in two different messages. All three erode as the channel gets used.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhy one request reads as three moderately popular ones
Set up a #feature-votes channel where anyone can post a request and reactions decide what gets picked up next sprint, and it works cleanly while the volume is low. The failure arrives when the same underlying request gets posted more than once, worded differently by whoever was closest to the customer conversation that surfaced it.
The first posting describes the workaround a customer is stuck with. The second, weeks later, frames the same gap as a lost deal. The third uses a different phrase for the same capability. Each posting collects its own handful of 👍, and each one is a separate poll as far as Slack is concerned.
Slack leaves them unconnected. The channel now holds three separate, moderately popular requests instead of one request that a larger group asked for, and the ranking puts each of the three below a single-message ask that happened to collect more reactions in one place. The only thing that catches it is a person noticing that the third post used a phrase close enough to the first, which depends on that person having read all three and remembering the earlier ones.
Three reasons the count drifts
That pattern is the general failure mode, not a one-off. Reaction voting inside Slack stops scaling for three predictable reasons:
- Nothing dedupes phrasings. Slack has no concept of "these two messages are the same request." Every rewording resets the vote count to zero.
- Nothing aggregates across the channel. There's no ranked view, so someone has to scroll the whole channel and manually compare counts to know what's leading. That comparison gets slower every week the channel stays active.
- Reactions don't distinguish weight. A 👍 from one enterprise account and a 👍 from an evaluating trial user count identically, with no way to see who's behind the emoji without opening each message.
None of this is a bug in Slack. Reactions weren't built as a voting or reporting system, and holding them to that standard is asking a lightweight acknowledgment gesture to do a database's job.
What actually counts the votes
Modem exists to do the counting reactions cannot. Its Slack integration reads the channels you add it to and turns requests, bug reports, and complaints into topics, tied to the people and companies who raised them. It groups what it hears automatically, without anyone tagging or manually triaging first. One request phrased three ways becomes one topic with three linked conversations and a real count of how many people and companies actually asked, not three separate tallies someone has to notice are related. Each topic keeps the full source conversations attached, so checking that the count is right means opening the topic and reading the three original messages, the same check you would otherwise do by hand. That's the specific claim to hold a vendor to here: not "it ranks correctly" but "the count it produces is traceable back to real messages." We build Modem, so verify that traceability yourself before trusting the number. What doesn't change no matter who's counting is that Slack itself never will.
If you're earlier in this than a dedicated votes channel, how to keep a #product-feedback Slack channel from becoming a graveyard covers the capture side first. And if the answer for your team right now is "we need this out of Slack entirely," the best tools to mine customer feedback in Slack compares the options built specifically for that job.
The version that's honest about the limit
Reactions on a dedicated votes channel are a fine, cheap system for a small team with a trickle of requests and one person willing to periodically scan for duplicate phrasings by hand. Past that, the arithmetic has to move somewhere Slack isn't, whether that's a spreadsheet someone updates weekly or a system built to read the channel and do it automatically.