A good client status update does one job: it tells the client where their project stands clearly enough that they do not have to ask. Do that well and you get fewer where-are-we emails, calmer clients, and a lot less firefighting. Do it badly, or late, and you get the opposite. Here is how to write one, what to avoid, and a sample you can copy.
Lead with the answer
The single biggest improvement you can make is to put the conclusion first. Clients open your update wanting one thing: to know whether their project is okay. So the first line should say it. On track. At risk. Off track. Everything after that is support for that headline. Most updates bury the answer under a list of activity and make the client dig for it, which is exactly the work they were hoping to avoid.
Cover six things, in order
A complete client update covers six things, and the order matters as much as the content.
- Overall status. One word or one line at the top.
- A plain-language summary. Two or three sentences on where things stand and the most important thing to know.
- What got done. The outcomes since the last update, not a task log.
- What is next. What will happen before the next update.
- Risks and blockers. Anything that could affect timeline, budget, or scope, and what you are doing about it.
- What you need from them. Decisions, approvals, or assets you are waiting on, each with a date.
If you cover those six, in that order, you have a complete update. If you are missing the last two, you have a progress brag, not a status update, and those are the two the client most needs.
A sample status update email
Subject: [Project name] update, week ending [date]
Hi [Name],
Quick update on where things stand. Overall the project is on track for
the [date] launch.
This week we finished the homepage design and it is ready for your review,
and development started on the booking flow. Next week we move into the
checkout build and send the first round of copy for sign-off.
One thing to flag: the product photography is now a week behind, which does
not affect the launch date yet but will if it slips much further. We have
followed up with the photographer and will keep you posted.
To keep us on track, we need two things from you:
- Homepage sign-off, by Thursday
- Final product list, by Monday
Next update this time next week. Anything you want to talk through before
then, just reply.
Thanks,
[Name]
Notice what that email does. The status is in the first two lines. The risk is stated plainly, with context and a next step, not hidden. And the client is given a short, dated list of what is needed from them, which is often the real thing holding a project up.
Common mistakes
Burying bad news. The instinct on a rough week is to soften or omit the problem. Resist it. Clients forgive issues they hear about early and lose trust over ones they discover late. A blocker named early is a manageable conversation. The same blocker discovered at the deadline is a crisis.
Too much detail. The client does not want your task list. They want outcomes and decisions. If your update reads like a changelog, cut it in half.
Sending it late. An update that arrives whenever you have time tends to arrive latest on the busiest weeks, which are exactly the weeks the client most wants to hear from you. A predictable update on a fixed day beats a thorough one that shows up whenever.
How often
Weekly suits most client work. It is frequent enough to catch problems early and infrequent enough to stay signal rather than noise. Increase it near a launch or through trouble, and only drop to monthly for slow retainers. Consistency matters more than frequency: the update a client can rely on arriving is the one that stops them chasing you.
The part worth automating
Every status update is really the current state of your project, written out by hand. The deadlines, what is blocked, what moved, all of it already lives in the tool you used to do the work. Writing the update is copying that out into an email once a week.
That is the part a tool should carry. SRP produces a client-facing view of the project automatically from the work itself, current whenever the client looks, so the update stops being a Friday chore and the internal truth and the client’s view are finally the same thing. We made the full case in the status email that writes itself. Until then, the sample above will serve you well.
