Team Operations
Async Status Updates: Make Progress, Blockers and Decisions Clear
Replace vague status messages with a useful written update that separates evidence, dependencies and decision requests, with an original before-and-after example.
What you will learn
- Write a status update around changed facts and useful next actions
- Separate a blocker from an explicit decision request
- Choose when an asynchronous update needs a live conversation
An asynchronous status update lets people understand progress, blockers and decisions without needing to be present at the same time. Its job is to make the current state and next useful action clear, not to prove the author has been busy.
A good update can be short because it links to evidence and names the decision. A vague update can be long and still leave everyone asking what changed.
What should a project status update include?
Include the intended outcome, what changed since the previous update, the evidence, the next dependency and any decision needed. State who should respond and by when when a response is necessary. Do not make every reader guess whether the message is for awareness or action.
Atlassian describes async updates as written or video progress reports that can cover status, challenges, decisions and risks without requiring an immediate response. That does not mean a genuinely urgent issue should wait unnoticed in a weekly document.
Choose a cadence and location people can reliably find. The update should point to the working record, not create another conflicting source of truth.
Rewrite one vague update
This original fictional example concerns a customer resource launch. The first version sounds active but contains little usable information.
“Good progress this week. Content is almost done. Waiting on design. Still targeting launch soon.”
Now separate facts, dependencies and the actual request.
| Update part | Decision-ready rewrite |
|---|---|
| Outcome | Publish the reviewed customer kickoff resource, including its downloadable preparation card |
| Changed fact | Text review is complete; the working draft contains the approved corrections |
| Evidence | Link to the reviewed draft and its open asset checklist |
| Dependency | The card layout is not yet reviewed; the named designer has not confirmed availability |
| Decision request | Resource owner: decide by Tuesday noon whether to use the approved text-only card or wait for the designed version |
| Next update | Launch timing will be confirmed after that decision, not assumed now |
The rewrite does not blame design or invent a deadline commitment. It identifies the unresolved capacity question and gives the authorized owner a concrete choice.
Make the status label explainable
“On track,” “at risk” and “blocked” mean little without shared definitions. Describe the dependency and its impact. If a launch date is at risk because a required approval is missing, say that. Do not use a positive color to conceal uncertainty.
Distinguish confidence from commitment. An estimate belongs to the person making it and may depend on conditions. A requested action becomes an accepted commitment only when the responsible owner confirms it.
Keep the previous update available. Readers should be able to see what changed without reconstructing the project from scattered messages. Correct an error openly rather than silently rewriting the historical record.
Ask for a decision people can actually make
A useful request contains the choice, relevant evidence, owner and timing. “Thoughts?” asks everyone to invent the decision. “Please choose the reviewed text-only card or a later designed release” makes the trade-off explicit.
If no response is required, say so. If a response is needed, avoid assuming that a mention guarantees it was seen. Follow the team's agreed escalation route for time-sensitive issues.
Use the meeting notes template when a live discussion creates new decisions. Summarize the accepted outcome back into the project record so absent teammates do not need to watch a recording to know what happened.
Know when to switch formats
Async is useful for information people can inspect independently. A live conversation may be appropriate when the choice is ambiguous, participants disagree about the evidence or the situation is sensitive. Keep that conversation focused on the unresolved question rather than repeating every status item.
Urgent incidents need the team's incident route, not an ordinary update with a more dramatic subject line. For routine coordination, the task management guide helps connect the update to actual owners and work.
Copyable AI prompt
Try this with Aurora AI in Finta, Codex, or Claude. Use only authorized project notes.
Rewrite [project notes] as a concise async update. State outcome, changed facts, evidence links, dependencies, decision requests, responsible owners and next review point. Distinguish estimates from accepted commitments and awareness from required action. Flag missing evidence and matters needing the team's urgent or sensitive escalation route. Do not invent progress, blame colleagues or assign unaccepted work. Prepare the draft for human review; do not post, message or change deadlines.Send clarity, not another status ritual
Explore Finta's Executive Assistant for preparing a clear update. Keep the evidence and owner visible so readers can act without chasing the author for the basic facts.