Weekly Report: How to Write One (Template and Examples)

A weekly report is a short written summary, sent on the same day each week, of what you finished, what is still in progress, what is blocked, what comes next and which numbers moved. A good one fits on one screen and can be read in two minutes. Its reader is usually your manager, sometimes your team or a client, and always your future self, who will need the record at review time.

This guide gives you the format and three templates you can copy into an email, Slack post or doc: one for an individual, one for a team lead and one for an IT or engineering team. It also has a filled-in example week for a hypothetical employee, a method for writing the report in 15 minutes, and the mistakes that make weekly reports go unread. If you need a project report for stakeholders with red, amber and green status, the weekly status report template covers that format in depth.

What is a weekly report?

A weekly report is a recurring document that answers one question for someone who was not there: what changed this week, and what do I need to know or decide? It is written by one person or one team, it covers a fixed period (usually Monday to Friday), and it follows the same structure every week so the reader can scan it fast and compare it with last week's.

People use several names for the same thing: weekly work report, weekly update, weekly progress report, weekly status report. The differences are mostly about the reader:

• A weekly work report or weekly update goes from an individual to their manager.
• A weekly team report goes from a team lead to their own manager or to the wider company, and rolls up several people's work.
• A weekly project status report goes to stakeholders and tracks one project against its plan, often with a RAG (red, amber, green) rating. That format has its own guide: the weekly status report template.
• An IT weekly report covers systems and service work: incidents, changes, tickets and delivery metrics.

A weekly report is not a timesheet, and it is not a list of every task you touched. A timesheet records hours; a weekly report records results and problems. It is also not a substitute for talking: a blocker that needs a discussion still needs one, and the report is where you flag it.

Where the format comes from

Written weekly reports predate today's team chat apps. At Google, "Snippets" was a weekly email sent on Monday that asked employees for last week's projects and activities and their planned work for the coming week (Google Blogoscoped, 12 March 2008); the full story is in what Google Snippets actually were. Michael Lynch, a software engineer who used Snippets at Google and kept writing weekly updates after he left, describes the tool as just a text box and argues that the habit matters more than the format (mtlynch.io, 25 June 2019). This guide still recommends a fixed format, because it helps the reader; Lynch's point is that the habit keeps the reports coming.

Patagonia founder Yvon Chouinard reportedly used "5-15" reports to stay in touch with employees while he was away for weeks: about 15 minutes a week for the employee to write, five minutes for the manager to read (Entrepreneur, 13 February 2014). The 15-minute limit is still a good target.

Who reads a weekly report, and what they need from it

Most weekly reports have three readers, and each wants something different.

Your manager wants to know whether things are on track, where to step in and what to pass upward. They often read on a phone between meetings, so put blockers and decisions near the top and keep each line short.

Your team or skip-level wants context: what shipped and what might affect their work. On remote and hybrid teams, the report is often how colleagues learn what you do, which matters when the people deciding on promotions do not see you working (more on that in proximity bias and remote visibility).

You, later. Keep weekly reports and your review writes itself: when you write your self-evaluation from twelve months of them, you summarize evidence instead of trying to remember it. The same notes feed a brag document.

Writing the report also helps the writer in the moment. Teresa Amabile and Steven Kramer studied about 12,000 daily diary entries from 238 employees at seven companies, and found that among the events on people's best working days, "by far the most prominent was making progress" (Harvard Business School Working Knowledge, 6 September 2011). A weekly report is a weekly look at that progress, which is easy to lose sight of in a busy week.

The weekly report format: five sections

The weekly report format that works for almost every role has five sections, in this order. The order puts finished work first, because it is the reader's quickest signal of progress, and keeps blocked items high enough that a skimmer still sees them.

The example lines are illustrations, not benchmarks. Two optional lines make the report more useful when they apply:

• Needs from you: a decision, an approval or an introduction you need from the reader, with a date. If this line exists, put it first.
• Notes: anything the reader should know that does not fit above, such as a vacation next week, a risk you are watching or a thank-you to a colleague who helped.

Bullets, not paragraphs

Use one bullet per item and start each bullet with the thing, not the verb: "Onboarding email: shipped" scans faster than "This week I was able to finish and ship the onboarding email". Keep the whole report under about 250 words. If a topic needs more, link to the doc or ticket where the detail lives.

Weekly report templates you can copy

Pick the template that matches who you are writing for. Each one is plain text, so it pastes cleanly into an email, a Slack or Teams message, a Notion or Confluence page, or a Google Doc. Replace the bracketed parts.

Individual weekly report template

Weekly report: [Your name], week of [date]

Needs from you
- [Decision or approval you need, and by when. Delete this section if none.]

Done
- [Outcome 1: what was delivered and what changed because of it]
- [Outcome 2]
- [Outcome 3]

In progress
- [Item]: [where it stands], expected [date]
- [Item]: [where it stands], expected [date]

Blocked
- [Item]: blocked by [person, team or dependency] since [date]. Need [what] by [date].

Next week
- [Priority 1]
- [Priority 2]
- [Priority 3]

Numbers
- [Metric 1]: [this week] (last week [value])
- [Metric 2]: [this week] (last week [value])

Notes
- [Time off, risks, thanks. Optional.]

Team lead weekly report template

A team lead's report is a roll-up, not a stack of everyone's individual reports. Group by goal or project, not by person, and name people where credit is due.

[Team name] weekly report, week of [date]

Summary
[One or two sentences: are we on track for this month's or quarter's goals? What is the one thing to know?]

Decisions needed
- [Decision], needed from [person] by [date]. Options: [A] or [B]. My recommendation: [A], because [reason].

Progress by goal
- [Goal or project 1]: [what moved this week]. [Name] [specific contribution].
- [Goal or project 2]: [what moved]. On track / at risk because [reason].
- [Goal or project 3]: [what moved].

Risks and blockers
- [Risk]: [impact if it happens], [what we are doing about it], [what would help].

Team
- [Hiring, time off, onboarding, workload changes]

Next week
- [Top 3 team priorities]

Numbers
- [Team metric 1]: [this week] (last week [value], target [value])
- [Team metric 2]: [this week] (last week [value], target [value])

To write the roll-up, read your team's individual reports first, then answer the summary line last. If your team posts a daily update, the daily report template is the format that feeds this one.

IT weekly report template

An IT weekly report, whether for an internal IT team, an operations team or a software engineering team, has the same five parts plus a service section: what broke, what changed and how the service performed. For software delivery, the DORA research program defines five metrics that make good weekly numbers: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate (DORA, updated 5 January 2026). Use the ones your team already measures; a weekly report is the wrong place to start a new metric.

IT weekly report: [Team name], week of [date]

Summary
[One or two sentences: service health this week, and the one thing leadership should know.]

Needs from you
- [Approval, budget or decision needed, by date]

Incidents
- [Incident ID] [title]: [severity], [impact on users], [duration]. Root cause: [cause or "under review"]. Follow-up: [ticket].
- [Count] incidents in total this week (last week [count])

Changes and releases
- Shipped: [release or change], [what it changes for users]
- Scheduled next week: [change], [date and time], [expected impact or downtime]

Projects
- [Project]: [what moved], [next milestone and date]
- [Project]: [status], [blocker if any]

Tickets and requests
- Opened: [n], closed: [n], backlog: [n] (last week [n])
- Oldest open ticket: [ID], [age], [why]

Security and maintenance
- [Patching, access reviews, certificate renewals, vulnerabilities fixed]

Delivery metrics (if you track them)
- Deployment frequency: [value] (last week [value])
- Change lead time: [value]
- Change fail rate: [value]
- Failed deployment recovery time: [value]
- Deployment rework rate: [value]

Next week
- [Top 3 priorities]

Keep incident detail short and link to the postmortem. The reader of an IT weekly report is often outside IT, so describe impact in business terms ("checkout was down for 14 minutes") rather than system terms ("pod restarts on payments-api").

Weekly report example: a filled-in week

Here is the individual template filled in for a hypothetical employee, Maya, a marketing manager at a 40-person software company. The details are invented to show the level of detail that works.

Weekly report: Maya Okafor, week of 9 November

Needs from you
- Approve the $1,200 budget for the December webinar platform by Wednesday,
  or I book the free tier and we cap attendance at 100.

Done
- Launched the new onboarding email sequence (5 emails). First email opened
  by 41% of new trials in its first 3 days.
- Published the logistics customer story; sales has used it in 2 demos.
- Cleaned the CRM list: removed 1,900 bounced contacts before Friday's newsletter.

In progress
- Pricing page rewrite: copy done, design review Monday, live by 20 November.
- December webinar: speaker confirmed, landing page draft ready for review.

Blocked
- Webinar registration form: waiting on the budget decision above.

Next week
- Run the A/B test on the onboarding subject lines.
- Ship the pricing page.
- Draft the Q1 content calendar with sales.

Numbers
- Trial sign-ups: 212 (last week 188)
- Newsletter open rate: 38% (last week 35%)

Notes
- Out Friday 20 November. Sam covers the newsletter.

That report is about 160 words. Maya's manager can see in ten seconds that one decision is needed, by when and what happens if it is not made. Compare the version most people write on a Friday afternoon from memory:

This week I worked on the onboarding emails, the pricing page and the
webinar. Had some meetings with sales. Also did some CRM work. Next week
I'll continue with the pricing page and the webinar.

Nothing in the second version is wrong. It just gives the reader no outcome, no date, no number and no decision, so the manager has to ask a follow-up question for every line.

How to write a weekly report in 15 minutes

The slow part of a weekly report is usually reconstructing the week; the writing is quick. Michael Lynch, mentioned above, writes that by Friday afternoon he often forgot what he had accomplished that week (mtlynch.io). Part of the reason is how fragmented a week is: in Microsoft's telemetry, the most interrupted 20% of Microsoft 365 users are interrupted by a meeting, email or notification every two minutes during core working hours (Microsoft WorkLab, 17 June 2025; vendor research). This method assumes you collect the raw material as you go.

1. During the week: keep a running log (1 minute a day). At the end of each day, write three lines: what you finished, what you started, what got in the way. A plain note is enough; a daily report or an async standup update does the same job and tells your team sooner. Your calendar alone is not enough, because it records meetings rather than work (see calendars are not a work log).
2. Minutes 0 to 5: gather. Open your daily notes, last week's report (for the "Next week" items you promised), your sent messages and your task tracker. Copy anything that finished or changed into the template.
3. Minutes 5 to 10: sort and rewrite as outcomes. Move each item into Done, In progress, Blocked or Next. Rewrite each Done line to say what changed: shipped, decided, fixed, published, closed. Delete anything the reader does not need.
4. Minutes 10 to 13: blockers, asks and numbers. Write the blocked items with who can help and by when. Put any decision you need at the top. Copy in this week's numbers next to last week's.
5. Minutes 13 to 15: trim and send. Cut the report to one screen. Read the first three lines as if you were your manager: do they say what you most need them to know? Then send it.

Send it on the same day every week. Friday afternoon is a natural choice: it is the end of the period you are reporting on, and in Microsoft's data Friday carries the lightest share of the week's meetings, 16% against 23% on Tuesday (same WorkLab report). If your manager plans the week on Monday morning, send it then instead, covering the previous week, as Google's Snippets did.

Common weekly report mistakes

These are the patterns that make a weekly report go unread or create follow-up work.

• Listing activity instead of outcomes. "Had three meetings about the migration" tells the reader how you spent time, not what changed. Write the decision the meetings produced.
• Burying the ask. A decision request in the last bullet of the Notes section will be missed. Put it first, with a date and a default ("if I hear nothing by Wednesday, I will go with option A").
• Hiding problems until they are emergencies. A blocker reported on day two is a quick fix. The same blocker reported on day ten is a missed deadline. A report that is all green every week stops being believed.
• Writing a novel. If the report needs scrolling on a phone, it is too long. Link to detail; do not paste it.
• Changing the format every week. A fixed structure lets the reader find the same information in the same place and compare weeks. Pick a template and keep it.
• Reporting numbers without context. "212 sign-ups" means nothing without last week's value or the target next to it.
• Writing it from memory on Friday at 5pm. This is the root cause of most of the mistakes above. Without notes, you remember the last two days and the loudest problem, and the report undersells the rest of the week.

How the weekly report fits with standups, daily reports and 1:1s

The weekly report sits in the middle of a team's written rituals. Each one covers a different time span and reader, and they feed each other.

A written weekly report frees the 1:1 from status: if your manager has already read what you shipped, the meeting can go to the one-on-one meeting questions that matter, such as feedback, growth and the problems that do not fit in a bullet.

A weekly report can also stand in for a weekly status meeting. In an Atlassian survey of 5,000 knowledge workers across four continents, 70% said meetings are ineffective for status updates (Atlassian, undated page, retrieved 3 November 2026; vendor research from a company that sells collaboration software). To see what a recurring status meeting costs your team, run it through the meeting cost calculator. The norms that make written updates work across time zones are in our guide to async communication.

Writing the report from a week that is already recorded

The 15-minute method depends on the running log, and the running log is the step people skip. That is the gap DoneThat is built for. Disclosure: DoneThat publishes this blog. Its desktop app (Windows, macOS and Linux) reconstructs your workday from screen and app activity, with no timers, and writes a daily summary of what you worked on. Screenshots are processed and then deleted, never stored, and you decide whether each summary stays private or is shared with your team. You can export that history as CSV or query it through the API or MCP, for example from Claude or ChatGPT.

For a weekly report, that means the "gather" step is already done when you sit down on Friday. You start from five daily summaries of what actually happened, and the job becomes editing: choosing what matters to the reader, rewriting activity as outcomes and adding the asks and blockers only you can judge. It does not write the "Needs from you" line for you, and it cannot tell your manager why something matters. It just means you are not reconstructing Tuesday from memory.

Screen-based capture is a bigger ask than a notes app, and it is not for everyone. If you prefer a manual log, the templates above work just as well with three lines a day in a text file.

Frequently asked questions

What should a weekly report include?

A weekly report should include five sections: work completed this week (as outcomes), work in progress with expected dates, blockers and who can resolve them, priorities for next week, and the two or three numbers you own compared with last week. Add a "Needs from you" line at the top whenever you need a decision from the reader.

How long should a weekly report be?

An individual weekly report should be about 100 to 250 words, short enough to read on a phone in two minutes. A team lead or IT weekly report can run to 400 words plus a few metrics. If you need more, link to the underlying doc or ticket instead of pasting it into the report.

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

They overlap, and many teams use the terms interchangeably. A weekly report usually covers one person's or one team's work across everything they do. A weekly status report usually tracks a single project against its plan for stakeholders, often with a red, amber or green rating. The weekly status report template covers that format.

What day should I send a weekly report?

Send it on the same day every week. Friday afternoon is a common choice because the week you are reporting on is complete. Monday morning works if your manager plans the week then; Google's internal Snippets email went out on Mondays and asked about the previous week.

How do I write a weekly report to my manager?

Start with anything you need from your manager, then list what you finished as outcomes, what is in progress with dates, what is blocked and what you will focus on next week. Keep it under one screen and use the same format each week. Ask your manager once which part matters most to them, and put that part first.

Start with next Friday's report

A weekly report is five short sections, written the same way every week: done, in progress, blocked, next and numbers, with any ask at the top. Copy the template that fits your role, keep three lines of notes a day this week, and write next Friday's report from those notes in 15 minutes. If the report is for a project and its stakeholders, use the project status format with RAG ratings, linked in the table above.

Sources

• Atlassian (undated). Workplace Woes: Meetings. Vendor survey of 5,000 knowledge workers across four continents. Retrieved 3 November 2026.
• DORA (updated 5 January 2026). DORA's software delivery performance metrics. DORA research program guide.
• Lenssen, P. (12 March 2008). Google Product Snippets. Google Blogoscoped.
• Lynch, M. (25 June 2019, updated 2025). Status Updates to Nobody. mtlynch.io.
• Max, S. (13 February 2014). Everyone Gets 15 Minutes of Feedback. Entrepreneur. On 15Five and Yvon Chouinard's 5-15 reports.
• Microsoft (17 June 2025). Breaking down the infinite workday. Work Trend Index special report (vendor research); aggregated Microsoft 365 telemetry.
• Nobel, C. (6 September 2011). How Small Wins Unleash Creativity. Harvard Business School Working Knowledge, on Amabile and Kramer's diary study of 238 employees at seven companies.

Written by Don, DoneThat's AI coach (LinkedIn) - so this article is AI-written. Every statistic is cited next to the claim and linked in the Sources list, and vendor research is labeled as such. The example people and figures in the templates are invented. Published by DoneThat (Letss B.V., Amsterdam). More about DoneThat; corrections and questions go to support.