Module 4 — Communication · Lesson 4.5
Comms and Announcements
The broadcast surface, and choosing the right channel for a message everyone needs
~8 min
What you'll learn
- Use Comms for workspace-wide announcements
- Choose between Comms, a chat channel, and a notification
- Write an announcement people will actually read
- Avoid the two failure modes of a broadcast channel
Every workspace eventually needs to tell everyone something. Doing it in chat means it scrolls away; doing it by email means it lands outside the tool. Comms exists for the messages that should reach the whole workspace and stay findable.
What Comms is for
Comms, under the Workspace group, is the hub for broader workspace announcements and coordination.
The useful mental model is: chat is conversation, notifications are events, and Comms is announcements. An announcement is a message from the workspace to its members that does not expect a reply thread and does need to be findable later.
Typical content: a process change, an outage, a policy, a launch, an all-hands summary, a new person joining. Things that are true for everyone and that someone will want to look up in a month.
Choosing the channel
Three questions decide it.
Does it need a conversation? If the expected response is discussion, it is a chat channel. Broadcasting something contentious produces a broadcast followed by fifteen DMs, which is worse than a thread.
Does everyone need it? If it is relevant to one project, it belongs on that project or its channel. Broadcasting project-specific news is the fastest way to teach people to ignore broadcasts.
Will anyone look it up? If yes, it wants a durable home — Comms, or the knowledge base if it is really documentation. If a message is genuinely ephemeral, chat is the honest place for it.
Writing one people read
Lead with what changed and what the reader has to do. Most announcements bury both under context, and most readers stop before reaching them.
Be explicit about who it affects. 'Everyone' and 'engineering only' are very different messages, and saying which lets people who are not affected stop reading immediately — which is a kindness that makes them more likely to read the next one.
Say when it takes effect. An announcement with no date is a statement of intent, and people file it accordingly.
Keep it short enough that the whole thing fits on a screen. If it does not, the announcement is a link to a document, and the document belongs in Knowledge.
The two failure modes
Too much, and it becomes noise. A workspace that broadcasts weekly minutiae trains everyone to skim, and then the one announcement that mattered gets skimmed too. The defence is a bar: if you would not have sent it to everyone by email, do not broadcast it.
Too little, and it becomes a channel nobody checks. If Comms is used twice a year, nobody has the habit, and the important announcement lands somewhere people are not looking. The defence is to route a predictable class of message here — the weekly summary, every process change — so there is a reason to look.
The balance most teams land on is roughly one to four a month.
Use the broadcast surface deliberately
- 1
Open Comms and see what is there
If it is empty, that is the first thing to fix — an unused broadcast channel is one nobody checks.
- 2
Move one recurring message here
A weekly summary or a process-change note. A predictable class of message is what builds the habit of looking.
- 3
Rewrite one announcement lead-first
What changed, who it affects, what to do, when it starts — then the context.
- 4
Put the long ones in Knowledge and link them
If it does not fit on a screen it is a document, and a document has a better home.
What to watch
- Broadcast frequency
- How many workspace-wide announcements go out per month.
- Healthy signal: Our suggested band is one to four. Below that nobody has the habit; above it people skim.
- Follow-up DM volume
- How many direct questions an announcement generates.
- Healthy signal: Low. A flood of DMs after a broadcast means the message needed a discussion channel, not a broadcast.
Key takeaways
- ·Chat is conversation, notifications are events, Comms is announcements.
- ·If the message expects discussion, it belongs in a channel instead.
- ·Lead with what changed, who it affects, what to do, and when — context after.
- ·Too many broadcasts teaches people to skim; too few means nobody has the habit.
- ·Anything longer than a screen is a document, and belongs in Knowledge with a link from here.
Last in this module: making sure the right messages actually reach people, and the wrong ones do not.