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 NotionWhere it broke at Aldergrove Payroll
Aldergrove Payroll sells payroll and benefits software to small manufacturing shops, and eight months ago its product lead, Halima Boyer, set up a #feature-votes channel: any teammate could post a request, and reactions decided what got picked up next sprint.
It worked cleanly for the first few months. Then a request for multi-state tax filing support showed up three separate times in six weeks, each time worded differently by whoever was closest to the customer call that surfaced it:
Post 1 (support): "Customer in Ohio can't run payroll for their Michigan warehouse staff without manually splitting the file. Anyone else hearing this?" (6 👍)
Post 2 (sales): "Prospect walked because we don't handle employees working across state lines. Worth a vote?" (4 👍)
Post 3 (support, five weeks later): "Multi-state withholding keeps coming up, is this on the roadmap?" (9 👍)
Nineteen reactions total, and until Halima happened to notice the third post used the phrase "multi-state" too, the system had it filed as three separate, moderately-popular requests instead of one request nineteen people actually wanted. "We'd been ranking it below single-message asks with twelve votes," she said, "and it should have been near the top the whole time."
Three reasons the count drifts
The pattern at Aldergrove 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 for exactly the gap Aldergrove hit. Its Slack integration reads the channels you invite it to and, per Modem's own description, "turns requests, bug reports, and churn signals into topics, tied to the people and companies who raised them." It groups what it hears automatically, without anyone tagging or manually triaging first. Multi-state withholding 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 Halima ended up doing 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 honest 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.
