How to Write a Slack Message People Actually Read
Most advice about Slack is about etiquette. This is not that. The reason your messages get ignored is structural: you are writing them as conversation, and they are being read as a queue.
Someone opening Slack after two hours in meetings has a long list of unread conversations and a glance for each one to decide whether it needs them. A message that does not survive that glance does not get a slow reply. It gets scrolled past, marked unread with good intentions, and never returned to.
The basics are well known: ask first, name a person, give a date. Where most threads actually stall is the step after, when a question goes to a group and nobody decides. An open question to a channel gets silence or six opinions. A proposal with a default and a deadline gets a decision.
The question every reader asks first
In that glance a reader is answering exactly one question: is this mine to do?
Everything that helps them answer it earns its place. Everything else is in the way. In practice that means three things, in this order:
- The ask in the first line. Not the context. Not the greeting. The thing you want.
- A name or a clear "nobody in particular". Ambiguous ownership reads as somebody else's job to every single reader. If you do not know who owns it, say so: "I don't know who owns this. @Dan, can you point me at the right person?"
- A deadline, if there is one. "When you can" is read as "never", and honestly it usually is.
Everything else, the background, the reasoning, the links, goes underneath, where the people who need it will find it.
Six rewrites
1. Put the ask first, context second
Before
Hey! So I was looking at the analytics dashboard this morning and noticed the signup numbers looked a bit odd for last week, especially Tuesday and Wednesday. I checked with Marco and he said the tracking script was updated on Monday. Anyway I think we might need to decide whether to rerun the report?
After
@Priya: can you decide by Thursday whether we rerun last week's signup report? Context: the tracking script changed on Monday and Tuesday and Wednesday look wrong. Marco confirmed the change.
Same information, same length. The difference is that Priya knows in line one that this is hers, and everyone else knows in line one that it is not theirs.
2. Never send "quick question"
Before
quick question when you have a sec
After
Do we need legal sign-off before sending the pricing page to the customer advisory group? No rush, but I'd like to know before Friday.
A message with no content is a request for a second message, and it costs you hours of round trip. The same goes for "hi" on its own, "got a minute?", and "are you there?".
3. Send one message, not seven
Before
so about the migration we're basically ready except the staging db which is still on 14 and I don't think we can upgrade it before Thursday do you think that's a blocker? or should we just go anyway
After
Migration: is staging still being on Postgres 14 a blocker for Thursday, or do we go anyway? Everything else is ready and I don't think we can upgrade staging before then.
Seven messages send seven notifications, arrive out of order on a phone, and cannot be quoted in a thread. Press Shift + Enter for a new line inside one message. If you do this often, Slack's Preferences, then Advanced, has an option to make Enter insert a newline and require Command + Enter to send.
4. Make the status update skimmable
Before
The redesign is going okay, we finished the settings screens last week and started on onboarding, though there's been some back and forth with design about the second step which has slowed us down a bit, and we're also waiting on the copy from marketing which was supposed to arrive Monday.
After
Redesign, week 3. On track for the 14th. Done: settings screens. In progress: onboarding, slowed by open questions on step two. Blocked: waiting on marketing copy, due Monday, still not received. @Sam can you chase?
Status updates are read by people scanning for two words: "blocked" and their own name. Give them both in a shape they can find.
5. Escalate with facts, not adjectives
Before
This is getting really urgent now, we've been waiting ages and it's becoming a serious problem for the whole team.
After
We've been blocked on the API keys since Tuesday. Three people are idle and the launch date moves if this isn't resolved by Thursday. @Dan, who owns this?
"Urgent" is a claim. Dates, headcount, and consequences are evidence. The second version is also easier to act on, because it names the decision and the person.
6. Do not open a decision you are not prepared to close
Before
What does everyone think about moving standup to 10am?
After
I'm moving standup to 10am from next Monday, so it doesn't clash with the support handover. React with a thumbs down by Friday if that breaks something for you.
An open question to a group produces either silence or six opinions and no decision. A proposal with a default and a deadline produces a decision. This one pattern removes more stalled threads than any other.
The async patterns worth learning
State the default. "Unless I hear otherwise by Thursday, I'll go with option B." Silence becomes a decision instead of a delay. It also means the people who do not care correctly do nothing.
Put the thing in the message, not behind a link. A link is a second decision. If the point is three sentences long, write the three sentences and link the detail underneath.
Use threads for the working out, the channel for the outcome. When a thread resolves, post the conclusion with "Also send to channel", because nobody reads a 40-reply thread to find out what was decided.
Say what your reactions mean. Eyes for "I am looking at this", check for "done", thumbs up for "I agree". Say which you mean the first time, and they close loops that would otherwise sit open.
Earn @here and @channel. Each one notifies everyone in the channel, including people on holiday. Overuse them and people mute the channel, and then your real emergency does not reach them.
Pick DM or channel on purpose. Anything a third person might need to know, or find in six months, belongs in a channel.
The 15-second check before you send
- Is the ask in the first line?
- Does it name one person, or clearly nobody?
- Is there a date, or an explicit "no rush"?
- Can the whole thing be read without scrolling?
- If you were skimming past this at speed, would you know whether to stop?
If the message fails the last one, the fix is almost always to move a sentence from the bottom to the top.
Tightening a message without retyping it
The rewrites above are all the same operation: cut, reorder, sharpen. Doing that by hand is the slow part, which is why most people send the first draft.
BlinkWrite does it in place, in the Slack composer itself, whether you use the Slack app or Slack in a browser:
- Write the message the way it comes out.
- Double-tap Tab to open rephrasing.
- Choose Shorten to cut it down, Improve for clarity, Friendly to soften an escalation, or Custom for a specific instruction such as "put the question first and keep the dates".
- Press Tab to apply it, or Esc to keep what you wrote.
Rephrasing changes the current paragraph only and works in any Mac or Windows app with a normal text field. In Slack specifically, BlinkWrite also reads the surrounding conversation, so corrections and suggested replies fit the thread rather than being generic. Supported apps lists where the full set works, and the rephrasing guide covers each mode.
The same instincts apply to email, where the stakes are usually higher and the reader is even less patient. How to make an email sound more professional covers that side.
Common questions
Is it rude to write short messages in Slack?
No. Short is the courtesy. What reads as rude is a message with no greeting and no clarity about what you want, and the fix is the second half, not the first. "Hi Sam, can you approve the invoice by Thursday?" is short and warm at the same time.
Should I say hello before asking my question?
Say hello in the same message as the question. The problem was never the greeting; it was sending the greeting alone and making someone wait for the point.
When should I use a thread instead of the channel?
Any reply that does not need to be seen by the whole channel. Discussion, clarification, working out. Post the outcome back to the channel so the decision is findable.
How long is too long for a Slack message?
Longer than one screen without scrolling. Beyond that, the format is wrong rather than the length: put it in a document or a post and link it with a three-line summary.
Does anyone actually read @here?
The first few times. After that, a channel that overuses it gets muted, and muting is permanent in a way that your next real emergency will discover.