← all posts

How to Write Async Updates That Actually Get Read

May 4, 2026

You’ve been sending async updates for months. Some get a reply. Most get nothing. You have no idea if the silence means “seen and handled,” “seen and deferred,” or “not seen at all.” So you send a follow-up two days later, which feels like nagging, and the whole thing starts again.

The problem is almost certainly not length, tone, or the tool you’re using. It’s structure. Specifically: your update probably doesn’t tell the reader what to do next — and when a message doesn’t carry an action layer, the reader’s default is to defer it until they have more context, which means it disappears.

This article is about how to write async updates that are designed to get actioned, not just read. If you’re part of the broader async coordination architecture your team relies on, the mechanics here are where that system either holds or breaks down.

Why most async updates fail before anyone reads them

The update gets posted. The reader glances at it. They don’t know if they’re supposed to reply, decide, acknowledge, or just absorb it. So they move on, intending to come back. They don’t come back. You follow up 48 hours later.

This is not a people problem. It’s a message design problem.

The missing action layer

Every async update has an implicit ask — even a purely informational one has an implicit ask of “adjust your understanding.” But implicit asks are silent. The reader has to reconstruct what you want from context, and most of the time they won’t.

The action layer is the explicit statement of what you need the reader to do, who specifically needs to do it, and by when. Without it, the message is a broadcast signal with no destination. The reader who gets it has no role assigned. The message gives them nothing to act on, so they act on nothing.

This is structural, not motivational. A team of 6 or a team of 60 fails in exactly the same way when messages don’t carry an action layer — and it’s fully fixable at the writing level.

Broadcast vs. request: two different artifacts

There are two fundamentally different types of async update, and they need different shapes. Mixing them up is the single most common failure mode.

A broadcast update is informational. You’re not asking for a response. “The Q2 roadmap is locked — here’s the link.” That’s a broadcast. No action needed. The implicit ask is: note this and move on.

A request update requires something to happen. A decision, a review, an approval, an answer. The reader has to do something. “Thoughts?” at the end of a long message is a request that doesn’t know what it’s asking for — and that’s the problem. It reads like a broadcast but expects a response.

The failure pattern: you embed a request inside what looks like a broadcast. The reader files it under “FYI” because that’s how it reads. The request never gets actioned. Three days later you’re wondering why nobody responded.

Trust erodes steadily when this happens at scale. People learn to skim updates labeled FYI because they’ve been burned by hidden asks before. Label your type explicitly, and mean it.

The template for how to write async updates

A request update that consistently gets actioned has four parts. Each part removes a different type of ambiguity. You can adjust the format per channel, but the content should always cover all four.

Context: why this update exists

One sentence. What changed, or what’s in motion. Not background on the project — the immediate trigger for this message.

Example: “The design agency sent over two logo options this morning. We need to pick one before Wednesday’s print deadline.”

No preamble. No “as you may know.” The reader learns, in a single sentence, what the situation is and why it’s pressing.

The decision or action needed

State it explicitly. Name the person. Name the action.

Bad: “Let me know your thoughts.” Bad: “Would love some input on this.” Good: “Priya and Dom — please review the two options linked below and add your preference to the Notion page by Tuesday 3pm ET.”

If you don’t name the person, you’ve published the ask into a void. Someone who sees it may act on it, but nobody is responsible for it.

The deadline

Specific. Day, date, time, timezone.

“EOD” is not a deadline. EOD in New York is 5pm ET. EOD for someone in Singapore is 5am the next day by Eastern time — and that’s if they even share your assumption about what “end of day” means. The ambiguity is guaranteed unless you remove it.

“By Tuesday, April 29, 5pm ET” removes it. A vague deadline is no deadline.

What happens if there’s no response

State it. Explicitly. In the message.

“If I don’t hear back from Priya and Dom by Tuesday 5pm ET, I’ll proceed with Option A and send it to the printer.”

This is the most underused line in async communication. It tells the reader what’s at stake if they don’t act, removes the need for a follow-up, and creates a forcing function without nagging. You’re not threatening anyone — you’re describing the consequence of silence so everyone can plan around it. The response-time agreements that make “if I don’t hear back” land require this kind of stated consequence, or they don’t work.

Calibrate the consequence to the stakes. For a minor formatting decision: “I’ll proceed with Option A.” For a decision that affects the whole team: “I’ll escalate to the group on Wednesday.” Either is fine. What’s not fine is no statement at all, which means the thread stays open indefinitely and the follow-up nag is coming.

The full template applied:

Context: The design agency sent over two logo options this morning. We need to pick one before Wednesday’s print deadline.

Action needed: Priya and Dom — please review both options (linked below) and add your vote to this Notion page.

Deadline: Tuesday, April 29, 5pm ET.

If no response: If I don’t hear from both of you by then, I’ll proceed with Option A.

That’s 68 words. It will get read and actioned. A 300-word message without these four parts won’t.

Ambiguity is the enemy, not length

A 400-word update can be perfectly clear. A 40-word update can be completely opaque. Length is the wrong variable. Ambiguity is the problem — specifically, ambiguity about who needs to do what and by when.

What “unclear” actually looks like in practice

Ambiguous async updates share recognizable patterns. Once you can name them, they’re easy to fix before you send.

Passive constructions: “A decision needs to be made on the vendor contract.” Who makes the decision? Nobody knows. Passive constructions reflect genuine uncertainty about ownership — but writing it in the passive voice just obscures that gap without resolving it.

Missing ownership: “Someone should review this before we proceed.” Someone. This is a request that doesn’t know who it’s asking. In a team of 8, “someone” means each person reads it and assumes one of the other seven will handle it.

Vague timelines: “Can you take a look at this soon?” Soon. Does that mean today? This week? Before the next sprint? If your mental model of “soon” is Tuesday morning and your colleague’s is Friday afternoon, neither of you is wrong — you’re just operating on different timelines. Neither of you knows that.

Implicit asks: “Thought you’d want to see this.” This is a broadcast masquerading as something. The reader doesn’t know whether you want a reply, a decision, or just acknowledgment. They’ll probably do nothing.

The context-collapse failure mode this template prevents is exactly this: the reader and writer are in different contexts, and the message doesn’t bridge them. The reader doesn’t know what you know, what you’re expecting, or what’s at stake.

How to test your update before sending it

One check: can you read the message and answer “what do I need to do, and by when?” in under 10 seconds? If you have to re-read to find the ask, so does your reader. Except they won’t re-read — they’ll move on.

For request updates: cover the four template fields above. For broadcast updates: confirm there’s no hidden ask in the body. If the words “thoughts?” or “let me know” appear anywhere in a message you’ve labeled FYI, it’s not a broadcast — revise it. Writing async messages that pass this test consistently is a learnable habit, not a talent.

How to write async updates for each channel

The four-part structure above works across every channel. What changes is how you express it — the format that fits the channel’s medium and reading patterns.

Slack: short, skimmable, one ask per message

Slack is optimized for speed, not documentation. The reader is scanning a stream of messages, probably on a phone, probably while doing something else.

Keep request updates short. The action and deadline belong in the first 2–3 lines — never in paragraph 3. Use threads deliberately: post the short ask in the main channel, put the full context in the thread for anyone who wants it. Never bury the action in a wall of context.

One ask per message. If you need two things from two different people, send two messages. The second ask in a multi-ask message rarely gets done.

Don’t use Slack for decisions that need a paper trail. If you need a record of who decided what and when, Slack is the wrong tool.

Email: subject line is the lede, body is the backup

Most people open email by scanning subject lines. Your subject line is doing the work your first paragraph used to do. Use it.

Weak: “Q2 campaign update” Strong: “Review needed: Q2 campaign brief — by Wed April 30, 5pm ET”

The strong version tells the reader what’s needed and by when before they open it. Body provides context. Put the action first in the body too — don’t make the reader scroll to find the ask after three paragraphs of background.

Notion or GitHub: structure compensates for low urgency signals

Nobody is watching Notion. Nobody has a notification set for a Confluence page. A document posted standalone to a wiki is a document that probably won’t get seen.

Structure compensates. Use callout blocks or bold action headers at the top of the document, not buried in a subsection. But also: post a Slack message with a direct link to the page. The Notion page is not the delivery mechanism — the Slack message is. The page is where you put the context.

For GitHub PRs and issues: name your reviewers explicitly in the description, not just via GitHub’s reviewer assignment UI. Give one sentence of scope context (“this changes the auth flow — review the middleware changes most carefully, the UI is cosmetic”). Use checklists for multi-part reviews. Explicit structure is what separates a PR that gets reviewed from one that sits in the queue.

How to know if an async update actually landed

There’s a difference between “read and skimmed” and “read and actioned.” The signals are different, and learning to read them tells you whether your message design is working.

Signals an update landed:

Signals it didn’t:

If you’re consistently sending follow-ups within 48 hours, that’s a diagnostic signal. Not that your colleagues are bad at async — that your updates aren’t making the action visible enough, or aren’t making the consequence of non-response clear enough. This pattern is especially common with distributed team updates, where time zone gaps mean silence sits longer before anyone notices it.

The “if no response” clause in the template fixes most of this. When there’s a stated consequence, the reader has a reason to respond or explicitly opt out. When there’s no consequence, silence is rational behavior.

Calibrate the consequence clause to the stakes. Minor decisions: “I’ll proceed.” Significant decisions that affect multiple people: “I’ll flag this in Wednesday’s sync.” High-stakes decisions with real risk: “I’ll escalate to [name].” The escalation path should be proportional — not every unanswered message needs to go up the chain.

The through-line in all of this is the same: async updates fail when the reader has to do interpretive work to figure out their role. Every structural choice in the template — explicit action, named recipient, specific deadline, stated consequence — removes one layer of that work. Remove enough layers and the message gets actioned instead of deferred.

If you start with one change, make it the “if no response” line. It’s the most underused and highest-leverage move in async writing. The first time it eliminates a follow-up you would have sent, you’ll make it permanent.

Related reading from the broader async coordination architecture: