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.
| How to collect member information when they join Discord: put a short form at the entrance and capture four fields, the permanent account ID, the external handle you will verify, the one answer you route on, and where the person came from. Ask at the door because access is the reason to answer, and turn the answers into roles immediately. |
|---|
The short answer
Collect it at the entrance, and collect four things. A short form placed before full access, asking for the account identifier your systems will store, the external handle you intend to verify, the single answer that decides where this person belongs, and the source they arrived from. Four fields, answered once, converted into roles automatically. Everything below is why those four, why the entrance, and what breaks when either choice is made differently.
Why the entrance is the only good moment
A member arrives with a reason to cooperate. They want in. That is the only point in the relationship where a form is not an imposition, because filling it in is how they get what they came for. A week later, the same three questions arrive as an interruption from a brand they have not yet decided to trust. Response rates collapse, and the people who do not answer are not a random sample. The ones who ignore it skew towards the members who joined casually, which is exactly the group you most need to identify and rank.
Every question you postpone past the entrance costs you the answer, and the people who never answer are the ones you know the least about.
What a join record is
A join record is one row per member, created at the moment of entry, holding only the fields you will use. It is not a profile. It is not a CRM. It is the minimum set of facts that lets you route somebody, verify somebody, pay somebody, and count somebody. Programs that treat it as a profile end up with a long form nobody finishes, and programs that skip it end up with a room full of usernames and a spreadsheet built by hand.
Field one: the permanent account identifier
Store the numeric account ID, not the username. This is the single most common technical mistake in creator and ambassador programs. Usernames change. Per server nicknames differ from the global name. Somebody rebrands after a partnership, and every list you keep silently stops matching the person it describes. The underlying account ID never changes. Capture it in the form submission, keep it as the primary key of your record, and treat the display name as a convenience field that may be stale at any time.
Why this shows up as a payout problem rather than a data problem
The failure surfaces at the end of the month. Somebody exports a list of participants by username, reconciles it against a payout sheet, and three names do not match anything. The people involved changed their handles, and nobody logged the change because nothing was watching for it. The result is a manual investigation, a delayed payment, and a partner who now trusts the program less. All of that traces back to a column choice made when the form was built.
Field two: the external handle you will verify
Ask for the one external handle that matters to your program, and design for the fact that the answer is a claim rather than a fact. A member typing a handle into a form is telling you who they say they are. That is enough to route them and enough to begin a conversation. It is not enough to pay them or to grant a partner role, because a claimed handle is trivially copied. So separate the two stages plainly. The claim happens at the entrance, in the form. Verification happens afterwards, once, through something only the real account holder can do: posting a code, adding a line to a bio, replying from the account, or connecting the account through the platform's own connection feature. Store the verification date next to the handle, because a handle verified a year ago and never rechecked is a claim again. Ask for one handle, not five. Programs that ask for every platform get abandoned forms and mostly empty columns. Ask for the one you actually run the program on, and collect the others later from members who are already active.
Field three: the one answer you route on
Every program has a single question whose answer determines everything downstream. Find it and ask only that. It might be the language a creator publishes in, the region they sell into, the size tier they fall into, the product line they cover, or whether they are applying as an individual or a team. One question, a small closed list of answers, no free text. Closed lists matter more than they look. Free text answers cannot be routed automatically, cannot be counted without cleaning, and quietly force somebody into a weekly manual sorting job. A closed list of four or five options can drive a role assignment the instant the form is submitted.
Field four: where they came from
Capture the join source, and capture it from the invite rather than from the member. A distinct invite link per campaign, per partner, per event and per platform means the source is recorded without asking anybody anything. Members are unreliable narrators of their own discovery, and the question wastes a slot on the form. This is the field that turns your community into something you can report on. Without it, every question about which partnership or which campaign produced engaged members is answered with an opinion.
The four rules that keep the record accurate
The fields are the easy half. These rules are what keep the record true a year later.
| Rule | What it prevents |
|---|---|
| Ask at the entrance, never later | Missing answers concentrated among your least known members |
| Ask only what you will use this month | Abandoned forms and columns nobody maintains |
| Convert answers into roles on submission | A record that no longer matches who has access to what |
| Defer sensitive fields to the moment of need | Holding payment and contract data you have no reason to hold yet |
The third rule is the one teams underrate. A record that is not wired to role assignment becomes a historical document within weeks, because the room changes and the sheet does not. When the form assigns the role, the room and the record cannot drift apart. The fourth rule is both a privacy position and an operational one. Payment details, tax information and contract signatures 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.
What the form actually looks like
Keep it to something a member finishes on a phone while standing up.
Join form, four fields, one screen:
- Your handle on the platform you publish on. Free text, one field only, verified later.
- The language you publish in. Closed list. Drives the role you get on submission.
- Are you joining as an individual or a team. Closed list of two. Drives which lane you enter.
- Agreement to the program terms. Checkbox with a link.
Captured silently, not asked:
- Permanent account ID
- Join source from the invite link
- Timestamp of submission Three visible questions and a checkbox. The two most valuable fields in the record are never asked, because the system already knows them.
What this makes possible immediately
Once every member arrives with a record, a set of jobs that used to be manual become ordinary. You can hand somebody the list of every member in one language lane, with verified handles, without asking anyone. You can pay a cohort without a reconciliation exercise. You can tell which partner or campaign brought people who are still active a month later. You can grant and revoke a partner role from data rather than from memory. And you can answer the question a leadership team always asks, which is who these people actually are, with a table instead of an estimate. None of that requires new tooling beyond a form, a role automation, and a place to keep the rows.
Where this sits in the larger system
The join record is one layer of the onboarding system, and it is the layer everything else reads from. Around it sit the layers that use it: verification that turns a claimed handle into a confirmed one, role and channel architecture that decides what each lane can see, a first 48 hours sequence that gives a new member something to do while their interest is highest, tiering that promotes members as they earn it, support routing that knows which lane a question came from, and reporting that connects join source to retention. A program can build the record on its own and get immediate value. Building the other layers without it means every one of them runs on guesswork. Write down the four fields your program would actually use this month. If a field has no job, it does not go on the form.
The moment somebody wants in is the only moment they will happily tell you who they are. Everything after that is a favour you are asking. More at danieljeong.org.