Standup notes are evidence, not the report
A standup answers today. A status report answers one reporting period. The project status report tool wants a period, an overall status, a short summary, completed work, next work, milestones, and only the risks that need a decision now. It does not want five days of “yesterday, today, blocker” pasted into Executive summary.
Start from the standup minutes you already wrote, not from a memory of the chat. If those notes are still in the meeting minutes tool, keep that draft open or export it. Do not import a minutes JSON file into the status tool. JSON import accepts a backup of the same tool only, and a file of the wrong kind is refused.
Fictional week for this guide: Northstar customer portal, period ending 9 October 2026. Alex facilitates. Sam Lee owns payments. Jordan Taylor owns support readiness. Four standups exist. Only a few facts change the status colour. The rest of the week can stay in the daily notes.
If you do not have written standups, do not invent a week of notes in order to fill the report. Write the status from the evidence you can point to, and say what you did not review.
Sort each line before you type
Before you open the status tool, sort each standup line into one bucket. Completed this period gets a result that already happened inside the period. Next period gets work that is still ahead. Risks and decisions gets a blocker that needs a named response in this period. Everything else stays in the standup note.
- Read each standup once and mark blockers that lasted more than one day.
- Collapse repeats. “Sandbox still down” on Monday, Tuesday and Wednesday is one issue, not three rows.
- Keep the earliest date you noticed it and the latest review date anyone actually agreed.
- Drop activity that does not move the next milestone. Opening a laptop or joining the call never enters the report.
- If a standup recorded a real decision, copy the decision, not the discussion that led to it.
The tool’s risk columns are Risk or issue, Owner, Response / decision needed, and Review date. There is no column for the speaker list. Owner is the person who can move the item, even if someone else mentioned it in the standup. Dates you paste later must be YYYY-MM-DD. The draft and paste guide covers the header tick and the 50-row cap.
A line can belong to only one bucket. If you cannot tell whether “testing” is finished or still blocked, it is not ready for the summary. Ask the owner before you colour the period.
Fill the status tool in one pass
- Open the status report tool. If a fictional example is loaded, choose Start blank. The example banner must not ship to a real audience.
- In Basics, set Project name and a Reporting period that matches the evidence, such as “Week ending 9 October 2026”. Prepared by is the person sending the report, not “the team”.
- Choose Overall status as your judgement. If the launch date depends on tests that have not started, At risk is more honest than On track. The tool does not calculate the colour from the rows.
- Executive summary is two or three sentences: what changed, what is blocked, and the decision you need. Do not list every attendee.
- Completed this period holds finishes only. “Sign-in flow passed review” belongs here. “Started looking at payments” does not, because nobody can tell whether it finished.
- Next period names the next check, with a finish line a reader can recognise next week.
- Milestones: one row for the next gate. Planned date is the date you promised. Forecast date is the date the evidence now supports. Status is a word the team already uses.
- On Risks and decisions, use Add row only for items that need a decision in this period. If you paste, the order is Risk or issue, Owner, Response / decision needed, Review date. Preview the rows before you add them. A refusal adds nothing.
- Choose Review & export. The checks flag empty details. They do not confirm that an owner agreed. Download Word or Excel, or use Print / save PDF and choose Save as PDF in the browser dialog. That control does not download a PDF by itself.
Save on this device if you will reopen the same report in this browser. Download a JSON backup if the file has to move to another machine. The draft is not a hosted copy, and clearing site data removes it.
Fictional Northstar lift
What the standups said
Monday: Sam says the payment sandbox is down and six cases have not started. Jordan cannot finish training slides until those results exist. Alex names 16 October as the launch milestone.
Thursday: the sandbox is still down. Nobody makes a new decision. Jordan repeats the same blocker.
Friday report: Executive summary — “The sign-in flow passed review. Six payment tests remain blocked while the sandbox account is restored. The 16 October launch is at risk until those results exist.”
Completed this period keeps the sign-in review. Next period says “Restore sandbox access, rerun the six cases, and recheck the launch date.” The single risk row states the effect: payment sandbox unavailable, six cases have not started, so the launch cannot be confirmed. Owner Sam Lee. Response: restore the sandbox or confirm a fallback by 12 October. Review date 2026-10-12.
Jordan’s training delay is not a second risk row unless someone must decide about training this week. It is a consequence of Sam’s row. Mention it in the summary only if a reader would otherwise book the training as if the product were ready.
The longer record, including a stable ID and a Type, stays in the risk and issue log. The status tool will not store I-01, and it will not update the log when you export.
Common mistakes, and the correction
What goes wrong
Mistake: Pasting all four standup notes into Executive summary.
Correction: The summary is the change and the decision. Daily texture stays in the minutes. A reader who wanted the diary already has it.
Mistake: A new risk row every day for the same sandbox.
Correction: One row for the period. Update the response if the ask changed. Thursday is not a new outage.
Mistake: Overall status On track because most people spoke.
Correction: Tie the colour to the milestone. If the launch date is not supported by evidence, the colour is not On track, even when the standup felt calm.
Mistake: Owner set to “standup” or “the team”.
Correction: One person who can act. If nobody agreed, say that in the response and do not invent a name.
Mistake: Importing the minutes JSON into the status tool.
Correction: The import refuses a file of the wrong kind. Copy the meaning by hand. A refused import adds no rows.
These are writing habits. The tool will not stop you from pasting a diary into the summary. It will only give you fields that make the shorter version easier to keep.
What this path will not do
- It will not merge five standup files into one report. You choose which sentences survive.
- It will not read Slack, a calendar or a meeting bot, and it will not record the standup for you.
- It will not keep standup history inside the status draft. There is one draft per tool, in this browser. Download JSON if you need the report elsewhere.
- It will not sync with the issue log or the action tracker. Copying is manual, and updating one file does not update the others.
- It will not accept more than 50 rows in a table, 2,000 characters in a main field, or 600 in a cell. An oversized value is rejected, not silently cut.
- It will not prove the status colour. You still have to point at a milestone or an open test.
Fictional close: Alex sends the Friday report, keeps Monday’s minutes as the daily record, and leaves the issue-log row open until the sandbox result exists. The standup notes did their job when the status report became shorter than the week. The status report guide covers the narrative in more detail if the period is not coming from standups.
Put it into practice.
Open a blank status report and copy only the lines that change the period. Leave the daily notes in meeting minutes.
Open the project status report tool →