How to write a client status report for a small agency
Most client status reports fail for the same reason: they are written to document everything that happened instead of to tell the client what they need to know. On a small team, you do not have time to write a report nobody reads, and your client does not have time to read one that buries the one thing they need to decide.
A good status report is short, consistent, and built around decisions and risk, not a task-by-task recap of the week.
Why small agencies get this wrong
Larger firms often have someone whose job is reporting. On a small team, the same person running the project is also writing the update, usually at the end of a long day. The easy failure mode is to either skip it, or to paste in a long list of completed tasks because that is what is easiest to generate.
Neither builds trust. A client who gets no report assumes nothing is happening. A client who gets a wall of task names has to do the work of figuring out what matters themselves, and most won't.
What to put in it
Keep the whole thing to something a client can read in under two minutes.
- Header. Client name, project name, reporting period, and the date.
- Overall status. One word or phrase: on track, at risk, or off track. Say it before anything else.
- Summary. Two or three sentences on where the project stands right now.
- What moved since last time. Outcomes, not activity. "Homepage design approved" tells a client something; "12 tickets closed" does not.
- What's next. What will be true by the next update.
- Risks or issues. Named, not vague. Who owns watching each one.
- Decisions needed from the client. The single most important section, and the one most reports leave out.
Lead with the status, not the summary
Put the health rating first, above the fold, every time. A client scanning their inbox should know in two seconds whether this project needs their attention this week. If you bury "at risk" in paragraph three, you have written a report that protects you on paper but doesn't actually warn anyone.
Be honest with the rating. A project that is secretly behind but reported as "on track" for three weeks running does far more damage when the truth comes out than one status report that says "at risk" a little early.
Report outcomes, not hours
A status report is not a timesheet. Clients generally don't care how many hours were logged or how many tickets moved columns; they care whether the things they're paying for are getting closer to done. Translate activity into outcomes before it goes in the report: not "worked on the checkout flow" but "checkout flow is built and in client review."
If you can't translate a week's work into an outcome, that's worth noticing. It may mean the work itself needs to be broken into smaller, more visible pieces.
Make the client's side of the work visible
Most project delays on small teams are not the agency working slowly. They are an approval sitting in someone's inbox, or an asset the client said they'd send three weeks ago. Naming that, every single update, is one of the most effective things a status report can do.
Put it under "Decisions needed," with an owner and a date it's needed by. A client who sees "waiting on your sign-off since Oct 12" in writing, every week, closes that loop faster than one who gets a vague check-in call.
Keep the format identical every time
Use the same structure every single update, even when a week is quiet. A consistent format means a client can scan it in seconds because they already know where to look for the status, the risks, and what's needed from them. Changing the layout, or skipping sections when there's "nothing to report," trains clients to stop reading closely, which defeats the purpose.
A quiet week is still worth a short report: "No change in status, team is heads-down on X, nothing needed from you" takes thirty seconds to write and keeps the rhythm intact.
Pick a cadence you can actually sustain
Weekly is the common default for active client work, but match it to the project's pace. A fast-moving two-week sprint of client work might need something closer to twice a week; a slower, quarter-long engagement might only need biweekly updates. The wrong cadence is whichever one you quietly stop doing after a month because it takes too long to write.
If writing the report is taking real time every week, that's a signal the underlying project tracking isn't giving you a clean summary to pull from, not that reporting itself is the problem.
Tailor it to who's reading
An internal team update and a client-facing report are different documents, even if they draw from the same source. Internally, you can be blunt about a subcontractor who's behind schedule. Externally, that same fact needs to be reframed around the project, not the person. Keep separate versions rather than trying to write one report that serves both audiences.
Keep the source of truth separate from the report
The report should summarize work that's already tracked somewhere, not be the place you're deciding what happened for the first time. If your week's actual status lives only in your head or an email thread, writing the report becomes guesswork. Full disclosure, I'm the founder of ConfidantPM, and this is part of why its Gantt charts and Evaluate Project feature exist: they give you one place to see what's actually on track before you summarize it for a client, rather than reconstructing the week from memory.
A quick checklist
Before you send a status report, check that it has:
- The overall status, stated plainly, near the top.
- Outcomes from the last period, not a list of hours or tickets.
- What's expected to be true by the next update.
- Named risks, each with an owner.
- A clear list of what you need from the client, and by when.
If all five are there, the report is doing its job even if it's three sentences long.
Project management that actually knows your project.
ConfidantPM's assistant reads your project documents, asks one question at a time, and never acts without your sign-off. Free to start.