Write the weekly update from what changed

Give the update a decision to support

A weekly update is useful when the reader can do something with it: unblock work, adjust a dependency or understand a decision. Begin by naming that reader and the questions they need answered. An update for a project sponsor will not need the same level of implementation detail as a handoff between operators.

Our suggested format has four parts: meaningful changes, current blockers, decisions needed and the next expected checkpoint. Keep a separate place for general background. Otherwise, the same background returns every week and makes real changes harder to spot.

Collect changes from their actual locations

Google’s Workspace guidance distinguishes Drive activity from the version history of Docs, Sheets and Slides. Activity can include moves and sharing changes as well as edits. That is a reminder to inspect what an event means before turning it into a claim of progress.

Build a small source list for your project: the work tracker, the current brief and the place decisions are recorded. For each meaningful change, capture a link, the date and a plain-language explanation. A renamed file may improve organization without moving the project closer to its goal.

Sources: Google

Use a checkpoint you can find again

Notion documents viewing and restoring earlier page versions, with access and retention depending on the workspace arrangement. Whatever tool you use, establish a reference point that next week’s reviewer can actually retrieve. Do not assume a forever-growing chat is an adequate project record.

At the end of each reporting period, save the reviewed update and the date through which it is current. Next time, compare with that checkpoint. Preserve unresolved items until someone closes or changes them; silence in the latest notes is not evidence that a blocker disappeared.

Sources: Notion

Let the assistant organize a constrained packet

Give your assistant the selected change notes and the previous update. Ask it to identify additions, changed commitments, completed work and unresolved questions. Tell it to retain source links and mark missing information rather than filling gaps. This is an original workflow suggestion, not a claim that every assistant will follow it correctly.

Read the draft in two passes. First check factual changes: did the thing happen, and does the source say so? Then check usefulness: does the reader know which decision or action is needed? Remove activity that adds volume without changing the reader’s understanding.

Automate collection only after the questions work

Slack describes Workflow Builder as a way to automate processes through ordered steps. A collection workflow can support a recurring update, but it should collect the fields you have already found useful. Automating a vague request for progress often produces a larger pile of vague progress.

For a small team, start with a manually repeated request: what changed, what is blocked, and what decision do you need? Add automation when the answers have a consistent home and a reviewer. Keep the option for an owner to explain an exception in ordinary language.

Sources: Slack

Make the final update easy to challenge

Publish the reviewed version with its reporting window and an owner. Keep source links near important changes so a reader can correct an interpretation without searching through the whole project. If a date is tentative, say so. If a question is unanswered, leave it visibly unanswered.

After a few cycles, ask whether the update led to clearer decisions. Shorten sections nobody uses and keep the ones that reveal dependencies. The aim is a reliable habit for seeing change, not a weekly performance in which every task must sound like a breakthrough.