Quick answer: Start with a short message from a named owner when the client needs a decision or a predictable progress update. Use a shared report when several people need a dated record of changes, blockers and next steps. Use a dashboard only when the client will return to it and the underlying work is kept current. The channel is less important than whether the client can see what changed, what they must decide and when they will hear from you again.
For: small service teams delivering a client project after kickoff. This is a workflow choice, not a ranking of email, project tools or portals. The example is hypothetical.
Choose by the client’s next action
An internal board may contain dozens of tasks. A customer usually needs a smaller answer: where the agreed work stands, what was completed since the last update, what is at risk, what decision or input is needed, and the next date. Begin with the communication route and cadence agreed at kickoff. The proposal-to-kickoff guide shows how to capture that commitment; the CRM versus project tool guide helps decide where delivery tasks live.
| Client need | Starting route | Failure to test |
|---|---|---|
| One owner, one or two decisions, occasional update | Short email or agreed message | Can the client identify the request and next date without opening an attachment? |
| Several reviewers or a recurring dated record | Shared report plus a short notification | Can everyone find the current version and decision history? |
| Frequent self-service checks across active work | Dashboard or client-facing project view, plus explicit decision requests | Is its data current and is access limited to the intended client? |
A dashboard may display movement without explaining its meaning. An email can be excellent when the work is simple. Avoid giving the client three places to check for the same decision. Name one authoritative project record and one channel for requests that need an answer. The team chat guide covers internal conversation; a channel message by itself is not a client status record.
Write the update before choosing a tool
Use the same compact structure each time: as of date; agreed milestone and current state; completed since last update; blocker and impact; decision needed with approver and response date; next owner action; next update date. Describe an at-risk date as a risk, not as a completed delay. If no client action is needed, say so. If a date is only a target, label it. Keep internal staffing notes or unrelated client work out of the external view.
Asana’s official status-update documentation describes a dated snapshot with summary and next steps. It also notes that people added to a status update can read its contents even if they cannot access the underlying project. That is a concrete reason to review the external audience and text before sharing any generated or copied report. You can apply the same review to a plain email or document.
A hypothetical Friday update
Imagine a three-person studio refreshing a service website. The agreed next milestone is a first-page review the following Wednesday. Copy and layout for two pages are ready internally; one page still needs the client’s approved photos. The delivery owner can continue an unrelated contact-page test. The milestone remains a target until the missing images are checked.
As of Friday, 2 October — website refresh
Completed: first drafts of the Home and Services pages are ready for our internal review.
At risk: the About page still needs three approved team photos. If the final photo is not usable by Monday, we will confirm a revised first-page review date.
Decision needed: please send the three approved photos through the agreed upload link by Monday, 5 October, 12:00 in your time zone, or tell us who can supply them.
Our next action: [delivery owner] will check the files, continue the contact-page test, and confirm the review schedule.
Next update: Tuesday, 6 October, by [agreed channel].
Those dates and outputs belong only to this fictional example. In a real message, check the accepted scope, actual progress, time zone and available capacity. The missing client inputs guide gives a copyable request and a record for what can proceed while a file or approval is pending.
Test the route before adding a portal
Send one sample update to an internal reviewer using the intended client view. Ask them to answer: What is done? What is blocked? Who acts next? What happens if the client does nothing? When is the next update? If the answer is buried below a chart or behind a login, simplify the message. If a portal is under consideration, the onboarding guide explains when repeated client activity may justify it.
For a recurring report, assign a maintainer and a review time. Compare its headline with the underlying task record before sending. Record corrections instead of silently replacing an earlier dated update. If no one maintains the view, return to a simpler named-owner message until the reporting process works.
Copy the status decision record
Project and accepted scope reference: ___ · client audience and agreed channel: ___ · update owner and backup: ___ · cadence: ___ · authoritative task record: ___ · completed since last update: ___ · blockers and date impact: ___ · client decision, approver and response date: ___ · next team action: ___ · next update date: ___ · external-view check: ___.
Use the record on one live project. If the client can identify its decision and your next commitment from the first screen of the update, the format is doing its job. Add a report or dashboard when a repeated retrieval problem justifies its upkeep.
Source checked 2 October 2026: Asana Help, project progress and status updates. The channel table, fictional message and acceptance test are Practical SaaS Lab editorial guidance; no client communication result or vendor account trial is claimed.
Useful detail: Give a status update a return date
Slack can remind a whole channel at a chosen time; a personal reminder has a different audience.
If a client update is waiting for an internal answer, attach the reminder to that missing answer rather than to a vague instruction to check the project. Use the client’s approved communication channel for the final update.
Try this:
- Write the exact question: “Has the client approved version B?”
- Name who will check, and the time of the next internal review.
- Close the reminder when the answer is recorded; send an update only if it is still needed.
Source: Slack: reminders. Checked October 3, 2026. The practical check is a PSL suggestion.
