Onboarding Setup
Paid community Slack onboarding — workspace configuration reference card
Slack creates four structural onboarding friction points that forum-based community tools do not have. Three are fixable at workspace configuration time, before the Day 0 DM fires. One is a hard architectural limit of Slack that no admin setting resolves. This reference card covers the four friction points with their Slack architectural causes and fix paths, the three workspace changes with exact admin-panel steps and verification procedures, a minimum channel-architecture table for communities under 500 members, and a notification-settings reference card that identifies what operators can and cannot control on behalf of new members.
TL;DR
Four friction points: sidebar overwhelm (all channels auto-joined on invite — fix by restricting default channels to two), notification defaults that train muting (unrestricted @channel/@here + all-channel join burst — fix by restricting @channel permissions to admins), missing orientation path (no default content feed — fix with a #start-here channel, operator-only posting, pinned message under 200 words, one instruction), and no content discovery algorithm (Slack architectural limit — not fixable; mitigate with #introductions quality and an operator-curated #best-of). All three fixes are settings changes available on Slack Free and Pro, requiring 30–60 minutes total one-time setup. None require additional tooling. The narrative companion post explains the why behind each friction point; this page is the practitioner reference for what to change and where.
Friction-point reference table
Each friction point has a different Slack architectural cause and a different fix path. Treating all four as “onboarding problems” without distinguishing their causes leads operators to invest in solutions that address the wrong layer — typically by writing a longer welcome DM to compensate for workspace configuration issues that exist before the DM lands.
| Friction point | Slack architectural cause | Operator-fixable? | Admin path | Fix effort | Impact on activation rate |
|---|---|---|---|---|---|
| Sidebar overwhelm on first login | Default invite behaviour auto-joins new members to all public channels in the workspace | Yes | Workspace Settings → Invitations → Default channels | Low — 10-min one-time change | High — removes navigation-without-context as the default first experience; members open two channels with relevant content instead of 30 channels with no context |
| Notification defaults that train muting | All-messages notifications on by default for all joined channels; @channel/@here unrestricted for all members, producing broadcast-ping interruptions with no context for new joiners | Partial — @channel restriction is operator-controlled; per-member notification preferences are not | Workspace Settings → Permissions → Messaging → Who can use @channel and @here | Low — 5-min one-time change | Medium-high — eliminates broadcast interruptions; does not change individual members’ notification settings (Slack-side individual control) |
| Missing home channel and orientation path | Slack has no default orientation feed; pinned messages in high-volume channels (#general) are buried below months of conversation history on first open | Yes (workaround required) | Channel creation → Channel Settings → Posting permissions → Pin message | Medium — 30–60-min one-time setup, plus ongoing discipline to keep orientation post under 200 words | Medium — creates the orientation path Slack does not provide natively; effectiveness depends on operator maintaining the under-200-word constraint |
| No content discovery algorithm | Slack does not surface content algorithmically across channels to new members; all content is locked in the channel where it was posted and visible only to members who join that channel and scroll back | No — architectural limit; not a configuration problem | N/A | N/A | Mitigated only — #introductions as discovery proxy; optional operator-curated #best-of for thread archive access; no admin setting resolves this |
The sequencing problem. The Day 0 welcome DM arrives after the new member’s first experience of the workspace. If that experience was sidebar overwhelm, notification burst, or an orientation channel with a 2,000-word post, the DM is compensating for a configuration problem — not adding value on top of a friction-free first login. The three fixable friction points are upstream of the DM. Fix them before the DM fires, not instead of the DM.
The three workspace changes: step-by-step
All three changes are available on Slack Free and Slack Pro. None require Business+ or Enterprise Grid. Total setup time: 30–60 minutes for all three, one-time. The changes are cumulative — each removes a different friction point — and the order in which you implement them does not matter. For the narrative explanation of why each change moves activation rates, see the paid community Slack onboarding guide.
Default channels at invite: two only
Slack’s default behaviour adds new members to all public channels when they accept an invite. A workspace with 20–40 channels means a new member’s first experience is a sidebar of 20–40 channel names, every one showing as unread. This change restricts that to two channels whose content a new member has immediate context for: #start-here (an orientation message they were invited to read) and #introductions (recent member posts they can read before writing their own). All other channels are joined voluntarily after the onboarding sequence directs the member to channels relevant to their stated goals.
- Open Workspace Settings: click the workspace name (top-left) → Settings & Administration → Workspace Settings.
- Find the Invitations section. Click Expand or Edit next to “Default channels.”
- Remove all channels currently in the default set (click the × next to each channel name).
- Add #start-here and #introductions to the default set.
- Save changes.
Verification
Accept a test invite in an incognito or private browser window using a secondary email account not currently in the workspace. After completing the Slack account setup, confirm that only two channels appear in the left sidebar. If additional channels appear, check whether any individual channels have per-channel auto-join enabled (Channel Settings → More). Per-channel auto-join overrides the workspace default and must be disabled separately for each channel.
@channel and @here: operators only
Slack’s default grants all members the ability to use @channel and @here in any channel they have joined. In a paid community, this means any member can broadcast-ping the full membership of any channel — including new members who joined 90 seconds ago and have no context for the message. Most workspace muting by new members is triggered by receiving @channel pings from channels they did not consciously choose to join (and were auto-joined to by the now-fixed default). This change removes broadcast-ping ability from all members and reserves it for workspace owners and admins. Operators retain full @channel and @here access for legitimate announcements.
- Open Workspace Settings: click the workspace name → Settings & Administration → Workspace Settings.
- Navigate to the Permissions tab.
- Find Messaging → “Who can use @channel, @here, and @everyone.”
- Select Workspace Owners and Admins. Deselect “All Members.”
- Save changes.
Verification
Log in with a non-admin member account and attempt to type @channel in a channel message. Slack should show a warning that you do not have permission to use @channel in this workspace. If the @channel completion still appears and posts successfully, the permission setting did not save correctly — retry the save and confirm with the test account again.
#start-here: operator-only posting, pinned orientation message under 200 words
The #start-here channel substitutes for the default orientation feed that Slack does not provide. Its job is to give the new member one piece of content to read and one action to take — not to answer all possible questions. The 200-word limit is a forcing function that prevents the operator from front-loading orientation content the member does not need until after their first contribution. Operator-only posting permission prevents member messages from appearing above or between the orientation post and the pinned post, which would break the channel’s function as an orientation path. Create #start-here if it does not already exist; archive any existing orientation channels (e.g. #welcome, #getting-started) by redirecting their purpose to #start-here.
- Create #start-here if it does not exist. If a #welcome or similar channel exists, plan to archive it after this setup is complete.
- Open #start-here → click the channel name at the top → Settings → Posting permissions. Set to Workspace Owners & Admins only. Save.
- Write the orientation post (as the operator account) using this structure: (a) one sentence describing what the community is for and who it is for; (b) one instruction — “Go to #introductions and post a one-paragraph introduction using the template pinned to that channel”; (c) two or three channel links for the member’s first two weeks; (d) one reference link to the full channel guide or Canvas. Total: under 200 words.
- Post the message. Hover over it → click the three-dot menu (…) → Pin to channel.
- Delete or archive any prior messages in #start-here that appear above the pinned post.
- Archive or redirect any duplicate orientation channels (#welcome, #getting-started, #new-members).
Verification
Log in with the test non-admin account used in Change 1. Open #start-here. Confirm: (1) the pinned orientation message is the first visible item in the channel; (2) the message composer shows a “you cannot post in this channel” notice; (3) the orientation post is under 200 words and contains exactly one instruction. If the pinned post is not the first visible item, delete or archive any older messages that appear above it.
Channel-architecture reference table
The channel-architecture decision directly determines sidebar complexity for new members. Every channel in the workspace appears in the sidebar for members who have joined it. Communities that grew organically tend to accumulate channels faster than they remove them — a two-year-old workspace often has 40+ channels for a 300-member community, many of which are low-activity. This table defines the minimum viable channel set for a paid Slack community under 500 members and the criteria for when to add or remove channels beyond the minimum. For the full three-touch onboarding sequence that directs new members to topic channels based on their stated goals, see the companion reference card.
| Channel | Purpose | Posting permissions | New-member auto-join? | Pinned content | Create when | Risk if skipped |
|---|---|---|---|---|---|---|
| #start-here | Primary orientation path; first channel new members open | Operators only | Yes — always | One orientation post ≤200 words; one instruction; one reference link | Day 0 of community launch | No default orientation path; new members open #general (high-volume, no context) first and form a low prior about community activity |
| #introductions | Social proof + first-contribution entry point + new-member discovery proxy (substitutes for missing content discovery algorithm) | All members | Yes — always | Template introduction post pinned at top (showing the format for a new member’s introduction: name, role, what you’re working on, what you’re looking for) | Day 0 of community launch | No low-social-risk first-contribution entry point; no social proof of an active, peer-populated community for new members who have not yet read any content |
| #announcements | Community-wide news, upcoming events, operator updates | Operators only | Optional — add after the Day 0 DM if included in onboarding sequence | None required | Day 0 of community launch | Announcements posted in #general add noise to a channel new members open for orientation; #general mixes announcements with conversation and buries both |
| #general | Async catch-all conversation; water-cooler; low-urgency community-wide discussion | All members | No — members join after onboarding sequence directs them | Brief community norms post (ideally ≤100 words) | After month 2 when the community has enough content to make #general feel active rather than empty | N/A — making #general auto-join adds sidebar noise before members have orientation context; new members open it first, see little activity, and form incorrect prior about community health |
| #[topic-1], #[topic-2] | Core use-case discussions specific to the community’s niche; content members joined to access | All members | No — directed join via Day 0 DM based on member’s stated goals (from onboarding checklist question 2: “pick your goals”) | Seed question or thread starter from operator (gives new joiners an entry point for their first post) | When 15+ members share the specific need; earlier channels are low-activity and reduce perceived community health | Members subscribe to channels with content that is not relevant to their goals; channel subscription feels like a commitment, not a resource; low topic-channel engagement is misread as community disengagement |
| #best-of or #resources | Operator-curated archive of highest-value threads; mitigates absence of content discovery algorithm for new members | Operators only | No — linked from #start-here orientation post as the “explore the archive” reference link | None required; the entire channel is curated content | After month 6 when the thread archive is deep enough to curate (minimum: 10 threads worth preserving) | New members cannot access the historical depth of conversation in channels they have not yet joined; community appears shallow relative to its actual content depth |
The 30-channel audit. If your workspace has more than 30 channels for under 500 members, run a simple audit: for each channel beyond the minimum set above, ask whether you can name three recent conversations in that channel that a new member would find useful. If not, the channel is generating sidebar surface area without providing orientation value for new members. Archive low-activity channels; consolidate related channels; bring the active channel count below 15 before implementing the default auto-join changes above. A 30-channel workspace with two auto-join channels will still confront new members with 30 channels in the sidebar once they join topic channels voluntarily — the sidebar complexity problem is cumulative, not fully solved by the auto-join change alone.
Notification-settings reference card
Operator control over notification settings is more limited than most operators expect. The table below distinguishes which settings are operator-controlled (changeable in Workspace Settings) from which settings are individual-member-controlled (Slack-side preferences that operators cannot set on behalf of members). Knowing this boundary prevents operators from attempting workarounds for settings that do not exist in the admin panel. The two actionable operator controls — default channels and @channel restrictions — are covered in the configuration changes above; this table provides the complete picture. For the full Slack member onboarding checklist that combines workspace configuration with the three-touch DM sequence, see the companion reference card.
| Setting | Default state (Slack default) | Target state | Who controls it | Admin path (if operator-controlled) | What the change prevents |
|---|---|---|---|---|---|
| Default channels for new members | All public channels in workspace | #start-here + #introductions only | Operator (workspace admin) | Workspace Settings → Invitations → Default channels | Sidebar overwhelm on first login; join-burst notification volume from 20–40 simultaneous channel joins |
| @channel and @here usage | All members (any member in any channel they have joined) | Workspace owners and admins only | Operator (workspace admin) | Workspace Settings → Permissions → Messaging | Broadcast-ping interruptions for new members with no context for the message; one of the two primary triggers for workspace muting within the first 72 hours |
| #start-here posting permissions | All members (Slack channel default) | Workspace owners and admins only | Operator (channel admin) | Channel Settings → Posting permissions | Member-added content appearing in the orientation channel and displacing the pinned orientation post from its visible position at the top of the channel |
| Per-member notification preferences (desktop, mobile, quiet hours) | All messages on all joined channels; desktop and mobile alerts enabled; no quiet hours | Not operator-controllable; individual member preference | Individual member (Slack preferences panel) | N/A — no admin path; this setting is outside operator control | N/A — mitigated indirectly by auto-join restriction (fewer channels = lower ambient notification volume) and @channel restriction (eliminates broadcast pings) |
| Per-channel auto-join override | Follows workspace default unless individually overridden | Disabled on all channels except #start-here and #introductions | Operator (channel admin; paid plans) | Channel Settings → More → Auto-join toggle | Individual channels overriding the workspace default and auto-joining new members regardless of the Invitations → Default channels setting |
Frequently asked questions
What Slack plan tier is required to change default channel settings for new members?
All plan tiers — Free, Pro, Business+, and Enterprise Grid — support the default channels setting under Workspace Settings → Invitations. The setting is not gated behind a paid plan. None of the three configuration changes in this reference card require Business+ or above: restricting @channel and @here permissions, changing default auto-join channels, and configuring #start-here posting permissions are all available on Slack Free and Slack Pro. The one feature mentioned in the narrative companion post as a partial workaround for the content discovery limitation — Slack AI channel digests — does require Business+ or Enterprise Grid, but it is not a setting within this reference card’s scope. Operators on any plan tier can implement all three workspace changes described here.
How do I verify that the default channel change worked after saving it?
The most reliable verification method is a test invite accepted in an incognito or private browsing window using a secondary Slack account (a personal email address not currently in the workspace). Accept the invite, complete the Slack account setup, and observe which channels appear in the sidebar after the new-member join sequence completes. If the change is correctly saved, only #start-here and #introductions should appear. If additional channels appear, check whether any individual channels have per-channel auto-join enabled — per-channel auto-join overrides the workspace default and must be disabled separately on each affected channel. On paid plans, per-channel auto-join is in Channel Settings → More. The workspace-wide default and per-channel auto-join interact: the workspace default controls what is added at invite; per-channel auto-join can add channels independently of the workspace default.
Can I set @channel and @here restrictions on a per-channel basis rather than workspace-wide?
Yes. Slack allows @channel and @here restrictions at two levels: workspace-wide (Workspace Settings → Permissions → Messaging) and per-channel on paid plans via channel posting restriction settings on Business+ and Enterprise Grid. The workspace-wide setting is the more reliable baseline for a paid community because it applies uniformly to all channels and does not require per-channel maintenance as the workspace grows. If a specific channel such as #announcements needs stricter posting restrictions (only operators can post anything at all, not just use @channel), configure that restriction at the channel level on top of the workspace-wide @channel restriction. The workspace-wide setting is the floor; per-channel posting restrictions layer above it. For most communities under 500 members, the workspace-wide @channel restriction combined with operator-only posting permissions on #start-here and #announcements is sufficient without additional per-channel overrides.
What should a correctly formatted #start-here orientation post contain to stay under 200 words?
Exactly four elements: (1) one sentence identifying what the community is for and who it is for, specifically enough that a new member recognises themselves; (2) one instruction — what to do right now (“go to #introductions and post a one-paragraph introduction using the template pinned to that channel”); (3) two or three channel links representing the most active or most relevant channels for a new member’s first two weeks; (4) one reference link to the full channel guide or Canvas for members who want to explore further. Community norms, event schedules, content archives, and member directories do not belong in the orientation post on day one. If the orientation post includes them, the member reads the first paragraph and closes the channel. The 200-word constraint is a forcing function: it prevents the operator from including information for all possible new-member questions and forces them to name the one action that produces a first contribution. Everything else belongs in the Canvas or in the Day 3 follow-up from the three-touch sequence that follows workspace setup.
At what community size should operators move from manual onboarding tracking to an automated three-touch sequence?
Manual tracking — a spreadsheet logging each new member’s join date, Day 0 DM status, Day 3 nudge status, and Day 7 check-in status — becomes the bottleneck at approximately 20–30 new members per month. Below that threshold, personal DMs from the actual operator often produce better activation outcomes than automated messages because the personal sender has higher perceived relevance. Above 20–30 new members per month, the per-member tracking overhead accumulates faster than the operator can manage it: Day 3 nudge timing becomes inconsistent (some members get it at day 3, others at day 6), the Day 7 scorecard is never assembled, and at-risk members identified by the scorecard do not receive follow-up. Consistency in timing is the variable that makes the three-touch sequence work. An automated sequence that fires the Day 3 nudge at exactly day 3 for every member is more consistent than a manual sequence that fires it approximately around day 3 for some members. Automation is not about the tool — it is about whether the sequence runs consistently at scale.