Short answer: The hard part of a weekly status report is not the format, it is collection — getting accurate information without spending Friday chasing seven people. Solve that by deriving most of the report from work that already happened, asking each person exactly one question, writing it whether or not everyone replied, and keeping it short enough that someone reads it. The template matters least and comes last.
Why every status report guide misses the problem
Search for this and you will get templates. Dozens of them, all reasonable, all built on the same silent assumption: that you already have the information and merely need somewhere to put it.
You don't. That is the whole problem.
The real Friday looks like this. You open a document with five headings. You know roughly what two people did. You message the other five. Three reply within the hour, one replies Monday, one never does. You write something vague to cover the gap, send it, and the report is slightly false — and everyone senses it, which is why nobody reads next week's.
A template does not touch any of that. So this article spends its length on collection, and gives the format at the end, short.
Rule 1: derive, don't ask
Most of a status report already exists as a by-product of the work. Anything you can read, you should not be asking for.
- What shipped — closed items from the week. No question needed.
- What is in flight — items currently in progress, with how long they have been there.
- What slipped — dates that moved, and when they moved.
- Who was unavailable — leave and public holidays, which explain half the variance in any week and are almost never mentioned in reports.
The target is that 80% of the report writes itself and you only ask about the rest.
Rule 2: ask exactly one question
For what cannot be derived — judgement, risk, the thing not on the board — ask one question. Not a form, not five fields. One.
"Anything I'd be wrong about if I wrote the update from the board?"
This works because it is answerable in a sentence, it asks for the exception rather than a summary, and it respects that the person has already recorded the facts. Compare it with "please send me your weekly update by EOD Thursday", which asks someone to duplicate work they already did, in prose, on a deadline.
Ask it in the channel people already use. A question that requires opening a different tool has a lower answer rate, and the difference is not small.
Rule 3: write it whether or not everyone replied
This is the rule that removes the chasing, and it is uncomfortable for exactly one week.
Set a cut-off. Write the report from what you have. Where someone did not answer, write what the board says and attribute it plainly: "Design: three items in progress, no update received."
Nobody is being punished — this is simply accurate. But it reliably changes behaviour, because people who see their area described from stale data will correct it themselves next week. Chasing puts the cost of accuracy on you; publishing on time moves it to the person who owns the information.
Two guard rails: never use this to make someone look bad, and never let it become passive-aggressive. The tone is neutral bookkeeping, not scoreboard.
Rule 4: make it short enough to be read
An unread report is a weekly ritual that costs real time and returns nothing. Length is the main reason reports go unread.
Cut these, in this order:
- Everything already visible in the tool. If the recipient can see the board, do not transcribe it. Link it.
- Work in progress with no change since last week. "Still ongoing" is not information.
- Per-person activity lists. Managers care about outcomes and risks, not who touched what.
- Anything with no decision attached. If a line changes nothing for the reader, it is filler.
The format, since you came for one
Five blocks. Aim for one screen.
Shipped this week — three to five items, outcome not activity. In flight — what is moving, and what it is waiting on. Slipped — what moved, the new date, and the reason in one clause. Risks and decisions needed — the section the reader is actually here for. If a decision is needed, name who from and by when. Availability next week — leave, holidays, anyone at a conference. Put it in every report; it is the single most useful line and almost always missing.
Two things to notice. There is no "no updates" filler, and availability is a first-class block rather than an afterthought — because next week's plan is wrong without it.
What to do when the report still gets ignored
If you have done all four rules and nobody reads it, the problem is usually one of three things, and each has a different fix.
- Wrong audience. You are writing for "the team" rather than a specific reader. Pick one person whose decisions the report should inform, and write to them. Everyone else can read over their shoulder.
- Wrong rhythm. Weekly is a convention, not a law. Some work moves too slowly for it, in which case fortnightly is more honest than a weekly report padded with "ongoing".
- No consequence. If nothing ever changes as a result of the report, it is a diary. Make sure at least one line each week asks the reader for something — a decision, an approval, an unblock.
Where a tool helps
Rule 1 is the only one a tool can do for you, and it is the one that saves the most time. If the work — items, dates, and who is away — lives in one system, the derived four-fifths of the report is a view rather than an assembly job.
The rest is process. Rules 2, 3 and 4 are habits, and no purchase installs them.
Poitim keeps leave and public holidays alongside the work, which is what makes the availability block cheap to produce; it is the line most reports omit precisely because it usually lives in a different system.
Frequently asked questions
How do I get people to send status updates on time? Mostly by not needing them to. Derive what you can from the work itself, ask one narrow question about what you cannot, set a cut-off, and publish without the missing pieces. People who see their area described from stale data update it themselves the following week.
What should a weekly status report include? Five blocks: what shipped, what is in flight, what slipped and why, risks or decisions needed, and who is unavailable next week. The last is the most useful and the most frequently missing.
How long should a weekly status report be? One screen. If it is longer, the usual cause is transcribing what the reader can already see in the tool, or listing work that has not changed since last week.
Should status reports be weekly? Only if the work changes weekly. Slow-moving projects produce padded reports full of "still ongoing", which teaches readers to skip them. Fortnightly with real content beats weekly with filler.
What is the difference between a status report and a standup? A standup coordinates the next day among people doing the work. A status report informs someone not in the day-to-day — usually about risk and decisions. Writing one as if it were the other is why most reports are too detailed and still not useful.