A clear project update helps the client understand the present state and make the next necessary decision. State what is complete, what evidence is available, what remains uncertain and what action is needed. Avoid percentages that have no defined meaning or reassurances that conceal a blocker. Updates connect the stages of manage freelance projects.
Report the state of the work, not the effort alone
“I worked on this all morning” describes effort but does not tell the client what they can review. “The square announcement draft is ready; the print version still needs the approved venue text” identifies an output and a dependency. Both effort and output can matter, but they answer different questions.
The GOV.UK guidance on measuring and reporting progress connects reporting to the work and evidence produced during delivery. For a small freelance project, a useful adaptation is to link an update to a version, decision or checked result. Do not borrow an elaborate reporting system when a short, accurate note will do.
Agree the channel, recipients and expected rhythm during the client onboarding checklist. A project with frequent decisions may need more contact than a straightforward file preparation task. A material problem should not wait for the next routine update merely because it was not scheduled.
Read the text version: Replace an effort-only update with a useful project state
Instead of saying only that you worked all morning, name the reviewable output, evidence, remaining dependency and decision. In the fictional note, event-square-v2 is ready, wording was compared with approved copy within the scenario, the print version needs final venue text, and the owner must confirm it in the review note. Record only actual work and checks in a real update.
Give the reader four things they can use
| Element | Useful content | Common weak substitute |
|---|---|---|
| Completed | A named output and its review state | “Nearly done” |
| Evidence | The relevant file, preview or check note | A screenshot presented as proof of every function |
| Constraint | A specific missing input or unresolved issue | “There have been some delays” |
| Next action | Owner, requested decision and effect of waiting | “Let me know your thoughts” |
Use dates or times when they help coordinate an action, and include the relevant timezone when people could interpret them differently. Do not create a false deadline to make the client respond faster. Explain the real dependency: “I need the approved spelling before final captions can be exported.”
Separate status from forecast. A draft ready for review is a current fact if it exists; a final file expected tomorrow is a forecast that may depend on approval. Name the dependency alongside the forecast. If you have not checked something, say “not yet checked” rather than using a broad quality claim.
Example 1: a normal review update
Fictional update draft; not sent: A designer has prepared the agreed square announcement but has not yet produced the print export. The following described work exists only within the teaching scenario.
The square announcement draft, event-square-v2, is ready at the review link. I compared its wording with the approved copy; the printable version is next.
Please send one consolidated set of comments on hierarchy and placement by the agreed review point. The event date and venue wording are already approved, so flag any proposed wording change explicitly. After that review I can prepare the revised square file and the print export.
The version makes the update inspectable. The note describes one specific check without claiming the whole project is finished. The requested review is focused, and the next output is clear. In your real update, include only checks you actually performed and make sure the recipient has access to the review file.
Example 2: a missing input changes the forecast
Fictional update draft: A captioned video needs the approved spelling of a guest’s surname. Editing can continue on unrelated sections, but final captions and export depend on that information.
The first edit is available for review. The guest’s surname at 00:18 is still marked for confirmation, so the captions are not final.
Please ask the programme owner to confirm the spelling in the shared review note. I can continue the other agreed adjustments while waiting. If confirmation arrives after the planned export slot, I will give you a revised delivery time before exporting the final version.
The timestamp points to the actual question. The update identifies the owner and explains which work can proceed. It does not blame the client or conceal the dependency behind “technical issues.” It also avoids promising that a missed input deadline has no effect on delivery.
Read the text version: Explain a blocker without hiding what can proceed
Fictional video update: the surname at 00:18 needs confirmation by the programme owner. Unrelated agreed edits can proceed, but final captions and final export remain dependent on the spelling. If it arrives after the planned export slot, give a revised forecast. The timeline locates the issue; it is not evidence of a real completed review.
Example 3: your own estimate was wrong
Fictional update draft: A freelancer underestimated the time needed to repair a supplied spreadsheet’s inconsistent date fields. The work is still within the agreed task; the freelancer is responsible for explaining the changed forecast.
I underestimated the time needed to check the mixed date formats. The records marked in the review sheet still need verification, so I will not describe the file as ready today.
I have preserved the original and completed the checked rows identified in the log. My next step is to verify the remaining ambiguous dates against the source. I propose sending the corrected file at the revised time shown in the schedule. If that no longer meets your need, let us decide which bounded output would be useful first.
The message owns the estimation error, identifies the remaining work and proposes a decision. It does not silently narrow the scope or label guessed dates as corrected. The appropriate revised timing depends on the actual work and agreement; the example is not a script for excusing repeated missed commitments.
Copy an update worksheet and check the evidence
| Field | Fill before sending |
|---|---|
| Project and version | Which work and review copy does this concern? |
| Completed since last update | What can the client inspect now? |
| Checks actually performed | What did you compare, open, play or test? |
| Still pending | What is incomplete, blocked or unverified? |
| Decision needed | What exact question needs an answer, and from whom? |
| Next step and forecast | What follows, with which dependencies? |
| Link/access check | Can the intended recipient open the relevant material? |
Before sending, read the previous update. Explain any change in the forecast or scope instead of leaving the client to reconcile contradictory messages. Keep sensitive details in the appropriate restricted record; the update can identify the issue without reproducing confidential data in a broad email thread.
When a requested action introduces extra work, use the process to handle client revisions scope changes and link to the decision record. A progress message should not smuggle a scope change into a sentence about what happens next. If a conversation resolves the issue verbally, write down the resulting decision where the project record lives.
As delivery approaches, distinguish “ready for checks” from “ready to hand over.” Use the digital project quality checklist to inspect the final output. A well-written update supports reliable delivery; it cannot substitute for the work or evidence it describes.
Frequently asked questions
How often should I update a client?
Agree a rhythm suited to the project and send an additional update when a material decision or change needs attention. Frequent messages without new information can create noise; a serious blocker should not wait merely for a scheduled reporting day.
Should I report percentage complete?
Only if the percentage has a clear, useful definition. A named output and its review state are usually easier to assess than “80% done.” Do not imply that the remaining work is predictable when major uncertainty remains.
What if there is no progress because I am waiting for the client?
Name the missing input, its owner and the specific work it blocks. Explain what can still proceed and how the forecast depends on the answer. Keep the message practical rather than blaming.
How should I report my own delay?
Acknowledge the cause accurately, show the present state, explain the effect and propose a realistic next step. Do not invent a technical problem or quietly lower the agreed quality standard to preserve an earlier promise.
Can a screenshot prove the work is complete?
It can show a visible state, but it does not prove behaviour that was not exercised. A form screenshot does not show that submission or delivery works. Match the evidence to the claim and state the checks actually performed.
What if the client responds with a new request?
Record it and compare it with the baseline. Clarify the impact before treating it as the next task. Keep a new requirement distinct from the decision the update originally requested.
Sources and scope
The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.