speakbites
CoursesHow it worksSpeech AnalyzerRewriteBlogPricing
Local time—•
Start learning
All guides
September 5, 2026·5 min read

How to Write a Work Message That Gets a Reply (Slack & Email)

Practise this in the Async That Lands courseOpen the course

Short answer: Messages get ignored when they contain no single clear ask, no deadline, and no obvious owner. Fix it by putting one specific request, one date, and one person in every message - and, if it could read as cold, one line naming your intent. A message that can be answered in one line gets answered in one minute.

Most work happens in writing now - Slack, email, tickets, docs - and nobody taught us how to do it. We learned to talk in person, then moved the whole job into a text box. Here's why your messages stall and exactly how to fix them.

Reason 1: There's no actual ask

The most common reason a message gets ignored is that it doesn't ask for anything. It has a topic and a mood, but nothing to do.

Before:

Hey! Hope you're well. We're putting together the Q3 deck and there's a section on retention that touches your area - no rush, but if you have any thoughts or numbers that might be useful, that'd be great!

The reader scans it, finds nothing they must do, and files it under "later" - a folder with no bottom. "No rush" reads as "no deadline," so it loses to every request that has one.

After:

Hey - can you send me the Q3 retention numbers (D7 and D30) by Thursday? They're the last gap in the deck. If Thursday's tight, tell me and I'll use last quarter's.

The rule: one ask, one deadline, one owner. Every request should contain exactly one thing to do, one date, and one responsible person. If your message has three asks, it effectively has zero - the reader can't tell which one matters.

Reason 2: It reads colder than you meant

Text strips tone. Research on communicating over email (Kruger et al., 2005) found senders expect their tone to be read correctly about 80% of the time, while readers actually get it closer to chance. You hear your own friendly voice as you type; the reader supplies their own - and under pressure, the voice they supply is rarely generous. A short message from someone senior reads as displeasure by default.

Before: "Why was this changed?"

After: "Curious about the change to the checkout copy - what was the thinking? Might be a good call, I just want to make sure I'm not missing context."

The rule: add the missing warmth on purpose. In writing, warmth doesn't arrive for free - you have to type it. One clause of stated intent ("just checking," "might be a good call") does the job your face would have done in person. One is enough; stacked apologies read as either weakness or sarcasm.

Reason 3: You made them do the context work

You have all the context; the reader has none. This is the curse of knowledge - once you know something, it's genuinely hard to model not knowing it. So your "quick question" is quick for you and expensive for them, which sends it to the back of the queue.

Before: "Quick q - is the sync broken?"

After:

Sync question - the nightly job for EU accounts hasn't run since Tuesday (last success 03:14, no error in the log I can see). I've already checked the credentials and the cron entry, both look fine. Q: is there somewhere else the failure would surface, or should I just re-run it?

The rule: pre-chew the context. Before you ask, supply four things - what you observed, when, what you already tried, and the exact question. A question that can be answered in one line gets answered fast.

Reason 4: It should have been a call

If you're several replies deep and the last two messages were both attempts to clarify the previous one, the channel is wrong, not the people. Text is a lean channel - no tone, no instant repair - and once a thread is repairing itself, each new message adds cost without adding clarity.

The rule: switch channels on the second misunderstanding. "Feels like we're talking past each other in text - 10 minutes on a call will be faster. Free at 3? I'll post the summary back here." Then actually post the summary, so the decision stays searchable.

A quick template you can reuse

For a request:

[One specific ask] by [day]? It's needed for [why it matters]. If that doesn't work, [fallback].

For a status update people will actually read:

Shipped: … · Changed / at risk: … · Need from you: …

That's most of the job. In writing, everything your body would have supplied - tone, urgency, context, closure - has to be typed on purpose. That's the whole skill.

FAQ

Why do people ignore my Slack messages?

Usually because there's no single clear ask, no deadline, or no obvious owner - so there's nothing the reader must act on. Add one specific request, one date, and one responsible person. If the message could read as cold, add one line naming your intent.

How do I write a polite reminder without being annoying?

Reference the original ask, restate the deadline, and offer an out. For example: "Following up on the retention numbers for the deck - still hoping for them by Thursday. If it's not doable, tell me and I'll use last quarter's." It's a nudge plus a fallback, not pressure.

How do I make an email sound friendly without being unprofessional?

Add exactly one warmth signal - a clause that states your intent or acknowledges the person ("thanks for the quick turnaround yesterday"). One is enough. Over-softening with multiple apologies reads worse than a plain, warm sentence.

When should I send a message versus schedule a call?

Use writing for anything factual or simple, and a call for anything ambiguous or emotionally charged. A good rule: after the second back-and-forth misunderstanding in a thread, switch to a call - then post a short summary back in the thread so the outcome is written down.

What's the best structure for a work status update?

Three lines: what shipped, what changed or is at risk, and what you need from the reader. Skip the activity diary - "continued working on X" tells the reader nothing they can act on. Report the delta, not the day.

Go deeper

Practise this in the Async That Lands course

Real situations, before/after examples, and a quiz. Chapter 1 is free.

Open the course