Async standups: what we actually send each morning

We tell prospective clients we send a daily async update, and the follow-up question is always the same: what does that actually contain? A vague daily message ("made good progress today") is barely better than no update at all. The format matters as much as the frequency, and it took us a few iterations to land on one that's actually useful to read.

Every update covers exactly three things: what got finished yesterday (specific enough to check, not "worked on the homepage" but "completed the homepage hero and stats section, pending your review"), what's planned for today, and any open question or blocker that needs client input to move forward. Anything beyond those three lines gets cut, since a longer update is one people skim rather than read.

Burying a question inside a paragraph of status update means it often gets missed entirely, and the team ends up waiting days for an answer that was technically asked for but not clearly flagged. A standalone, bolded "Need from you" line makes it impossible to skim past, which is the single change that's most reduced our average time-to-unblock across client engagements.

We post updates directly in the tool the client already checks, a shared Linear project, a Notion page, a Slack channel, rather than a separate email that competes with everything else in an inbox. The update needs to be somewhere the client would naturally look anyway, or it becomes one more thing they have to remember to check.

Internal process details, which team member did what specific task, minor technical decisions that don't affect the client-visible outcome, stay out of the client-facing update entirely. Those details matter to us internally and would just be noise to a client trying to get a fast, useful read on project status.

With a genuinely useful daily async update in place, weekly calls stop being status reports (which the client has already read) and become actual strategic conversations: reviewing direction, discussing trade-offs, planning the next phase. That shift alone is usually the most noticeable difference clients report after their first few weeks working with an async-first process.

Some days, especially during a longer investigative or research task, don't produce a clean, checkable deliverable. We still send an update on those days rather than skipping it, but we're honest about the nature of the work: "Investigated the payment webhook failure, ruled out three possible causes, narrowing in on a timing issue with the retry logic, expect a fix tomorrow." That's a legitimate update even without a finished feature attached to it, and it's a meaningfully different signal to a client than silence, which tends to read as no progress at all even when real, necessary work happened.

It's tempting to pull status automatically from a project management tool and generate the daily update without a person writing it, and we tried a version of this early on. It consistently produced technically accurate but practically useless updates, since a raw list of tickets moved between columns doesn't convey the same thing as a person's judgment about what actually matters that day. We went back to a person writing a short, deliberate update each morning, which takes a few extra minutes but produces something a client actually reads and trusts.

Early in a project, updates lean heavily on describing new work, since there's a lot of ground being covered for the first time. Once a project reaches a steady maintenance or iteration phase, we shift the format slightly, spending more of the update on what changed in production and its early results, and less on describing routine work that's become predictable to both sides. Keeping the format rigid regardless of project phase eventually makes updates feel like empty ritual rather than genuinely useful communication, so we treat the three-line structure as a floor, not an unchangeable template.

When we ask clients directly what they'd miss most if we stopped sending daily updates, the answer is almost never the specific content of any single day's message. It's the cumulative effect: a searchable, dated record of exactly what happened and when, which becomes genuinely useful months later when a client needs to reconstruct why a particular decision was made, or when a new team member on the client's side needs to get up to speed on a project's history without scheduling a series of catch-up calls.

A meaningful share of our clients are working from a time zone eight or more hours removed from ours, which changes how the daily update actually gets used. Instead of a same-day check-in, the update is often the first thing a client reads at the start of their own workday, several hours after we've already sent it and moved on to other work. We write with that gap in mind, making sure the "need from you" line is specific enough to act on without a live conversation, since waiting for a same-day reply from a client eight time zones away simply isn't realistic, and a vague question just adds another full day of delay before it gets resolved.

This is also why the async format tends to outperform live daily standups for distributed teams generally, not just for client communication. A live call assumes everyone's available at the same moment, which rarely holds true past a couple of adjacent time zones, while a well-written async update works regardless of when each side actually reads it.

Clients coming from an agency that used a traditional weekly-status-email model consistently mention the same adjustment period: the first few daily updates feel like more information than they're used to processing, and it takes about a week before they stop reading every line closely and start scanning for just the blocker line and any specific decision point, trusting that the rest is handled unless flagged. That's actually the intended end state. A daily update that still requires careful, worried reading after two weeks hasn't yet earned the trust that makes async communication actually save time instead of just relocating the anxiety of a weekly call into a daily one.