Project Status Report: How To Write One Your Client Actually Reads

It is Friday afternoon and you are writing the fourth status report of the day. The first one took twenty minutes because you had to go back through Slack to remember what actually happened. The others were faster because you copied the structure and changed the names. None of them will get a reply. On Monday a client will ask you something that was answered in the report you sent on Friday, and you will have to answer it again.

A project status report is a short, fixed update that tells a client what moved in the last period, what is stuck, and what you need from them before the next one. That is the whole job. Every guide you will find agrees on roughly the same six sections, and the sections are fine. The part nobody writes about is that most status reports are never read, and writing them anyway is one of the quieter time sinks in agency work.

What goes in a project status report?

Six things, and nothing else: the reporting period and who owns the project, what was finished, what is next, what is at risk with what you plan to do about it, where you stand against budget and scope, and the decisions you need from the client with a date attached.

That last one is the only part that earns a reply. A report that is purely descriptive gives the reader nothing to do, so they skim it and close it. A report with one clear question in it, with a deadline, gets answered.

A few things worth keeping out:

• Internal detail. Which of your people did what is your business, not the client's. It reads as padding.
• Colour codes without a sentence. Amber means nothing on its own. Amber because the content approval has been sitting with Bep for nine days means something.
• Hours spent. Unless you bill by the hour and the client expects it, a time breakdown invites a conversation about effort rather than outcome.

If you want a project status report template, take those six headings, put them in a document, and never change the order. The consistency is doing more work than the format. A client who knows the risk section is always third will find it in two seconds, and that is the only reason they will keep opening it.

How often should you send a status report?

Weekly for active project work, monthly for retainers, and never on a schedule nobody asked for.

Weekly is right for a project in delivery. For a retainer where the same work runs every month, it creates four documents saying the same thing, which trains the client to ignore all of them. Ask at the start which rhythm they want. Some will say they only want to hear from you when something changes, which is an honest answer and you should take it.

Does anyone actually read it?

Often not, and you can find out in a week. Put a real question in the next report, something you genuinely need an answer to, and see whether you get one.

If you do not, you have learned something useful rather than something depressing. It means the report is functioning as a record and not as communication, and those are two different jobs. A record is still worth having. When a project goes sideways in month four and someone asks why the launch slipped, a dated trail of status reports is the difference between a discussion and an argument. I wrote about how that plays out in scope creep in client projects.

What it also means is that you should stop expecting the report to replace the conversation. Fifteen minutes on a call does more than two pages of prose, and the report then becomes the written confirmation of what you already said.

How do you report bad news?

By making sure the report is not where the client finds out. Call first, write it down second.

This is the rule I would defend hardest. A delay, a budget overrun or a mistake on your side should reach the client by phone or in a meeting, in your own words, with what you are doing about it. The status report then records it calmly, in one line, with a new date. Clients forgive problems. They do not forgive discovering a problem in paragraph four of a document you sent on a Friday afternoon.

The version of this that goes wrong is softening the language until the report no longer says anything. "Some delays in approval flow" is not a status. "The homepage copy is two weeks late because we are waiting on your legal review, which moves launch to 12 October unless we get it by Friday" is a status. The second one is uncomfortable to write and it is the one that works.

What does reporting cost when you run eight clients?

More than you think, and this is the part the template articles skip entirely.

Say a report takes forty minutes once you have gathered the information, chased the two people who know what happened, and written it in a way you are willing to send. Eight clients, weekly, is over five hours a week. That is most of a working day spent describing work rather than doing it, and it is why reporting is the first thing to slip when things get busy, right when clients most want to hear from you.

The honest fix is not writing faster. It is making sure the information is already somewhere before you sit down. If tasks, deadlines and client decisions live in one place per client, the report becomes an assembly job instead of an archaeology job. That is the thinking behind keeping an overview of multiple clients and behind our reporting and client portal features, where the client can see project status without waiting for a document.

Being straight about the limits: Wecooking has no time tracking and no invoicing, so if your status report needs a budget-burn line pulled from logged hours, you will still be assembling that part by hand or from another system. For ad performance reporting specifically, automating client reports covers what can genuinely be handed off and what cannot.

If reporting is eating your Fridays, you can try Wecooking for free and see whether having projects, tasks and client communication in one view shortens it. From 19 euros per month, everything included, and currently free in beta.