A client project update email should explain the current position, meaningful progress, risks, required decisions, and next checkpoint. Put the most consequential point near the top, especially when the schedule is at risk or work is blocked.
“Twelve tasks completed” does not tell the client whether the next milestone is ready. Name what is complete, what is approved, and what still depends on an input or decision.
Use the three fictional emails below as examples, then adapt the copyable structure to your project.
Before releasing the first stage, use the delivery readiness checklist to confirm necessary inputs, access, and decisions.
Use a short structure that answers the client's questions
Use this structure for a client-facing update:
- Overall position: on track, at risk, blocked, or another clearly explained state.
- Progress that matters: completed work or decisions affecting the milestone.
- Risks and effects: what has changed and what it means.
- Action needed: the decision, owner, and agreed date.
- Next checkpoint: what the client can expect to hear next.
You do not need every field in every message. If nothing requires client action, say that. If a date is uncertain, explain what must happen before you can confirm it.
Asana's status-report guide covers project health, milestones, blockers, and reporting structure. The client-facing examples below focus on making the next decision visible rather than reproducing an internal project report.
Read the decision map as text
- On track: Explain the milestone and relevant completed work. State whether any client action is needed.
- At risk: Name the uncertainty and its possible delivery effect. Request the decision or input and set a confirmation checkpoint.
- Blocked: Name the dependency and the work that cannot proceed. Identify the owner, next check, and useful work that can continue.
Use a clearly explained status rather than a reassuring label. Completed work, approved work, and work ready for handoff are different states.
Example 1: On track, with no action needed
This fictional update concerns a service-page copy project.
Subject: Service pages — first draft on track for November 3, 2026
The first draft remains on track for November 3, 2026, at 3:00 p.m., America/New_York. The service structure is confirmed, and the supplied product details have been incorporated into the outline.
I am drafting the three agreed pages next. No action is needed from you at this stage.
That delivery will include the draft and focused review questions. The review window remains as agreed at kickoff.
The update ties activity to the promised delivery. It also tells the client they are not currently holding up progress.
Avoid adding reassuring adjectives such as “excellent” or “amazing” unless they convey something specific. The confirmed commitment is the useful information.
If the missing decision is an approval, check the client approval process before adding another reminder.
Example 2: At risk, with a decision needed
This fictional update concerns a website release.
Subject: Website release — product information needed to protect the schedule
The release date is at risk because the final product information has not arrived. The layout work is complete, but the affected pages cannot move into final review without those facts.
Alex, as the product-information owner, please confirm by November 4, 2026, at noon, Europe/London, whether the approved facts can be supplied. This is the requested response checkpoint; receipt is not yet confirmed. I will review the actual input position and remaining sequence on November 5 by 3:00 p.m., Europe/London, then propose a feasible delivery date for agreement.
If it cannot, we need to choose between releasing the unaffected pages first or rescheduling the complete release.
This update does not imply that receiving the information automatically restores the original date. It names the checkpoint at which the provider can make a credible commitment.
Example 3: Blocked, with a known dependency
This fictional update concerns an inquiry workflow.
Subject: Inquiry routing — implementation paused pending authorized access
The routing setup is blocked because the required account permissions are not yet available. The agreed workflow has been documented; the live configuration has not begun.
Morgan, the client’s system owner, has agreed to confirm the access position or an authorized alternative route by November 2, 2026, at noon, America/New_York. This is a checkpoint, not a promise that access will exist. I can continue preparing the handoff notes, but live configuration and testing remain paused until the necessary permission is available and checked.
I will update you November 2 at 3:00 p.m., America/New_York, with the access position and next feasible production step. If access is still missing, I will report the blocker and next action rather than an assumed recovery date.
A useful blocked update distinguishes the paused work from work that can still proceed. It does not make the whole engagement appear idle or promise an unverified recovery date.
A copyable client update email template
Use the parts that fit the current project. Replace each bracketed item before sending; omit empty fields rather than inventing progress.
Copy-and-customize template: Replace the text in square brackets with your project details before using it.
Subject: [Project] — [current position or next decision]
Current position: [What is on track, at risk, or blocked, and why.]
Since the last update: [The completed work or confirmed decision relevant to the next milestone.]
Next milestone: [The deliverable or checkpoint, its date, and any unresolved condition.]
Action needed: [Specific input or decision, owner, and agreed deadline with time zone.] / No client action needed.
Next update: [When you will confirm the next position.]
For a small project, this may fit in one short email. A larger engagement may need a linked report, but the email should still make the current position and requested decision clear.
Keep links limited to the relevant version or evidence. A client should not have to open every project document to understand the message.
Explain completion without misleading percentages
“90% complete” sounds precise, but it may conceal the hardest remaining dependency. A task count can be equally misleading if tasks vary greatly in size or importance.
Instead, identify what is ready and what remains:
All three pages are drafted. Two are approved; the third is awaiting confirmation of the service exclusions. Final handoff remains dependent on that approval.
If you use a percentage, explain what it measures. “Eight of ten agreed pages drafted” is different from “80% of total project effort complete.” Neither should imply the project is ready for release unless the necessary checks and approvals are complete.
Use clear client communication to explain the effect and the next action.
Report bad news while there is still a decision to make
Do not wait for certainty about every consequence before acknowledging a material risk. Explain what is known, what remains uncertain, and when you will clarify it.
If the problem is your mistake, own it:
Subject: Integration handoff — provider estimate needs correction. I underestimated the testing needed for the agreed integration. The planned November 6, 2026 handoff is at risk; the additional testing is my responsibility and is not new client scope. I am checking the remaining scenarios and available capacity. I will send the results and a proposed revised date by November 5 at 3:00 p.m., America/New_York, for your review. No client action is needed today. If a remaining test is blocked, that update will name the dependency and next checkpoint instead of claiming the fix is complete.
If the issue is a new requirement, describe the requirement and the change decision needed. Avoid using blame to substitute for a plan.
Choose a cadence and exception rule
Agree a reporting rhythm that fits the project. A short, stable engagement may need less frequent reporting than a rapid release involving several dependencies.
Also agree which events justify an update outside that rhythm: a material schedule risk, a blocked approval, or a change requiring authorization.
If you send weekly updates, communicate a material risk when it appears rather than waiting for the scheduled report. A daily message should not repeat “still working on it” when nothing relevant has changed.
Useful delivery updates provide context for a later client retention review; they do not guarantee renewal.
Keep the supporting detail available
Link to the relevant approved version, review item, or milestone record where access is appropriate. Do not link the client into an internal workspace that reveals unrelated projects or private notes.
If you use software to distribute reports, verify who can see the update, linked files, and underlying project. Test the intended client access before sharing. Do not assume that a private project makes every separately shared report private.
If facts are clear but uncertainty remains, ask about the client concern rather than sending more activity detail.
Before sending the next update
Read it as if you have not followed the project's daily work. Can you identify the current position, the next milestone, and any action required? Are the dates and uncertainties consistent? Does the message distinguish completed work from approved work?
If so, send it. If not, repair the missing explanation. A status update earns its place when the client can use it to understand or decide—not when it proves you have been busy.