Freelance Client Update Template With a Worked Example
- What should a freelance client update include?
- What evidence belongs behind the update?
- How do you turn the evidence into a readable message?
- What does a complete client update look like?
- Why is "50% complete" sometimes misleading?
- How should you report a delay or unresolved decision?
- How do you share evidence without exposing client information?
- What should you check before pressing send?
- Sources
What should a freelance client update include?
A freelance client update should identify the reporting period, the current state of each deliverable, evidence of progress, the next action, and any decision needed from the client. Separate drafted, sent for review, and accepted work; none automatically means the next. Protect confidential information and use the agreed approval and change process. A routine update does not determine contractual rights: refer legal, tax, payment, or privacy questions to appropriately qualified professionals in the relevant jurisdiction.
The useful question is not "Have I sounded busy?" It is "Can the client see what changed and what needs their attention?" A short update can answer that without reproducing your entire working notebook.
This guide focuses on reporting during an active project. Use the client kickoff checklist to establish the channel, recipients, review roles, and reporting rhythm before applying it.
What evidence belongs behind the update?
Start with the agreed deliverable list, the previous update, and the current files. Compare them before composing the message. Otherwise, it is easy to report a draft you intended to finish as one you actually sent.
For each deliverable, keep a small evidence row:
| Field | What to record | Illustrative entry |
|---|---|---|
| Item | Stable deliverable name or identifier | Services page |
| Version | The exact file being discussed | Services-v02 |
| Working state | What has actually happened | Sent for review |
| Evidence | Authorized file link or decision record | Review message dated 7 September |
| Next action | A specific remaining action | Client to confirm service names |
| Owner and date | Responsible person and agreed deadline | Named client contact; 9 September |
| Dependency | What cannot proceed yet | Final wording awaits service names |
These are our editorial fields, not a required industry standard. Adapt them to the work. A photographer may track an approved image selection; a developer may track a named test result and environment. Neither should mark a delivery accepted without the required confirmation.
Avoid one shared "done" column that combines your own completion with client acceptance. If the agreement uses different terms or a formal acceptance procedure, retain those terms rather than quietly replacing them with this vocabulary.
How do you turn the evidence into a readable message?
Use a stable order: current position, changes since the last report, decisions needed, and next work. Asana's status-report guidance similarly recommends leading with project health, accomplishments, and blockers, assigning next actions, and maintaining a consistent reporting format and schedule. You do not need its software to write a clear update.
Lead with the important exception. If approval is missing and affects the next milestone, say so before listing routine progress. If no client action is needed, state that explicitly instead of adding a vague "Any thoughts?"
Keep evidence close to the statement it supports. "About page v02 is ready for review" should point to that version, not to a folder containing every draft. Use descriptive link text and enough written context for someone who cannot open an attachment immediately.
Separate the reporting period from the time of writing. An update covering 1–7 September may be prepared the following morning; work completed after the reporting cutoff belongs in a clearly labeled subsequent note, not silently inside the earlier totals.
What does a complete client update look like?
The following is a fictional example created to demonstrate the workflow, not an account of a real engagement. Assume the parties have already agreed the review roles and dates. File names are illustrative; there are no live client links.
Subject: Website copy update — 1–7 September 2026
Current position: All four page drafts have been prepared. Two pages are accepted under our agreed review process. The Services page is awaiting a decision on service names, so its final wording is not yet ready.
Changes this period: Home-v03 and About-v02 were accepted on 7 September. Services-v02 and Contact-v01 were sent for review on 7 September. The shared evidence record contains the corresponding files and approval messages.
Decision needed: The named client contact should confirm the approved service names by 9 September, 15:00 UTC, through the agreed review channel. The choice must come from the authorized decision-maker; the freelancer will not select new names independently.
Next work: The freelancer plans to incorporate the confirmed names into Services-v03 by 10 September. The client reviewer is scheduled to return consolidated Contact-page feedback by 9 September. The next routine update is planned for 11 September.
Dependency: The Services revision depends on receiving the naming decision. If it is unavailable at the review deadline, the freelancer will contact the project lead to assess the affected schedule under the existing agreement. No revised completion date has yet been agreed.
Replace every detail with the project's actual record before sending. Keep any contractual notices, change requests, or payment correspondence in the form and channel the agreement requires; the example is a progress message, not a legal notice template.
Why is "50% complete" sometimes misleading?
In the example, two of four pages are accepted: 2 ÷ 4 = 50% of the page count. All four have drafts: 4 ÷ 4 = 100% drafted by page count. Neither number establishes that half, or all, of the entire project is finished.
Pages may require unequal effort. Review, revisions, file preparation, or other agreed handoff work may remain. A count also cannot establish the amount earned or payable; those questions depend on the agreement and applicable rules.
A clearer statement is: "Two of four pages accepted; two awaiting client review or decisions." It preserves the count and names the missing stage.
If a client requests percentages, agree what the numerator and denominator measure. State whether the measure counts pages, test cases, approved assets, or estimated effort. Do not combine unlike items into an unexplained percentage, and do not invent weighting after progress has slowed.
How should you report a delay or unresolved decision?
Distinguish a fact from a forecast. "The required file has not arrived as of 12:00 UTC" is a dated observation. "Delivery may move" is a possible consequence. "Delivery is now next Tuesday" is a different claim requiring an established basis and the relevant authorization.
Use an issue record with four parts:
- What is missing or has changed.
- Which named deliverable or next step it affects.
- Who can resolve it and what answer is needed.
- When you will review the position again.
If you caused the delay, say what happened plainly and describe the proposed recovery step. Do not imply client approval of a new schedule merely because you announced one.
If a request adds work, link it to the documented project scope and follow the agreed change procedure. Do not bury a new fee, deadline, or deliverable inside an ordinary update. Obtain qualified advice where obligations are disputed or unclear.
How do you share evidence without exposing client information?
Include only what the intended recipients need. Keep passwords, account numbers, personal records, and unrelated client material out of the update. A screenshot is not automatically safe: review visible tabs, notifications, names, comments, and background information before sharing.
The U.S. Federal Trade Commission's business privacy guide recommends limiting sensitive personal information to legitimate business needs and limiting access to the resources needed for the job. It also calls for a retention policy when information must be kept for business or legal reasons. This is not a substitute for jurisdiction-specific privacy advice or the client's approved security process.
For a concrete tool example, Google Drive's sharing documentation distinguishes Viewer, Commenter, and Editor roles for My Drive files. Restricted access limits opening to people with access. Google also explains that higher parent-folder permissions cannot simply be reduced on an individual file.
Check the intended recipients and folder access; ask the authorized administrator if permissions are unclear. Do not switch confidential evidence to public or anyone-with-the-link access merely to resolve a viewing problem. Ask the recipient to confirm access using their authorized account, never shared credentials.
What should you check before pressing send?
Read the first paragraph alone. Does it state the actual position, or only describe effort? Check every count against the evidence rows and every "approved" against the required decision record.
Then verify the reporting dates, version names, decision owner, time zone, next checkpoint, recipients, and links. Remove client actions already completed before sending. Carry unresolved items forward with their original context instead of presenting the same request as new each week.
If nothing has changed, say what remains unchanged, why, and when it will next be checked. Escalate urgent security incidents or material issues through the agreed procedure immediately rather than waiting for the reporting day.
Keep the sent update in the agreed project record. Further client-workflow guidance can help organize the surrounding process. The aim is a reliable picture of the work, not a more impressive description of the week.