Discord Onboarding for a Two Sided Community: One Question at the Door

What goes wrong in a flat server

Put two audiences in one room and each of them has to work out which half belongs to them.

Neither manages it. Someone who arrived to hire scrolls through channels of people advertising availability. Someone who arrived for work scrolls through requirement lists they do not match. Both read the server as active and not for them, and both stop opening it within a week.

Anyone who cannot identify their half of a server will treat all of it as someone else's.

The correction is simple to build and genuinely painful to retrofit, which is the whole case for doing it before the first invite goes out.

A single question

The first thing a new member meets asks which side they are here as, with two buttons and nothing else on the screen.

No name field. No niche. No budget, no experience level, no goals, no how did you hear about us. Every one of those is worth knowing and none belongs here.

Each extra field on that screen costs members, and it costs them before they have seen a single reason to stay. The only question you have earned at that moment is the one that determines what appears next.

Absent, not locked

The moment they answer, everything built for the other audience should cease to exist for them. Not dimmed. Not padlocked. Gone.

Teams resist this, usually reasoning that a full channel list demonstrates scale.

The effect runs the other way.

A second cost arrives later. In a server where everybody sees everything, there is no clean way to mark the moment you grant someone a new area, because nothing visibly changes. Where the other half is genuinely absent, opening a new channel is an event the member registers.

The questions that come second

Once the branch has happened, the follow up questions become worth asking. They can be specific to the chosen side, and the member has already put a click in.

Hiring side: what are you hiring for Working side: what do you do Three questions maximum, on a second screen

The same questions asked at arrival get skipped and answered badly. Asked here, after a commitment, they get answered properly, because the person is inside something rather than filling in a form at the door.

Reviewing the side that carries risk

One side almost always needs checking and the other does not. It is the side making offers or spending money, because that is where a poor participant imposes a cost on everyone else.

• Their answers route into a private channel only your team can see.
• Each submission lands as one post carrying an approve action and a reject action.
• Approval grants the role automatically, because manually assigned roles are where membership systems spring leaks.
• Rejection sends a short note and ends there.

Check the single public artefact that predicts quality in your market: a profile, a portfolio, a company site. Open it in a sandboxed browser rather than your own, since you are clicking links from strangers as a matter of routine.

Turn it around inside one working day. A review that takes a week filters out the applicants who had alternatives, which is precisely the group you wanted.

Where approved work lands

Output from the gated side goes to the room where the other side is waiting.

An approved job reaches the channel for people seeking jobs. An approved profile reaches the channel where people go looking. Unapproved material goes nowhere, and no channel exists where pending items sit on public display.

That is what makes the halves valuable to each other without merging them. Neither side sees the other's rooms. Both see the other's filtered output.

The argument for the gate

Gating here is not about standards in the abstract.

An open two sided community fills with low effort offers, because making one costs nothing. The receiving side works through them, finds the hit rate poor, and leaves. They rarely say anything. They just stop opening the server, and what shows up in your reporting is falling engagement among your strongest members, which reads as an engagement problem and gets answered with events that do not help.

There is also the side effect nobody plans for. A community that took effort to enter gets treated as worth being in. That is not manipulation, it is what happens when the review is genuine.

Configure it before launch

Adding a branch to a flat server later is costlier than it sounds.

It is not one new question. It is permissions revisited on every existing channel, a decision about what each current member should now see, roles applied to people who joined when roles meant nothing, and an explanation to everyone about why the place looks different this morning.

Done before promotion, it is an afternoon of configuration. Done after a few hundred members, it is a week of work and a week of confusion for all of them.

The layer this belongs to

Entry flow and role architecture form one layer of a community operating system, covered here fully enough to build unaided. Its neighbours are separate pieces of work: the first forty eight hours after entry, response time, support routing, moderation load, escalation paths, documentation, automation coverage, engagement rhythm, and leadership reporting.

Entry comes first because everything after it inherits its decisions. Support routing needs to know who someone is. Engagement rhythm needs to post into rooms holding the right half of your members. The question at the door settles both.

Two audiences sharing a server are two communities sharing an address. Running them as one room is what leaves both feeling half empty, and the repair is a single question asked before anyone sees anything at all. More at danieljeong.org.