Righthand
← All posts

How to Build a Weekly Meeting Briefing for Your Team

Build a weekly meeting briefing that highlights changes, decisions, blockers, accepted commitments, and source-backed unknowns.

A weekly meeting briefing should help the team decide where to spend attention. Repeating every project update produces another document to skim. A useful briefing shows what changed, which decisions are needed, which commitments are overdue, and what information the team still lacks.

Quick answer

Build the briefing from a defined set of current sources and organize it around the meeting's purpose. Include changes since the previous week, open decisions, blockers, and follow-ups with owners. Deliver it early enough that people can read and correct it before the call.

Righthand's task delegation can support recurring preparation, subject to access to the relevant work accounts. The process matters as much as the format: someone must own the review and corrections.

Decide what belongs in the briefing

Choose a stable source list such as the project tracker, previous meeting notes, and approved team updates. Specify the snapshot time so readers understand whether a Monday-morning change is included in a Friday-prepared brief.

Use a few practical sections:

  • Changes: new information that affects the plan.
  • Decisions: choices the team needs to make.
  • Blockers: work waiting on an external or internal dependency.
  • Commitments: accepted next steps and their current status.
  • Unknowns: missing or conflicting information requiring clarification.

Routine detail can remain behind links. The briefing should point to the source rather than reproduce every task description. This makes the document easier to verify and reduces the chance that a copied status becomes stale.

Prioritize by consequence

A missed deadline on an inactive idea should not outrank a dependency that blocks a customer delivery tomorrow. Give the assistant the team's priority rules: upcoming customer commitments, launch-critical dependencies, or decisions that multiple people are waiting on.

Do not let the assistant infer priority from how many messages a topic generated. A long conversation can be less consequential than a brief update from the person holding the final approval.

Ask for the decision needed, not just a warning. “Client assets missing” becomes useful when it includes which assets, who owns the request, and whether the team needs to move the review date.

An illustrative weekly brief

A small software team has a Monday planning meeting. The assistant reads the approved tracker and last week's decisions. It finds that onboarding copy is complete, the analytics review is waiting on a named owner, and the release date in one document differs from the calendar.

The briefing presents the copy as completed work, the analytics review as a blocker, and the date conflict as an unresolved question. It does not average the dates or choose the later one silently.

The team spends the meeting resolving the owner and launch timing rather than reciting all tasks. After the meeting, the new decisions become the reference for next week's comparison.

A weekly briefing brief

Prepare the Monday team briefing by Friday at 3 PM Pacific using the approved project tracker, last meeting's decisions, and this week's team updates. Organize changes, decisions needed, blockers, accepted commitments, and unknowns. Prioritize upcoming customer commitments and work blocking multiple owners. Include a source link for each important status. Flag conflicting dates rather than choosing one. Draft the briefing for my review; do not post it to the team until I approve it.

If you later authorize posting within a standing workflow, name the exact channel and review rule. Preparation and distribution need separate clarity even when they run together.

Maintain the comparison week to week

Keep a reference to the previous briefing and its corrections. Otherwise, “what changed” becomes a summary of what is visible today rather than a real comparison.

Define how an owner can correct the briefing and when changes should trigger a refresh. For a routine meeting, a single cutoff may be enough. For a launch review, a newer blocker may warrant an update before the call.

Measure usefulness by whether the meeting resolves the listed decisions and whether owners recognize their commitments accurately. A longer briefing is not inherently better.

FAQ

Should every team update be included?

Include the information needed for this meeting's decisions and coordination. Link to routine detail rather than filling the brief with unchanged work.

Can the assistant determine which deadlines moved?

It can compare approved sources, but conflicting or ambiguous changes should be flagged. Do not treat an inferred date as an agreed schedule.

Who approves the briefing?

Assign a meeting owner. Contributors can correct their sections, but one person should decide when the document is ready to distribute.

Related resources

Explore workflows for recurring preparation and calendar management for meeting timing.