Can You Tell Which Discord User Is a Paying Customer or Just a Lurker?
Not from Discord alone, no. A username, an avatar, and whatever roles your server hands out is all Discord gives you by default, and none of that is a plan, a seat count, or a company name. If you want to know whether kestrel_ops reporting a crash in #bug-reports is a free-tier hobbyist or the account paying you $600 a month, you have to build the connection yourself, or use something that already has.
The short version is to pick one identifier both systems actually share, usually a verified email, and match on it once, deliberately, rather than guessing from context clues in the message.
This isn't a rare complaint. It's common enough that an Ask HN thread titled "Lost in the Discord Maze" opened with exactly this problem: SaaS communities on Discord end up isolated from the product, with "no way to connect user conversations to their actual product interactions."
“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 NotionWhat Discord actually shows you
Open any member's profile in a server you moderate and you get their username, their avatar, when they joined, their roles, and, if your server has boosting enabled, whether they've boosted it. That's the full native picture, and there's no field for "customer," no field for "plan," nothing that reaches into your billing system.
Discord does have a mechanism for connecting a member to an external identity, called Linked Roles, which lets a server require a role based on a user meeting criteria on a connected third-party account. It's explicitly opt-in. The user has to run through an OAuth2 flow and grant your app the role_connections.write scope before any of it works, and what gets exposed to you is whatever your own app chooses to check, not raw account data Discord hands over. Discord isn't withholding a paying-customer flag out of caution; the concept doesn't exist on their side to withhold. Your product's billing status lives in your systems, and Discord has no way to know it unless you tell it.
The identifier that actually connects the two
Given that, the practical move is a verification step. Ask the person to confirm something that also exists in your customer records, almost always a work email, and write the match down as a role or a note the moment it happens.
That's what Wren Pemberton set up for Talus Labs, which ships a log-tailing CLI and runs a Discord support server about 1,800 members deep. A bot posts in #welcome asking people to type /verify and confirm the email they signed up with. The bot checks that email against the Stripe customer list and, on a match, adds a verified-customer role plus the plan name, verified-growth or verified-team, so the tag is visible next to the username in every channel.
A realistic exchange, three weeks after Wren shipped it:
kestrel_ops (verified-growth): getting a panic on
talus tail --followagainst anything over 2GB, stack trace in threadWren: Thanks. Growth plan customers hit this exact path more since it's the tier with the higher default buffer size. Can you paste the panic output and roughly how big the file was?
Before verification, that message was one more line from a username Wren didn't recognize. After it, "Growth plan customer, hit a buffer-size-dependent panic" is visible before anyone has to ask, and it tells Wren where to look first.
Where the manual version breaks down
The role-and-bot setup genuinely works, and it's worth building even if you go no further. But it has real edges, and they show up in a predictable order as a community grows:
- The account that verifies isn't always the account paying. A contractor or a junior engineer files the bug; the plan is billed to someone else's email who's never set foot in the Discord server. The role sits on the wrong person, or on nobody.
- Plans change and roles don't hear about it. Someone downgrades from Team to Growth in the billing portal, and the Discord role update is a manual step nobody remembers to run, so the tag quietly goes stale.
- History before verification stays anonymous. A member who joined eight months ago and verified last week still has zero attribution on everything they said before that, which is most of what they've said if the server is active.
- The bug itself never gets linked to the account. Even with a role that says who's asking,
kestrel_ops's crash report is still just a Discord message. Someone still has to manually copy it into Linear or GitHub by hand, and reattach the requester's name if that copy ever needs it again. That's the same gap covered in how to stop the same bug from being reported in five different Discord channels.
None of this is a reason to skip the verification bot. It's a reason to expect it to plateau once your server gets past a hundred or so active daily conversations, because every one of those failure modes needs a human noticing and fixing it.
When it's worth automating the match
Past that point, the pattern that holds up is treating the match as infrastructure rather than a one-time bot setup, so every message gets checked against account records continuously, not just at the moment someone types /verify, and the result attaches to a person and company record that survives whether the plan changes, the message is six months old, or the requester never verified anything at all.
Modem is built for that job. It reads the Discord channels you connect, classifies messages in real time, and ties each one to the person and company behind it, so kestrel_ops's crash report arrives already carrying the account, the plan, and every other time that account has shown up across Slack, support, or a sales call, instead of a bare username you have to look up. When the fix ships, the same record is what makes it possible to reply to the actual requester instead of posting a changelog and hoping they see it. Modem is our product, so read the pitch with that in mind; for a comparison that isn't coming from us, see our roundup of Discord feedback tools for devtools teams.
Modem's pricing is unlimited users on every plan, pay-as-you-go beyond included usage, so there's no per-seat math to redo every time your Discord server grows.
Start with a spreadsheet, not a bot
If a bot and a bit of Stripe-matching logic is more than you want to build this week, the smallest useful version is a pinned message in #welcome asking new members to DM a mod their signup email once, and a spreadsheet mapping Discord handle to account. It's manual and it will drift, but a spreadsheet that's eventually stale still beats a policy of guessing from context. Verify the ten people who post most often first; that's usually where most of the actual paying-customer signal already lives.
