A weekly client status update template should answer three questions quickly: what changed, what is next, and is there anything the client needs to decide? If the message only lists what you did, it may be a timesheet disguised as communication. If it buries the one pending approval beneath paragraphs of progress, the project can stall despite everyone receiving an update.
This guide is designed for freelancers and small service teams who do not want another reporting dashboard. It includes a copyable email, a fictional example with a genuine blocker, an optional one-page project view, and a process for deciding when an update should become a conversation. The examples are templates, not reports from real clients.
What a Weekly Client Status Update Template Should Include
Project reporting advice for large teams can be useful, but a solo operator rarely needs every field. Asana’s project status template organizes updates around project health, recent progress, blockers, and next steps. Atlassian’s weekly report template similarly emphasizes completed work, areas needing input, and what comes next. For a client email, that structure can be reduced to a single screen.
| Section | What the client should learn | Typical length |
|---|---|---|
| Project and period | Which engagement and week this covers | One line |
| Status | Whether the agreed plan remains workable | One sentence |
| Completed | Which deliverables or decisions progressed | Two or three concrete points |
| Next | What will happen before the next check-in | Two or three actions |
| Client action | What requires their input, by when, and why | One clear ask or “none” |
| Risks and changes | What might affect scope, deadline, or fee | Only when relevant |
The hardest section is often the status sentence. “Busy week, lots of progress” says almost nothing. “Draft completed; launch date now depends on approval of the new pricing copy by Thursday” gives the reader a decision they can act on.
The Copy-and-Paste Weekly Client Update Email
Use this as a starting point, not a form to fill regardless of relevance. Keep the sections your client needs and remove empty bureaucracy.
Subject: [Project name] — weekly update, [date range]
Hi [name],
Overall status: [On track / At risk / Waiting on a decision]. [One sentence explaining the reason.]
Completed this week:
• [Deliverable or milestone completed, with link to the right version]
• [Decision or meaningful improvement completed]
• [Optional third item, only if it matters]Planned next:
• [Next deliverable and target date]
• [Next dependency or planned review]One thing I need from you: [Specific decision, asset, or approval] by [date and timezone], so [consequence or next step]. If nothing is needed, say “No action needed this week.”
Scope or timing change: [None / Describe the issue and the proposed way forward. No unapproved commitments.]
The current project files are here: [link]. Please reply to this email for a decision; comments in the shared document are welcome for detailed feedback.
Thanks,
[name]
The exact clock time and timezone matter when client and freelancer work in different countries. “By Thursday” can describe two very different business days. The guide to working across time zones with clients explains how to set a reliable overlap and handoff window.
A Fictional Example With a Realistic Blocker
Suppose a freelancer is creating a five-page service website for an imaginary consulting company called Harbour North Advisory. The contract specifies approved copy before development and one named approver. Midweek, the client asks to add a sixth page and has not supplied the final service descriptions.
Subject: Harbour North website — weekly update, 12–16 October
Hi Sam,
Status: At risk. The first three agreed page layouts are ready for review, but the remaining build depends on the final service copy.
Completed: Homepage and two service-page layouts are ready in the shared review folder. Mobile navigation has been incorporated into the same draft. The last round’s approved comments are recorded in the version notes.
Next: I will implement the approved layouts and prepare the contact page once the copy and review decision are confirmed.
Action needed: Please send the approved service descriptions and confirm whether the three draft layouts are ready to proceed by Thursday, 22 October, 3:00 p.m. Brisbane time. If that timing is not possible, I can send a revised milestone proposal.
Scope: The requested sixth page is outside the signed five-page scope. I have not started it. I can quote it as a separate addition after we confirm its content and purpose.
Thanks,
Alex
This message is fictional and the dates are illustrative. Its strength is not the polished wording. It states progress, names the blocker without blame, separates an extra request from contracted work, and makes the next decision unambiguous. The status is “at risk” because a dependency is unresolved—not because the freelancer wants to pressure the client.
How to Choose On Track, At Risk, or Blocked
These labels only work if they follow consistent criteria. Agree on definitions rather than using red/yellow/green as a measure of emotion or effort.
| Status | Plain-English definition | Best next action |
|---|---|---|
| On track | Work and known dependencies support the agreed next milestone | Continue; state the next deliverable |
| At risk | A decision or delay may affect a milestone, but recovery is still plausible | Name the dependency, owner, decision date, and contingency |
| Blocked | Work cannot reasonably proceed without required input or access | Ask for the specific input; do not invent progress |
| Scope review needed | New work may affect deliverables, budget, or schedule | Propose a separate change approval |
“At risk” does not always mean the freelancer failed. A missing stakeholder approval, unavailable API access, or new client requirement may be the reason. The report should show what is known and what happens next. It should not turn uncertainty into an invented percentage such as “92% complete.”
Make Deliverables More Visible Than Hours
For fixed-fee and milestone projects, leading with hours worked may obscure whether the agreed result is closer to completion. “Spent six hours working on the website” gives less usable information than “Homepage design v2 is ready for consolidated review.” This does not mean hours never matter; time-and-materials agreements may require them, and a statement of work may define reporting differently.
Attach or link to the exact version rather than writing “the latest file.” Google’s version-history help
What If There Is No Progress to Report?
Do not fill space with trivial tasks. Sometimes a project is in a waiting period, such as procurement, legal review, or a scheduled launch. A useful short message might read: “No deliverable changed this week. We are waiting for the previously requested final copy. The next action remains with the client; the proposed production date will be revisited when the copy arrives.”
Other weeks call for no update at all if both sides have agreed on milestone-based communication instead. Pick a cadence that supports the engagement. Weekly is a good default for active multiweek work, not a law of freelance operations. A one-day task may only need a kickoff confirmation and completion notice; a stable monthly retainer may need an agreed monthly summary.
A One-Page Internal Record Behind the Email
The outgoing client email should be easy to skim. The private record may contain more detail so the freelancer does not have to reconstruct decisions later. A spreadsheet or small project board can include:
| Field | Example |
|---|---|
| Project / client | Harbour North Advisory website |
| Reporting period | Week of 12 October |
| Current status | At risk — pending copy |
| Approved deliverables | Five pages, two review rounds |
| Current version | Layouts v2, link to shared folder |
| Decision needed | Approve layouts and send copy |
| Decision owner | Named client approver |
| Next agreed milestone | Implementation after content approval |
| Change log | Sixth-page request awaiting quote |
Keep this source of truth separate from the text of the weekly email. You should be able to send an update without combing through six chat apps. If a project begins without clear delivery and approval boundaries, first establish them in a freelance scope of work template. Reporting cannot fix a scope nobody agreed on.
Sending Updates Across Time Zones
If a client is in Sydney and the freelancer is in London, a Friday-afternoon update may arrive on Saturday or after the client’s decision window has closed. Instead of assuming that everyone sees email during your workday, agree on the preferred day, recipient, decision channel, and deadline convention at kickoff.
A useful rhythm might be to gather evidence on Thursday, send the report before the client’s Friday workday, and reserve a predictable window for clarifications. The specific schedule depends on location and contract; there is no universal right hour. Use named time zones, and check daylight saving changes rather than treating the offset as constant all year.
Formal approvals should have a stable home. The client communication tools guide
How to Report a Delay Without Overexplaining
The uncomfortable email is usually the most valuable one to send. A vague “we are running slightly behind” leaves the client guessing. A useful delay update contains the affected milestone, the known reason, what is still possible, and what you need to decide together.
The agreed draft milestone is at risk because the source files have not been approved. The analysis and page structure are complete, but publication cannot proceed until the approved assets arrive. If they arrive by Tuesday, I can propose an updated schedule on Wednesday. If not, the next launch date will need to be agreed separately. I have not changed the contract timeline without your approval.
Use facts the client can verify. Do not claim that a dependency caused a delay when the real issue is your own capacity or an estimation mistake. If the mistake is yours, acknowledge it and propose a credible correction. Precision is usually more helpful than a long defense.
Should You Automate Weekly Client Updates?
Automating collection is often safer than automating a send. A calendar reminder can prompt you to review the project record; a form can gather milestone changes; AI can turn your factual notes into a draft. But an automatically sent status report can misrepresent an approval, date, or deliverable if the underlying records are incomplete.
A low-risk sequence is: collect approved facts, generate a short draft, verify project links and dates, decide the risk status yourself, then send. A status update should never automatically approve a change request or promise a new deadline. If you use AI, remove private or client-sensitive information that the selected tool is not authorized to process, and verify every assertion before sharing it.
The Five-Minute Pre-Send Review
- Can the client identify the project and reporting period immediately?
- Does the first paragraph say whether the next agreed milestone remains achievable?
- Are completed items linked to the correct version or deliverable?
- Is every client request specific, with a decision owner and a clear date?
- Have you distinguished the approved scope from optional additions?
- Do dates and time zones agree with the contract and the actual calendar?
- Would the report still be true if forwarded to a different stakeholder?
The point of a weekly client status update template is not to create another administrative habit. It is to reduce avoidable questions and help people make the next decision while there is still time to act. When the update is short, honest, and anchored in real deliverables, it can replace some meetings rather than becoming one more thing to manage.
