Project status report template: weekly format, example — and how the report assembles itself from the recaps (2026)

A project status report is a short, fixed-format page that tells the people outside the daily work where the project stands: on track or not, what changed since the last report, what might go wrong, and what the reader is being asked to decide. It is written on a cadence — weekly for most projects — and it is the same page every time, so the reader compares this week with last week instead of reading from scratch.

This guide is the craft first — the format, a template you can copy, a filled-in example, a shorter weekly version for a team lead reporting upward — then the mechanics: when a report is enough and when a status meeting is still worth calling, where the report is written in the tools your team already uses, and what happens between the meetings and the page. Because the report's hardest part is not the writing. It is the half-hour before, when the lead goes back through a week of calls and chats to find out what was actually agreed.

What a project status report is — and what it isn't

Four documents orbit a project, and the report is the one most often confused with the others:

The recap is per meeting; the report is per week across all of them. A stand-up surfaces blockers to the people who can clear them; the report tells someone further away whether those blockers are threatening the date. The decision log keeps the why; the report only says that a decision was taken or is still needed. If the report is hard to write, the cause is almost always upstream: the week's meetings left no record of their outcomes, so the lead is reconstructing them from memory on Friday afternoon.

The weekly format: six blocks, one page

A report that is read every week has to fit one screen and keep the same shape. Six blocks, in this order:

1. Header. Project, reporting period, author, the date of the next report. Readers scan for the period first — a report without one is a page of claims with no "since when".
2. Overall status in one line. Green, amber or red — or on track, at risk, off track — plus one sentence that says why. The colour is a summary of the blocks below, not a feeling; if the risks block says a supplier slipped two weeks, the line cannot say green.
3. Progress since the last report. Three to six lines of what was finished, each as an outcome rather than an activity. "Checkout flow in review with the client" is a fact; "worked on checkout" is not.
4. Next period. What the team commits to finishing before the next report, each with an owner. This block is what next week's progress block will be checked against.
5. Risks, issues and decisions needed. A risk is something that might happen; an issue is something that has. Each line: what, its effect on date or budget, the owner, and what the reader is asked to do — including "nothing, for information". Decisions needed get their own line with the date by which the project needs the answer.
6. Open actions. Every action still open from any meeting this period, with owner and due date, and a mark on the ones that are overdue. This is the block most reports drop, and the one the reader uses to judge whether the colour in block 2 is honest.

Three things to leave out: dialogue (who said what), activity logs (hours, calls held), and anything the reader could not act on. The report is for someone who will spend four minutes on it. Every line should survive the question "what would the reader do differently knowing this?"

Project status report template

Copy this into a document, a channel message or a canvas. Square brackets are placeholders.

[Project] — status report for [period, e.g. 20–24 October]
Author: [name] · Sent: [date] · Next report: [date]
Overall: [on track / at risk / off track] — [one sentence that says why]

Done since last report
– [Outcome, as a fact] — [owner]
– [Outcome] — [owner]
– [Outcome] — [owner]

Next period (by [next report date])
– [Deliverable] — [owner]
– [Deliverable] — [owner]

Risks and issues
– [Risk or issue] — effect: [date / budget / scope] — owner: [name] — ask: [decision needed by date / for information]

Decisions needed
– [Question, with the options on the table] — needed by [date] — from [name]

Open actions
– [Task] — [owner] — due [date] — [open / overdue since date]
– [Task] — [owner] — due [date] — [open]

The order is deliberate. A sponsor who reads only the first three lines gets the colour and the reason; one who reads to the end gets the actions that explain the colour. Keep the headings identical from week to week — the value of the format is the comparison.

Example: a filled-in weekly status report

A small software project, two-language team, a client who reads the report every Monday:

Order portal v2 — status report for 20–24 October
Author: Mateusz · Sent: 24 October · Next report: 31 October
Overall: at risk — payment-provider sandbox arrived four days late; launch date holds only if the integration test passes by 29 October.

Done since last report
– Checkout flow in review with the client; two comments open — Ana
– Product import from the ERP runs nightly in staging — Priya
– Spanish and Romanian UI strings complete; French at 80% — Luca

Next period (by 31 October)
– Payment integration test on the provider's sandbox — Priya
– Client sign-off on checkout — Ana
– French strings complete, all three languages reviewed — Luca

Risks and issues
– Payment sandbox delay (issue) — effect: launch 7 November holds only if the test passes by 29 October; otherwise 14 November — owner: Priya — ask: for information, decision below
– Client review turnaround (risk) — effect: each round takes 3 days; a third round moves sign-off past the test window — owner: Ana — ask: client to batch comments in one round

Decisions needed
– If the test fails on 29 October: launch 14 November with payments, or 7 November with invoice-only payment and card payments added later — needed by 30 October — from the client

Open actions
– Send the provider the IP allow-list — Priya — due 21 October — overdue since 21 October
– Confirm go-live window with the hosting partner — Mateusz — due 28 October — open
– Reply to the two checkout comments — Ana — due 27 October — open

Notice what the example does not say: how many meetings were held, who spoke, how many hours went in. The reader learns in one line that the date is at risk and in one block what they are asked to decide.

Weekly report template for a team lead

A team lead's weekly report to their own manager is a shorter cousin of the project report. The reader is one person, usually with less than two minutes, and the questions are three: is the team on its commitments, what is in the way, and what do you need from me. Four blocks fit in a chat message:

Team [name] — week of [date]
Status: [on track / at risk] — [one line]
Shipped: [two or three outcomes, each with a name]
In the way: [one or two blockers, each with who can clear it]
Needed from you: [one decision or resource, with a date] — or "nothing this week"

Two rules that make it readable over months. First, "Needed from you" is never empty by accident: write "nothing this week" so the manager knows the silence is deliberate. Second, "Shipped" lists people's names — a weekly report is also where a lead makes the team's work visible to someone who does not see it daily. If the team already keeps a daily stand-up with named blockers, "In the way" is a copy of the ones still standing on Friday.

The weekly report replaces the weekly status meeting for most of what the meeting carried — the information. What it cannot replace is covered next.

When a status meeting is still needed

A status meeting is the live form of the report: each person tells the lead or the sponsor where things stand, in a room, at everyone's cost. Once a written report exists, the meeting is justified only when the page cannot do the job. Four cases:

• A decision with a trade-off. The report can state the options; it cannot negotiate them. When "Decisions needed" has an entry whose answer depends on what two stakeholders are willing to give up, thirty minutes with both in the room beats two weeks of reply-all.
• A date is moving. A slip is rarely accepted from a page. The conversation about what moves with it — scope, budget, another project's start — is a meeting, with the report as its pre-read.
• A risk crossed its threshold. The week a risk becomes an issue, the people who own the consequence need to hear it from the lead and ask questions, not read it on Monday.
• A new stakeholder. Someone who has not read the previous six reports needs one session to get the shape of the project; after that, the page is enough.

What a status meeting is not for is reading the report aloud. If every item on the agenda is "update from X", cancel it and send the page; the meeting cadence guide covers which recurring meetings earn their slot. When the meeting is held, run it off the report — the risks and decisions blocks are the agenda, and an effective meeting ends with those items marked decided, open or deferred. With stakeholders who speak different languages, the room has three options for the meeting itself: a human interpreter — the Zoom interpreter guide shows how that is set up — the platform's own captions, or a space that translates for each participant; the report, written once, is a separate question.

Where the report is written in the tools you already use

Each major platform leaves something after a meeting that a status report can be built from, and each stops at a different point. Documented behaviour only, from the vendors' own pages, with the month each page was checked:

Two things are the same everywhere. What a meeting leaves behind is one document per meeting, in the one language the room used; and whether last week's next steps were done is not something the document knows — the lead goes and checks before writing "done". The live-captioning side of the platforms — what Teams and Google Meet show on screen during a call — does not change the document afterwards. Notetakers are the same category one step further: the ones compared in Otter.ai alternatives write a summary per meeting, and a report that spans a month of meetings is still a separate page.

How the report assembles itself from the recaps

InterMIND is a communication space where a project lives in a channel, so the report's raw material has an obvious home. Every meeting in the channel ends with a recap — a summary, the decisions, the action items with owners and dates — written from the meeting itself and delivered by email, as a message in the channel and as a link in the calendar event. Every signed-in member reads it in their own language: the record is translated per reader, not written once in the language the room happened to use, and the same goes for the channel's chat around it, typed by each member in their own language. Any member can edit the recap, every edit keeps author and revision history, and the channel keeps the recap of every past session — so "done since last report" is a scroll through the week's recaps rather than a reconstruction.

The action items carry their status with them. An item shows as to do, done, or not done with a reason, and in an organization with team status pages on, the open items of earlier sessions are judged when the next recap is written: an item someone reported finished is marked done, an item discussed but not finished is marked not done with the reason in the words of the meeting, an item nobody brought up stays open. That is the "open actions" block of the template, kept by the meetings instead of the lead.

Team status pages are where the rest of the report comes from. One page over the last 7, 28 or 90 days lists the organization's tasks, problems, what is important and urgent, and the money at stake, and every row carries the verbatim quote from the recap it rests on; a task stays until someone closes it, and after four weeks without movement it is marked stalled. The lead writes the trend line and the colour — the judgement — over a page the meetings already filled in. The same page is readable through a connected assistant: a lead who works in Claude, ChatGPT, Copilot or Gemini asks for the week's open tasks and problems and gets the rows with their quotes. Team status pages are a preview feature on paid plans: an organization's admin switches them on under Settings → Advanced after accepting the alpha terms (the Preview features page describes each one).

Where the report has to land in a system of record, the host adds a recap copy to any address — a CRM or project tracker's inbound mailbox — and every recap of the meeting or channel is also sent there after a one-time confirmation of the address; the mechanics are in a copy of every meeting recap in your CRM, by email, and the same recap arrives as a webhook or a Zapier trigger for teams that post it into a tracker themselves.

A client stakeholder who should see the recaps is invited to the channel by email and joins on a free account, reading in their own language; outside participants in a channel cost the host nothing. A guest of one meeting joins by link, without an account and at no cost — from a phone, in the browser — and hears the meeting live in their own language. There is no record for a guest afterwards — the account is free, and it is what makes the record reachable. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days; members who go quiet keep their access at no cost.

• Open a complete recap — a real record rendered by the same code that writes yours.
• Try the live demo — no signup; speak, and hear the room translated per listener.

The report as a craft survives every tool: someone still has to say whether the project is on track and why. What does not have to survive is the Friday half-hour — going back through a week of calls, in one language, to find out what was agreed and whether anyone did it.

FAQ

What is a project status report?

A short, fixed-format page sent on a cadence — usually weekly — that tells people outside the daily work where a project stands: an overall status in one line with the reason, what was finished since the last report, what is planned before the next one, the risks and issues with their effect on the date or budget, the decisions the reader is asked to make, and the actions still open with owners and due dates. It is the same page every time so the reader compares weeks rather than reading from scratch.

What should a weekly status report include?

Six blocks: a header with the reporting period; one line of overall status with the reason; progress since the last report as outcomes, not activities; the commitments for the next period with owners; risks, issues and decisions needed, each with its effect and an ask; and every open action with owner and due date, overdue ones marked. Leave out dialogue, hours and anything the reader cannot act on.

How do you write a project status report?

Start from the previous report: its "next period" block is this week's checklist, and its open actions are either done or still open. Then go through the week's meeting recaps for what was decided and what was added. Write the status line last, after the risks block, so the colour matches the facts. Send it the same day each week, to the same list, and keep the headings identical from one report to the next.

What is the difference between a status report and a status meeting?

A status report is written and read asynchronously; a status meeting is the same information delivered live, at the cost of everyone's time in the room. Once a report exists, a meeting is justified when the page cannot do the job: a decision with a trade-off between stakeholders, a date that is moving, a risk that has just become an issue, or a new stakeholder who needs the shape of the project once. A meeting whose agenda is "update from each person" is a report read aloud.

Is a weekly report template for a team lead different from a project status report?

Shorter and addressed to one person. A team lead's weekly report to their manager answers three questions in four blocks — status in one line, what the team shipped with names, what is in the way and who can clear it, and what is needed from the manager by when — and fits in a chat message. A project status report is longer, spans a period and a set of stakeholders, and carries risks, decisions and open actions across every meeting of the project.

How often should a project status report be sent?

Weekly for most projects: often enough that a slip is caught within a week, rare enough that each report has something new. Fortnightly suits long, steady projects with few decisions; daily reporting belongs to a launch week or an incident, and is a different, shorter document. Whatever the cadence, the day and the recipient list should not change — a report that arrives on a different day each week is not read as a series.

Should the client receive the status report?

Yes, if the client is paying for the project and a decision in the report is theirs to make — the "decisions needed" block is written for them. Write one report for everyone where possible, rather than a client version and an internal one; a report with two versions drifts, and the internal one becomes the real one. What stays out of a shared report is the team's internal detail — individual performance, estimates under negotiation — which belongs in the lead's own notes.

Sources: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" suggests next steps; Slack — Meeting agenda template (canvas). Microsoft notes, Google Meet notes and Slack pages checked October 2026; the Google next-steps announcement checked September 2026; the Microsoft recap and Zoom meeting-summary pages checked August 2026. Vendors change plans, features and language lists over time; check their pages for the current state.