Why Do Feature Requests Sent in Slack DMs Never Reach the Product Team?
A feature request DMed straight to a CSM or AE dies for a boring reason: it lands in a conversation only two people can ever see, with no queue, no tag, and no second person whose job is to notice it. A public channel post at least gets read by whoever else is in the channel, and a support ticket at least sits in a queue someone has to clear. A DM has neither. It's a private thread between two people, and if the one who received it doesn't personally act on it, nothing else in the company ever will.
That's the whole mechanism, but the reasons deserve spelling out, because "Slack is bad at this" undersells it. The problem isn't Slack's retention or its search. It's that a DM was never built to be a shared record of anything, and every fix that works for a channel — inviting a bot, running a team-wide search, pointing a report at it — requires access that, by default, nobody but the two participants has.
Why a DM is structurally different from a channel
A public or private Slack channel has a property a DM doesn't: anyone can be added to it after the fact, and once a bot or a second teammate is in, they see everything going forward without further action. That's how tools like Modem watch a channel at all: an app is added once, and Slack's im:history scope documentation makes the DM equivalent explicit: it grants access only to "direct messages that your Slack app has been added to." No app is added to a DM by default, and almost nobody adds one preemptively to a conversation with a customer, because at the point the DM starts, nobody knows a feature request is coming.
Slack does technically let you add people to an existing 1:1 DM, turning it into a group conversation of up to nine members, per Slack's own help article on direct messages. That's a real option, and it's also one that requires the CSM to stop mid-conversation, remember a bot exists, and add it, in the middle of a chat where the customer is the one talking. It doesn't happen, for the same reason people don't stop a phone call to loop in a note-taker who wasn't invited to begin with.
The second gap is visibility, and it doesn't go away even if retention is generous. A manager, a PM, or an automated pipeline can search a channel, review it, or subscribe to it. Nobody can do any of that to a DM they aren't in. There's no admin view, no shared search, no "let me check what's been coming up in your DMs" the way there is for a channel. Pulling a DM's contents out after the fact isn't a search query either: Slack's guide to import and export tools is explicit that a standard export only covers public channels, and getting DMs out requires either a Workspace Owner applying for special access under "valid legal process, or consent of members, or a requirement under applicable laws," or, on Business+ and Enterprise plans, a Workspace or Org Owner running a dedicated self-serve export tool built for compliance. None of that is a thing a CSM can casually do to double-check a request they half-remember getting DMed three months ago.
What this looked like at Barrick Analytics
Colten Ashwright leads customer success at Barrick Analytics, which builds demand-forecasting software for mid-market retailers. Jonas Meland runs operations at Coldbrook Retail, one of Barrick's larger accounts, and the two of them have been in the same Slack DM thread since onboarding, because it's faster than a support ticket for the small stuff.
In April, Jonas sent this:
Jonas Meland: Random one — any way to set separate reorder points per warehouse instead of one number for the whole account? We're stocking three regions differently and the single threshold keeps under-ordering the slow one.
Colten replied the same afternoon: "That's a good one, let me flag it to product." He meant it. He didn't write it down anywhere, because the conversation was right there in front of him and it felt filed the moment he typed the reply.
In September, a different Barrick CSM mentioned in a totally separate DM with a different account that "someone asked about per-warehouse thresholds a while back, I think." Nobody could confirm it, because the only record was a five-month-old message in a thread between two people, neither of whom thought to search for it, and no one else could have searched for it anyway. When product finally scoped multi-warehouse reorder points as a Q1 project, they built it off the September mention and a guess, not off Jonas's actual account, his actual wording, or the fact that this was the second time it had come up, not the first.
The DIY fix, and its actual ceiling
The habit that closes this gap costs nothing and requires no tooling: the moment a DM contains anything that reads as a request, copy the exact line into wherever your team already tracks requests — a shared channel, a Linear or Jira ticket, a running doc — before closing the tab. Treat "flag it to product" as a lie you tell yourself until the copy-paste actually happens. The Modem guide to keeping a product-feedback channel alive covers what a good landing spot for that copy-paste looks like once it exists.
That habit is real and it works, right up until it depends on every person remembering to do it every time, for requests that don't always announce themselves as requests. "Any way to set separate reorder points" doesn't read like a ticket while you're mid-conversation; it reads like a customer thinking out loud. The DIY fix isn't wrong, it's just entirely dependent on one person's discipline holding up across every DM they have, indefinitely, with nobody checking whether it did.
Where the habit stops being enough, and what to do instead
Past a handful of CSMs and AEs each carrying their own book of DM threads, relying on each of them to remember every time is the same bet as relying on any one person's memory. It works until volume or turnover breaks it, and there's no way to audit whether it's already broken. Slack's own retention and search apply the same to DMs as to channels, per the free-plan history documentation, which doesn't carve out DMs from the rule. That's beside the point, because retention was never the failure mode here; visibility was, and retention doesn't fix visibility.
This is the honest limit of anything, including Modem, that watches Slack: it works by being added to channels, and a private 1:1 DM between a CSM and a customer isn't a channel it can be added to in advance, for the same reason a bot can't sit in a text-message thread it was never part of. What changes is the target of the habit, not the habit itself. The Modem Slack integration reads every public channel it's added to and, once a channel's members approve it, private channels too, including the shared account channels and Slack Connect channels many teams already run alongside their DMs with customers. Route the DM habit at that instead of at a doc: when a request shows up in a DM, drop it into the account's shared channel rather than a spreadsheet, and Modem turns it into a topic tied to Jonas and Coldbrook automatically, deduped against every other phrasing of the same ask from that account or any other, with a Linear or Jira ticket filed carrying the original quote. The copy-paste still has to happen once. What stops happening is the second failure, where the request sits unconnected to anything until someone remembers it by chance. We build Modem, so weigh the recommendation against the DIY habit above, which is genuinely sufficient for a team small enough that one person can audit every DM thread personally.
The one habit worth adopting this week
Pick the landing spot first — a shared account channel, a #customer-voice channel, whatever your team already half-uses — and tell every CSM and AE the same rule: nothing stays only in a DM past the day it arrived. That single habit is worth more than any tool, and it's also the thing that makes a tool like Modem actually work once the volume outgrows it, because a request that never left the DM in the first place is one no system, ours included, can ever see.
