How to Write a Client Status Update

Key Takeaways

• Lead with the status word, then the ask, then what changed. The detail goes underneath for the people who want it.
• Send on a fixed day, whether or not there is news. Irregular updates make silence ambiguous.
• Name blockers with an owner and a date. A blocker with no owner is a complaint.
• Say when the date moves, on the day it moves, not in the update before delivery.
• Green, amber and red are only useful if amber means something specific. Define it once.
• The update is a paper trail. Write it so that reading it back in three months settles a disagreement rather than starting one.

The First Four Lines

A client scans. Assume the first four lines are all that get read and put everything load-bearing there.

Line one: the status. On track, at risk, or delayed, plus the date. Not "good progress this week". A word and a date.

Line two: what you need from them. The single most valuable line in the whole update, and it belongs at the top rather than buried at the bottom where most people put it. If you need nothing, say so, because "no action needed from you" is genuinely useful information.

Line three: what changed since last time. One sentence. If nothing material changed, say that plainly rather than manufacturing an update.

Line four: the next milestone and its date. So the client knows when the next thing lands and can tell you if it clashes with something you do not know about.

Then a divider, and the detail below for anyone who wants it: what was completed, what is in progress, decisions made, and anything worth flagging early.

The test: could someone read only the first four lines and know whether to act? If not, rewrite them. Most updates fail this test because they start with what the team did, which is the part the client cares about least.

Send It on a Schedule

An update that arrives when there is news is not a status update, it is an announcement, and it trains clients to treat silence as ambiguous.

Pick a day and time and hold it. Friday morning, Monday morning, whatever fits the project's rhythm. The value of a fixed cadence is that a client stops wondering. If it is Thursday and they have not heard, they know it is not Friday yet rather than wondering whether something has gone wrong.

Send it even when nothing happened. "On track for the 24th, no action needed, nothing material changed this week, next milestone is the first cut on Tuesday" is a complete and useful update. It takes ninety seconds and it is the one that builds the most trust, because it proves the cadence is real.

Weekly is right for most creative projects. Daily is noise unless you are in a crunch. Fortnightly is too slow for anything with a deadline inside a quarter, because a problem can grow for twelve days before anyone hears.

Keep it in one channel. A client who gets status by email, Slack and in calls has three versions of the truth and will believe whichever is most convenient. Pick the channel and be consistent.

Blockers Need an Owner and a Date

The most common failure in the detail section is a list of problems with nobody attached.

"Waiting on brand assets" is a complaint. It reads as an excuse, it gives the client nothing to act on, and it will still be there next week.

"Waiting on brand assets from Marco, needed by Thursday to hold the 24th" is a blocker. It names who, it names when, and it names the consequence. That sentence gets things unblocked because it makes the cost visible to the person who can fix it.

Always state the consequence. Not as a threat, as arithmetic: this is needed by Thursday to hold the date. Clients respond to concrete dependencies and ignore vague chasing, and most delays happen because nobody realised the thing they were sitting on was on the critical path.

Carry blockers forward, visibly. A blocker that has been open three weeks should say so. Quietly re-listing it every week without noting its age lets it become permanent.

Say When the Date Moves

The single most damaging thing you can do in a status update is discover a slipped date late.

Report the slip in the update after it happens, not in the one before delivery. A client who learns on the 22nd that the 24th is now the 31st has lost a week of their own planning time, and that is what they will remember about the project.

Attribute it factually, without blame. "Feedback arrived Tuesday rather than Thursday, so delivery moves from the 24th to the 26th." No editorialising, no passive aggression. The date arithmetic does the work.

Do the same for your own slips. Owning a delay you caused, early and plainly, costs far less credibility than people fear. Hiding it and hoping to catch up costs a great deal more, because when it surfaces it surfaces as both a delay and a concealment.

If you recover time, say that too. Updates that only ever report bad news get read as complaints. Reporting a date pulled forward or a milestone hit early keeps the channel balanced and makes the bad news more believable when it comes.

Make the Status Words Mean Something

Green, amber and red are useful only if everyone agrees what amber means, and almost nobody defines it.

Define them once, at kickoff, in one line each. Green: on track for the agreed date with no action needed. Amber: at risk, with a named cause and a named action that would fix it. Red: the date will move, or has moved.

Amber is the useful one and the one people avoid. Going straight from green to red is what destroys trust, and it happens because amber feels like admitting a problem. Amber is not a problem; it is a request for help while help is still cheap.

Never report green when you know it is amber. Everyone has done it, hoping to recover by next week. The cost is not the delay, it is that every future green becomes unreliable, and the client starts asking follow-up questions to information you gave them freely.

The Update Is a Paper Trail

Every status update is a dated record, and that changes how you should write the ambiguous parts.

Record decisions, not just progress. "Agreed to drop the second location to hold the date, confirmed by Priya on Tuesday" is the line that settles an argument in three months. Verbal decisions that never reach a written update effectively did not happen.

Record scope additions where they occur. Not as a confrontation, as a fact with a number: "added the vertical cut, half a day, delivery moves to the 26th." A client who reads that weekly is never surprised by an invoice.

Write it so it reads well to someone who was not there. In a dispute, the updates will be read by a finance person or a new stakeholder with no context. Neutral, factual and dated is what serves you.

Keep them. A folder of dated updates is the cheapest project documentation that exists, and it is the thing you will want if a project goes badly.

A Template You Can Reuse

Adjust the tone; keep the order.

> Status: on track for delivery on the 24th. > > Needed from you: feedback on v02 by Thursday. Nothing else. > > Changed this week: the second location fell through, replaced with the studio, no impact on the date. > > Next milestone: first cut, Tuesday the 19th. > > --- > > Completed: shoot day two, selects, assembly. > > In progress: first cut, graphics. > > Decisions: dropped the drone shots after the location change, agreed with Priya on Tuesday. > > Open: brand assets from Marco, needed Thursday to hold the date. Open since the 5th.

Four lines and a divider. The whole thing takes ten minutes and it does more for a client relationship than any amount of enthusiasm in a call.

What Tooling Helps

Very little, honestly. A status update is a short, well-ordered message, and the tool that delivers it is whatever the client already reads.

Project management tools generate status automatically and the generated version is almost always worse, because it reports task states rather than answering the client's question. Automated updates are useful internally and a poor substitute externally.

Storyflow is our product and it does not do this. It has no status reporting, no task states, no notifications and no client portal, so send the update in email or the client's channel. The adjacent job is upstream: keeping the decisions and the scope on one canvas so the update has something accurate to report. Paid-only during early access, with the Free plan landing before the end of 2026, and anyone a paid member invites to a board joins free now.

The Bottom Line

A status update is a service to the reader, not a report on the writer.

Answer three questions in the first four lines: are we on track, what do you need to do, what changed. Detail below the divider for whoever wants it.

Send on a fixed day even when nothing happened, because a reliable cadence is what makes silence unambiguous.

Give every blocker an owner, a date and a consequence, or it is a complaint that will still be there next week.

Report slips the moment they are true, and report recovered time too so the channel is not only ever bad news.

Define green, amber and red once, and use amber, because amber is what stops a project going from fine to late with nothing in between.

Nobody reads a status update to find out what you did. They read it to find out whether they need to do something.