You know the ritual. Friday afternoon. Someone pings the PMO channel asking where the weekly status report is. You open last week's doc, copy it, change the dates, and then spend forty minutes hunting down what actually shipped, what slipped, and which owners are about to miss a date. By the time you hit send, half of it is already stale.
This post is a weekly project status report template built for that exact workflow — except instead of a static doc that decays, it lives on a Zoobbe page linked to the board it reports on. When cards move, due dates change, or owners flip, the page reflects reality. You write the narrative once. The board carries the facts.
It's written for PMOs and engineering managers running multiple workstreams who are tired of being a human cron job for status updates.
Key takeaways
- A good weekly status report answers four questions: what shipped, what's at risk, what's next, and where do I need a decision.
- Static docs decay the moment you save them. A status page linked to a Zoobbe board pulls from the source of truth instead of duplicating it.
- The template below has six sections: header, highlights, risks, next week, decisions needed, and metrics. Each one maps to a board view.
- Automations handle the boring half: cards moving into a "This Week" list, due-date reminders, and a Friday digest. You write the qualitative parts.
- The point isn't a prettier report. It's reclaiming the two hours every Friday you currently spend reconciling cards with prose.
Why most status report templates fail
If you've worked in a PMO for more than six months, you've probably inherited a status report template that looks like this: a Google Doc with red/yellow/green pills, a bulleted list of "accomplishments," another bulleted list of "blockers," and a section called "next steps" that nobody updates after week three.
It fails for three reasons. First, it's disconnected from the work. The cards and tickets where work actually happens live in another tool, and the status report has to be re-typed from them each week. Second, it's write-only. Stakeholders skim it on Monday, nobody references it on Wednesday, and by Thursday it's archived. Third, it conflates two different jobs: tracking and reporting. Tracking is a board's job. Reporting is a narrative on top of tracking. When you merge them, you do both poorly.
The fix isn't a better doc template. It's separating the two layers and connecting them.
The template structure
Here's the structure that's worked for the eng managers and PMO leads I've talked to. Six sections, in this order:
1. Header
Project name. Reporting week. Overall health (one word: on track, at risk, off track). Owner. Last updated timestamp. Keep this short — it's the part stakeholders glance at and decide whether to keep reading.
2. Highlights
Three to five bullets on what shipped or moved meaningfully this week. Not every card that closed — the ones that mattered. If you can't say why a highlight matters in one sentence, it isn't a highlight.
3. Risks and blockers
Anything that could turn the project red in the next two weeks. Each risk gets an owner and a mitigation. "We're behind on the auth migration" is not a risk entry. "Auth migration owner is out next week and we have no backup — moving the deadline or pairing a backup owner this Friday" is.
4. Next week
The top three to five things the team is going to focus on. This is where the link to the board matters most — every item here should map to a card or epic.
5. Decisions needed
The most underused section. List the open questions where you need a stakeholder to weigh in. Tag the person. Give them a deadline. Most weeks this section is empty. The weeks it isn't are the weeks the report earns its keep.
6. Metrics
Two or three numbers that matter for this specific project. Cycle time, completion rate, scope changes, burn-down. Resist the urge to add a dashboard. One metric a stakeholder reads beats five they don't.
How to put it on a Zoobbe page
The mechanical part. Create a new page in your workspace. Pick the project category template if you have one, or start blank. The page sits in your workspace's nested page hierarchy so you can keep one per project under a parent page called something like "Weekly Status."
The page is rich text — Lexical-powered — so you can format the six sections as headings, drop in bullet lists, and embed checklists. Cover image at the top if you want it to feel less like a wiki entry.
Now the part that makes it stay current: link directly to the board. Reference specific cards by title in the highlights and next-week sections. When someone clicks through to a card, they see the live status, owner, and due date — not a stale screenshot. If a deadline slips on the board, the report reflects it the next time someone opens the page.
This is the difference between a report and a snapshot. A snapshot is a moment in time. A report linked to live cards is a moment in time plus a window into the underlying work.
The automations that do half the work
The point of putting the report on a Zoobbe page isn't just collaboration. It's that the board underneath can do work for you. Three automations cover most of the recurring grunt:
A "This Week" list that fills itself
Set up an automation: when a card has a due date in the next seven days, add a label called "This Week." Filter the board by that label and you have an instant view of what should land before Friday. The Next Week section of the report writes itself from this view.
Due-date reminders before they bite
Use the due-date-approaching trigger. When a card is two days from due and not complete, send a notification to the owner and the project lead. By Friday, you're not chasing — you're just confirming.
A Friday digest you don't have to assemble
Schedule an automation via cron expression to run every Friday at 9am. Have it post a comment on a dedicated "Status Roll-Up" card with a count of completed cards this week, overdue cards, and cards moved into On-Going. That's your highlights and risks sections, pre-drafted. You add the why.
None of this writes the report for you. It removes the parts of the report that don't need a human and leaves the parts that do.
What this looks like for a PMO running ten projects
If you're a PMO lead with ten active projects, the math changes. You don't write ten reports — your project leads do. What you need is a parent page that links to each project's status page, with the headers visible in one scroll. Workspace-level permissions mean stakeholders see exactly the projects they have access to. No copy-paste. No "can you send me last week's deck?" emails.
For engineering managers running two or three workstreams, the same template scales down. One page per workstream, one parent rollup, one Friday morning where you read the digest comments and write three paragraphs of context.
One thing this template won't fix
If your team isn't moving cards on the board, no report template will save you. The whole approach assumes the board is a reasonable proxy for reality. If cards sit in "On-Going" for three weeks because nobody updates them, the report will lie. The template doesn't solve culture. It rewards a team that already keeps the board honest by giving them two hours of their Friday back.
FAQ
How long should a weekly status report be?
Aim for something a stakeholder can read in under three minutes. That's roughly 300-500 words plus the metrics line. Anything longer and the people you need to read it won't.
Should the status page be public or workspace-only?
Workspace-only by default. If external stakeholders need access, use page-level sharing with the viewer or commenter role so they can read and ask questions without editing the report.
How is this different from just having a board?
The board shows the work. The report shows the meaning. Stakeholders don't want to read 80 cards — they want three highlights, two risks, and one decision. The page is where you write that interpretation on top of the live board.
What if a stakeholder wants a PDF or email?
Use page sharing to give them read access and link to the page in your weekly email. The link stays current. A PDF is stale the moment you export it.
Can I use the same template for monthly or quarterly reports?
The structure scales. For monthly, keep the same six sections but expand Highlights and Risks. For quarterly, add a section on goals and outcomes. The principle holds: narrative on top, live board underneath.
Ship it Friday
Pick one project. Build the page this week. Wire up the three automations. Next Friday, you'll either spend twenty minutes on the report instead of two hours, or you'll learn that your board is lying — which is a more useful problem than the one you started with.
Photo by Kelly Sikkema on Unsplash