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

Discord onboarding for a two sided community rests on one question asked before anything else: which side are you here as. Route each answer into channels the other side cannot see, ask the detailed questions after the branch, and gate whichever side makes offers behind a private approve and reject review. Build it before you promote the server anywhere.

The failure this solves

A server built for two audiences at once puts both of them in the same room and asks each to work out which half is theirs. Neither does. The person who came to hire scrolls past channels full of people looking for work. The person looking for work scrolls past channels full of requirements they cannot meet. Both conclude the place is busy but not for them, and both stop opening it.

A member who cannot tell which half of a server is theirs will treat the whole thing as somebody else's.

The design that fixes this is not complicated and it is very hard to retrofit, which is the argument for doing it before launch rather than after.

Ask one question, and only one

The first screen a new member sees asks which side they are here as. Two buttons. Nothing else. Not their name. Not their niche. Not their budget, their experience level, their goals, or how they found you. All of that is useful and none of it belongs on the first screen. Every additional field on a first screen costs you people, and it costs you them before they have seen anything worth staying for. The question you are entitled to ask at that moment is the one that determines what they see next, and that is exactly one question.

Hide the other side completely

Once they have answered, the channels built for the other audience should be gone. Not visible and locked. Not greyed out with a padlock. Absent. This is the part teams get wrong most often, usually for a reasonable-sounding reason: showing the full server communicates scale. It does the opposite.

⚠ A member who sees rooms they cannot enter does not think the community is large. They count the locks, decide most of the place is closed to them, and read the part they can reach as the leftovers.

There is a second cost that shows up later. A server where everyone can see everything has no clean surface for the moment you do want to show someone a new area, because there is no visible change to mark it. When the other side is genuinely absent, granting access to a new channel is an event the member notices.

Ask the detailed questions after the branch

Now the follow-up questions become worth asking, because they can be specific to the side the member picked and because the member has already committed to being there.

• Someone who picked the hiring side gets questions about what they are hiring for.
• Someone who picked the working side gets questions about what they do. Asked on a second screen, after a decision has already been made, these get answered at a far higher rate than the same questions asked on arrival. The member has invested one click and is now inside something rather than standing at a form. Keep this screen short as well. Three questions is generous.

Gate the side that carries risk

In nearly every two sided community, one side needs checking and the other does not. It is usually the side making offers or spending money, because that is the side where a low quality participant costs other members something real. The flow:

1. That side's answers route into a private review channel that only your team can see.
2. Each submission arrives as a single post with an approve action and a reject action attached.
3. Approval grants the role automatically. No manual role assignment, because manual role assignment is where membership systems leak.
4. Rejection sends a short message and nothing else happens. Check one thing: whatever public artefact predicts quality in your space. A profile, a portfolio, a company site. Open it in a sandboxed browser rather than your own, because you are opening links submitted by strangers all day. Decide within one working day. A gate that takes a week is a gate that loses you the applicants who had other options, which is the wrong half.

Route approved output to the other side

Whatever the gated side produces should land where the other side is waiting. An approved job post goes to the channel for people who want jobs. An approved profile goes to the channel where people go looking. Anything that has not been approved goes nowhere at all, and there is no channel where unapproved material sits visible "pending review". This is the mechanism that makes the two halves useful to each other without merging them. Neither side sees the other's rooms. Both sides see the output of the other's rooms, filtered.

Why gate at all

The case for gating is not quality for its own sake. An ungated two sided community fills with low effort offers, because posting one costs nothing. The people on the receiving side wade through them, find the ratio poor, and leave. They do not complain first. They simply stop opening the server, and the metric that tells you is engagement decline among your best members, which most teams read as an engagement problem and try to solve with events.

Ungated	Gated
Anyone can post an offer	Offers come from reviewed accounts
Volume high, quality unknown	Volume lower, quality predictable
Best members leave quietly	Best members stay because the ratio holds
Joining is free, so is ignoring it	Joining takes effort, which members respect

The last row matters more than it looks. Something that took effort to get into gets treated as worth having. That is not a trick, it is the honest consequence of the review being real.

Build the branch first

Retrofitting a branch into a flat server is expensive in a way that is easy to underestimate. You are not adding a question. You are revisiting permissions on every existing channel, deciding what each existing member should now see, assigning roles to people who joined before roles meant anything, and explaining to everyone why the server looks different today. Building it before you promote the community anywhere costs an afternoon of configuration. Building it after your first few hundred members costs a week and annoys all of them.

Where this sits in the bigger picture

Entry flow and role architecture are one layer of the operating system a community runs on, and this article covers that layer completely enough to build without help. The layers around it are separate builds: the first forty eight hours after entry, response time, support routing, moderation load, escalation paths, documentation, automation coverage, engagement rhythm, and the reporting that tells leadership what changed this month. The entry flow sits first because everything downstream inherits from it. Support routing depends on knowing who someone is. Engagement rhythm depends on posting into rooms where the right half of your members are. Both of those are decided by the question at the door. A two sided community is two communities that happen to share an address. Treating them as one room is what makes both of them feel half empty, and the repair is a single question asked before anyone sees anything. More at danieljeong.org.