Slack’s default state is chaos. Install it, invite your team, and within a month you’ll have 40 channels, half of them dead, with important decisions buried in DMs nobody else can see. We’ve been through three versions of our Slack setup. The current one works, and the pattern is replicable.
This guide covers channel structure, naming conventions, notification settings, and — most importantly — the cultural rules that keep Slack from becoming a full-time job.
The channel naming system
Every channel in our workspace follows a prefix convention. This isn’t original — companies like Buffer and GitLab have published similar systems — but the consistency is what makes it work.
Our prefixes:
#proj-— Active projects. One channel per project. Archived when the project ships.#ops-— Operational topics that are ongoing:#ops-hiring,#ops-infrastructure,#ops-finance.#team-— Team-specific channels for groups that need a shared space:#team-engineering,#team-content.#social-— Non-work:#social-general,#social-pets,#social-music. Whatever people want.#announce-— Broadcast channels. Only leads can post. Used for company-wide updates. Comments go in threads.#help-— Questions and requests:#help-it,#help-design,#help-data.
The rule: if a channel doesn’t fit one of these prefixes, it probably shouldn’t exist. This prevents the drift toward #random-ideas, #cool-articles, #q4-planning-v2 channels that accumulate and go stale.
Why prefixes matter
Prefixes do three things:
- Discoverability. New hires can browse by prefix to understand what’s available. Type
#proj-and see every active project. - Expectations. A
#social-channel has different norms than a#proj-channel. The prefix signals what kind of communication belongs there. - Cleanup. When a project ships, archive every
#proj-channel associated with it. The prefix makes bulk cleanup trivial.
Channel rules we enforce
Having a naming system is step one. The harder part is the behavioral rules. These are ours:
Threads are mandatory in project channels
Every top-level message in a #proj- or #ops- channel should be a discrete topic: a question, an update, a decision request. Discussion happens in the thread. This keeps the channel scannable — you can scroll through top-level messages and know what’s been discussed without reading every reply.
We enforce this socially. When someone posts a reply at the top level instead of in a thread, someone else gently redirects them. It took about two weeks for this to become habit.
DMs are for personal conversations, not project work
This is the single most important Slack rule we have. If a conversation is about a project, a client, or a decision, it goes in the relevant channel — not in a DM or group DM.
Why: DMs create information silos. When two people discuss a project in DMs, the rest of the team loses context. When that conversation needs to be referenced later, it’s invisible. And when one of those people leaves the company, the knowledge goes with them.
We make one exception: DMs are fine for truly personal topics (scheduling time off, quick favors, sensitive HR matters). Everything else goes in a channel.
@here and @channel need a reason
Our guideline: if you’re about to ping an entire channel, write one sentence explaining why it’s urgent enough to interrupt everyone. If you can’t write that sentence, it’s probably not urgent.
In practice, @here gets used 2-3 times per week across the entire workspace. That’s the right frequency — it means the notification actually means something when it arrives.
Set a channel purpose and pin key resources
Every channel has a purpose statement (Slack’s built-in field at the top). This should be one sentence: “Active discussion for the Q1 site redesign project” or “IT support requests — expect a response within 4 hours.”
Each channel also has 2-3 pinned messages: the relevant Notion doc, the project brief, or the team’s response time expectations. When someone new joins a channel, pinned messages are the first thing they should check.
Notification settings that preserve focus
In our experience, Slack notifications were the biggest contributor to that “always on” feeling. The defaults are aggressive — every message in every channel generates a notification. We recommend a specific configuration for every team member:
Desktop notifications: Set to “Direct messages, mentions & keywords” only. Not “All new messages.” This is in Slack > Preferences > Notifications. (Slack’s notification guide walks through the full settings.)
Channel-specific overrides:
- Mute
#social-channels entirely (check them when you want to, not when they ping you). - Set
#announce-channels to “Every new message” since they’re low-volume and important. - Leave
#proj-channels at default — you’ll get notified when mentioned.
Schedule: Use Slack’s notification schedule (Preferences > Notifications > Notification schedule) to set a window. Ours is 9am–6pm in each person’s local time zone. Outside that window, Slack holds notifications until the next morning.
Do Not Disturb: Encourage team members to use DND during focus blocks. A 2-hour DND window in the morning and another in the afternoon is common on our team. This is in addition to the scheduled quiet hours.
The combination of these settings means most people check Slack 3-4 times per day during focus blocks and respond in near-real-time during coordination windows. That’s the right balance for async work — you’re reachable, but you’re not reactive.
When to move conversations out of Slack
Slack is good at short, transient coordination. It’s bad at everything else. We have clear triggers for moving conversations to other tools:
Move to Notion when:
- A decision has been made and needs to be recorded
- A discussion has generated a process or spec that others will reference
- A thread has passed 20 messages and is becoming a document
Move to Loom when:
- You need to walk through something visual (a UI, a spreadsheet, a workflow)
- Tone matters and text feels ambiguous
- You’re explaining something complex that would take more than a few paragraphs
Move to a call when:
- There’s a disagreement that’s generating heat in text
- You’ve gone back and forth more than three times without resolution
- The topic is sensitive or personal
The test we use: “Will this Slack thread be useful to anyone in a week?” If yes, the content needs to land in Notion. If no, Slack is fine — it’s ephemeral by nature.
The weekly Slack audit
Every Friday, one person on our team (it rotates) does a 15-minute Slack audit:
- Archive dead channels. Any
#proj-channel for a shipped or cancelled project gets archived. - Check for orphan conversations. Are there important threads in DMs that should be in channels? Gently redirect.
- Review new channels. Did anyone create a channel that doesn’t follow the naming convention? Rename or merge it.
- Update pinned messages. Are the pinned resources in active channels still current?
This prevents Slack entropy. Without regular maintenance, workspaces accumulate channels like a closet accumulates junk. Fifteen minutes a week keeps it manageable.
What this looks like in practice
A typical day for someone on our team:
- Morning (9–9:15): Open Slack, scan
#announce-channels, check mentions, respond to anything urgent in#proj-threads. - Focus block (9:15–11:30): Slack closed. DND on. Deep work.
- Midday (11:30–12:00): Check Slack again. Respond to threads. Post async updates on any projects.
- Focus block (1:00–3:00): Slack closed again.
- Afternoon (3:00–3:30): Final Slack check. Clear threads, post any EOD updates.
Total Slack time: about an hour, spread across three sessions. That’s enough to stay coordinated without losing the day.
The structure matters more than the tool. If you moved this same system to Microsoft Teams or Discord, it would work the same way — because the value isn’t in Slack’s features, it’s in the rules and habits your team builds around it. Start with the naming convention, enforce threads, move DMs to channels, and fix your notifications. The rest follows.