Template · 10 min read
Project status report template: a status update clients actually trust
Every project sends status reports, and almost nobody reads them — because most of them are progress theater: a list of activity, a wall of green, and the real problems saved for a panicked call three weeks later. This template inverts that. It opens with a verdict, treats red as a request for help rather than a confession, and goes out on one permanent link per project that the client bookmarks. The full structure is below with the reasoning, plus a prompt that makes AI assemble the report from your week's raw facts.
What a status report is actually for
The client can't see the work. That's the whole problem a status report exists to solve. Between meetings, everything you're doing is invisible to the person paying for it, and into that silence they project whatever their last vendor did to them. A status report is trust maintenance — a regular, honest signal that someone competent has their hands on the wheel.
That's why the failure mode isn't "too little detail" — it's spin. A report that's green for six weeks and then suddenly red teaches the client one permanent lesson: the reports are decoration, the truth arrives by phone. From then on they micromanage, because your reporting gave them no alternative. The counterintuitive rule of status reporting is that a well-explained amber builds more trust than a wall of green, because it proves the report says something.
The other thing worth being honest about: the status report is not the project plan, the ticket board, or the timesheet. Clients who want raw detail can have a dashboard link in the appendix. The report itself is a judgment — where we are versus where we promised to be — written for someone with ninety seconds.
The template, section by section
Six sections. The reader should be able to stop after the first sentence and still know the truth.
- Status verdict. One sentence carrying the color and the reason: "Amber: the API migration slipped four days, the launch date holds if we get sign-off by Thursday." Not a paragraph, not a mood — a verdict. If the color and the sentence disagree, the sentence wins and the color is wrong.
- Milestones vs. plan. Each milestone with its planned date, its currently expected date, and its state. Slippage shown, not hidden — a date that moved and is explained reads as control; a date that silently changed reads as chaos when it's discovered, and it's always discovered.
- Risks and issues, each with an owner. A risk without an owner and a next step is an excuse being pre-positioned. Three lines each: what might happen, what it would cost, what's being done and by whom. Retire risks visibly when they die — it shows the list is real.
- Decisions needed. The section clients actually act on, so it gets its own heading rather than being buried in prose. What you need, from whom, by when, and what it blocks. If this section says "none" every week, you're probably absorbing decisions the client should be making.
- Next period. Three to five bullets of what happens next, specific enough to be checkable against next week's report. This is the sentence-level promise that makes the report a chain rather than a snapshot.
- Appendix. Burn vs. budget if money is in scope, links to the board or dashboard, detail for the reader who digs. Present, separated, optional.
One structural rule across all six: identical structure every period. The value of a status report compounds only when weeks are comparable — same sections, same metric definitions, same milestone names. The reader should be able to hold last week's report next to this one and see exactly what changed.
Red means "help", not "guilty" — the RAG rules
RAG status only works under two rules, and most orgs break both:
Rule one: red is a request, not a confession. Red means "the plan fails without a decision or a change I can't make alone." That's information the client is paying for. Teams sandbag to amber because red feels like an admission of failure — and so leadership learns about the real state of the project from the invoice dispute instead of the report. If your client punishes honest reds, that's worth a direct conversation, because the alternative is a reporting ritual that reports nothing.
Rule two: no naked ambers. Every amber and red carries a countermeasure or an ask in the same breath. "At risk" alone is anxiety transfer; "at risk, and here's the move" is management. This single rule is what separates a report that reads as competence from one that reads as a pre-written alibi.
And the classic failure the rules exist to prevent: the watermelon report — green on the outside, red on the inside. It's almost never a lie at first; it's optimism compounding weekly until the truth is unaffordable. The template's verdict-first structure is the antidote: you have to write the sentence, and the sentence has to survive contact with the milestone table directly below it.
Deliver it as one permanent link per project
re-publish ↻ the bookmark never changes
- Fri 16:05
Week 34 report published
- Fri 16:40
Client opened · 2m 10s
- Mon 08:15
Opened again — the decision section, before standup
- Mon 09:00
Walk in knowing they read it
Each project gets one URL for its entire life. Every period's report replaces the last at the same address — the client bookmarks it once, and "can you resend the latest status?" stops being a sentence anyone types. Six months in, the link is the project's paper trail: when someone asks what was flagged in week 33, the answer is a URL, not an inbox excavation.
The read signal is the quiet second half. A tracked link shows whether the report was opened before your Monday call — so you know whether to open with discussion or with a ninety-second recap, without asking "did you get a chance to look at it?" And the pattern where a client stops opening reports is worth noticing early: disengagement precedes most difficult conversations by weeks. The honest limits apply as always — an open is an open, not an identified reader, and a forwarded link or a mail scanner counts too. Treat it as a prompt, not proof. Password the page when the report carries commercially sensitive numbers.
Build the report with AI (prompt included)
The facts of your week already exist — in the board, the standup notes, your head. What eats the hour is assembly. Hand an AI the structure and the raw facts and it produces the formatted report in one pass; you check the verdict is honest, fix what's off, and publish. The prompt encodes the rules that matter: verdict first, no naked ambers, never invent a date.
Copy, fill in the brackets with this period's real facts, paste into Claude or ChatGPT:
You are producing a project status report as a single, self-contained HTML file. CONTEXT — replace everything in brackets: - Project: [project name] - Client / stakeholder: [who this report is for] - Reporting period: [e.g. week of ...] - Prepared by: [your name / company] - Overall status: [green / amber / red] because [one honest sentence] - Milestones, each with planned date, current date, and state: [milestone — planned — now expected — done / on track / slipped, one per line] - Risks and issues, each with an owner and next step: [risk — impact if it lands — owner — next step, one per line] - Decisions I need from the client: [list, or "none this period"] - What happens next period: [3-5 bullets] - Budget / burn if relevant: [spent vs budget, or omit] REQUIREMENTS: - Open with the status verdict as one sentence — the color AND the reason — before anything else. Render the RAG state as a clear colored badge. - Then: milestones vs. plan as a table with slippage visible, risks with owners, decisions needed (make this section impossible to miss), next period, appendix. - Keep every date and number exactly as I gave it. If something is missing, leave a clearly marked [TBD] — never invent data. - Amber and red items must each carry a countermeasure or an ask — a warning without a next step is not allowed. - Self-contained HTML: inline CSS, no external scripts, readable on a phone, printable. Stamp "Status as of [date]" under the title. - Tone: direct and unspun. No hedging language around the verdict.
- 1 Paste the prompt (with your details filled in) into Claude or ChatGPT. You get a finished, self-contained HTML document — review it, correct anything, iterate until it's right.
- 2 Publish it as a permanent tracked link: with the Pagelive connector in Claude, say "publish this page" and the link comes back in chat — next cycle, "update it" replaces the content at the same URL. Or paste the HTML at app.pagelive.io.
Review the verdict line yourself every single time. The one thing you cannot delegate to AI is the judgment call between green and amber — the model will faithfully format whatever optimism you feed it, and the watermelon report is a human failure the tool happily automates. The structure keeps you honest only if the inputs are.
What to build it in
Project-management tools (Jira, Asana, Monday and peers) can generate status views straight from the board. Genuinely useful internally — but exporting the raw board to a client outsources the judgment to them, and client-facing access to your PM tool tends to mean logins, seat questions, and the client reading ticket comments you didn't write for them.
Email and docs are where most status reports live, and the failure is structural: every week mints another attachment, the thread buries the history, and you never know what was read. Fine for a three-week engagement; corrosive over a year.
An HTML report at a permanent tracked link is the pattern above, and the AI workflow makes it cheaper than formatting a doc. Pagelive is built for it: publish the report as a private page, password it if the numbers are sensitive, re-publish each period to the same URL, and see whether it was read before the call. The honest limits: no connectors — you bring the facts each period — and the page shows the state as of your last publish, not live board data. If the client needs a real-time board, give them the dashboard link in the appendix; the report and the dashboard do different jobs.
Frequently asked
Six things, in order: a one-line status verdict (on track, at risk, or off track — and why in the same sentence); milestones against the plan with dates; risks and issues, each with an owner and a next step; decisions you need from the client; what happens next period; and a short appendix for detail. Budget or burn goes in when money is part of what you're accountable for.
Start with the verdict, not the background. Write the one sentence that answers 'are we on track?' first, then let every other section justify or qualify it. Keep it to one screen for the reader who skims and an appendix for the reader who digs. The fastest honest method: keep the same structure every period and change only the facts.
RAG stands for red, amber, green — a traffic-light verdict on the project. Green means on plan. Amber means there's a threat to the plan that has a countermeasure. Red means the plan fails without a decision or change — it's a request for help, not an admission of guilt. The system only works if red is safe to use.
Match the cadence to how fast the project changes: weekly is the default for active delivery work, fortnightly for slower infrastructure or retainer projects. More important than frequency is regularity — a report that lands every Friday builds trust; one that appears when things are going well and vanishes when they aren't destroys it.
A progress report says what got done — it looks backward at activity. A status report renders a judgment against the plan — it compares where you are to where you promised to be, and flags what threatens the gap. Clients need the second one. Most templates produce the first.
Related: weekly report template · QBR template · the always-live client report
One status link per project. Updated every week, read before every call.
Build the report with AI, publish it as a permanent tracked link, and know it was read before the Monday call. Free for 5 pages, no card.