The short version
- Status is ours to report. The decision is the client's to make.
- An ask carries the real options and a date. The same recommendation presented as a plan already in motion is a decision you took without asking.
- Report a blocker the week it appears, with the gate and its owner named. Blockers reported late read as excuses.
- Say what happens by default if nobody answers. Silence counts as approval only when both sides agreed it does.
A client update reports status and stops there. We write one every week on every account, 8 of them covering 11 brands, and the line we hold is that a decision belonging to the client leaves our side as an ask with options and a date, never as a plan already in motion.
What belongs in a client status update?
Five things. What shipped, with links to it. What is in flight and when it lands. What is blocked, and whose approval clears it. What we are asking them to decide. And what we will do by default if nobody answers by a stated date. Everything else is padding.
Links do more work than they look like they do. A line saying the landing page is done and a line saying it is done with the URL beside it are different claims, and only one can be checked.
Every line of a weekly update, and who owns it:
| Line | Who owns it | What it answers | Failure mode |
|---|---|---|---|
| Shipped this week, with links | Us | What did the money buy | Activity listed with nothing live behind it |
| In flight, with a date | Us | What lands next | Dates that move without anybody saying so |
| Blocked, with the gate and owner | Us to report, them to clear | Why is this not moving | Softened until it reads as an excuse |
| Ask, with options and a recommendation | Them | What do you need from me | An agency decision the client can disown |
Why should an agency not make the strategic call?
Because we hold a fraction of the information. The client knows the board conversation, the pricing floor, the roadmap that slipped, the customer who threatened to leave. A recommendation that ignores any of those is confident and wrong, and we would not know which.
The second reason is less flattering. A decision made on a client’s behalf is one they can give back the moment it costs money. Putting the same call to them as an ask leaves it where the accountability sits.
How do you write an ask that does not decide for them?
Give the real options, say what each one costs and wins, name the one we would pick and why, and set a date after which the choice expires. That last part is what turns an ask into something with a consequence attached. Without it, an ask is a question, and a question can be left.
When a gate slips a launch, the question is not whether the gate matters. It is which date we plan against while it runs, and whether the release gets cut down to the parts the gate does not touch. Both of those are the client’s to answer, and we hold a view on each.
The recommendation goes in, as a recommendation and not as a plan already underway.
How should a blocker be reported?
In the update the week it appears, with the gate and the person holding it named.
Timing is most of what a blocker communicates. Reported the week it lands, a blocker is a fact somebody can work on. The same sentence a month later reads as an excuse.
Keep the rest of the week visible while it sits there. Work the blocker does not touch still ships, and the update still reports it.
A line saying the page is done and the same line with the URL beside it are different claims.
Where should the update live?
Somewhere the client opens without asking us first, showing their own work and nobody else’s. We run a portal per client for that, scoped per account, because nobody polices where a link goes once it has been sent. An emailed update is true on the day it is sent, and then it is buried in an inbox.
The document the team works from should be the document the client reads.
Related reading: naming every gate in week one and why decisions in a DM do not exist.
Frequently asked questions
What should be in a weekly client status update?
What shipped, with links. What is in flight and when it lands. What is blocked, with the gate and the person holding it. What the client is being asked to decide. And what happens by default if nobody answers. Anything beyond those five is padding.
Should an agency make strategic decisions for a client?
No. The agency holds a fraction of the information, because the board conversation and the roadmap that slipped both sit on the client's side of the table. Present the call as an ask with options and a recommendation, which leaves the decision where the accountability already is.
How do you present a recommendation without taking the decision?
Give the real options, what each costs and wins, the one you would choose and why, and a date after which the choice expires. The client hired you for a view, so the recommendation goes in, as a recommendation and not as a plan already underway.
How should an agency report a blocker to a client?
In the update the week it appears, naming the gate and its owner, without softening the language. Reported the week it lands, a blocker is information the client can act on. The same sentence a month later reads as an excuse.
How often should clients get a status update?
Weekly, on every account. A monthly update makes a wrong direction expensive to correct, because a month of work already sits behind it. Weekly keeps every correction small and makes the engagement legible between meetings.
Where should client updates be published?
Somewhere the client opens without asking, showing their own work and nothing else. An emailed update is true on the day it is sent and then rots in an inbox. A per-client portal keeps the current state of the engagement answerable at any point in the week.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
