How to Collect Member Information When They Join Discord: The Four Field Join Record
The entrance is the only moment a member has a reason to answer questions. Here is the small record to capture there, and the four rules that keep it accurate a year later.
The room is full and nobody knows who is in it
A program lead can usually name the top ten members and almost nothing about the rest.
That is not carelessness. It is the natural result of a room where people arrive as a username with no attachment to anything the business already knows about them: the application they filled in, the handle they publish under, the campaign that brought them. The information exists. It is simply not connected to the account now sitting in the member list.
So the connecting gets done by hand. Somebody keeps a sheet, sends messages asking people to confirm who they are, and updates rows when a name changes. It works at a size where one person can hold it in their head, and it fails quietly at every size above that.
Ask at the door, for one reason
Wanting in is leverage, and it exists for a few seconds.
At the entrance, a form is the price of access and gets completed. A week later, the same questions are an unsolicited request from an organisation the member has not decided to trust yet. The completion rate difference is not marginal, and the gap is worst among the members you know least about, which is precisely the group the exercise exists to identify.
A question asked at the door gets an answer. The same question asked later gets an opinion about whether your program is worth the effort.
Four fields and nothing else
| Field | How it is captured | What it is for |
|---|---|---|
| Permanent account ID | Silently, from the submission | A key that survives name changes |
| External handle | Asked, one field only | A claim to verify before payment or partner status |
| Routing answer | Asked, closed list | Automatic role and lane assignment |
| Join source | Silently, from the invite link | Attribution that reporting can trust |
Two of the four are never asked, which is why the form stays short enough to finish.
The name field is a trap
Usernames are display values that change whenever somebody rebrands, and per server nicknames differ from the global name in the first place.
Keep the numeric account ID as the primary key of every row and treat the visible name as decoration. Programs that skip this discover it at payout time, when a handful of participants match nothing in the sheet, a manual investigation starts, and a partner waits longer than promised for money that was never in dispute.
A claimed handle is not a verified handle
Anybody can type anybody's handle into a form. Design for that instead of hoping.
The entrance captures the claim, which is enough to route somebody and start working with them. Verification is a separate, later step that requires an action only the real owner can take: posting a short code, adding a line to a bio, replying from the account, or connecting the account through the platform's own connection feature. Record the date of verification beside the handle, and treat an old verification as a claim again, because accounts change hands.
Separating claim from verification also stops the entrance form from becoming a gate that only technical members pass, which is what happens when verification is demanded before anyone has any reason to care about your program.
Closed lists, because free text cannot be routed
One routing question, four or five options, no open box.
Free text is comfortable to write and expensive to own. It cannot trigger a role, cannot be counted without cleaning, and creates a recurring manual sorting job that lands on whoever is least able to refuse it. A closed list turns the answer into an action: submission assigns the role, the role opens the lane, and the member is in the right room before their first message.
How to find your routing question:Ask what decides where a new member goes. If your program treats a Spanish language creator differently from an English one, language is the question. If it treats teams differently from individuals, that is the question. If nothing about your handling changes based on any answer, you do not have a routing question yet, and the honest move is to ask nothing extra and run one lane until you do.
Defer everything sensitive
Payment details, tax forms and contract signatures do not belong at the entrance.
They belong at the point of payment, where the member has an obvious reason to provide them and you have an obvious reason to hold them. Asking early depresses completion, and holding data you are not yet using is a liability with no matching benefit.
The first week of work
None of it is a large build. All of it is the difference between a program you can report on and a program you can only describe.
What you can do the day it works
Pull every member in one lane with verified handles, without asking anyone. Pay a cohort without reconciliation. Tell which partnership produced members still active a month later. Grant and revoke roles from data rather than memory. Answer the leadership question about who these people are with a table.
The layers around this one
Identity capture is one layer of an onboarding system, and it is the one every other layer reads from.
Beside it sit verification, role and channel architecture, a first 48 hours sequence that uses interest while it is still high, tiering that promotes members on evidence, support routing that knows which lane a question came from, and reporting that ties join source to retention. Built alone, the join record still pays for itself immediately. Built last, it forces every layer above it to run on estimates.
Decide your four fields this week. A field with no job does not earn a place on the form.
A community you cannot describe is a community you cannot defend at budget time. More at danieljeong.org.
Want a properly managed community?
Get Your Free Analysis →