Communication
Writing Weekly Client Updates That Clients Actually Read
A simple structure, a copy-ready template and writing tips for weekly client updates that are short, scannable and lead to decisions.
By Clientwharf TeamPublished 7 min read
On this page
Why weekly updates get ignored
Most freelancers and agencies know they should send regular updates. Fewer know why theirs go unread. The usual reasons are easy to recognize:
- They read like a diary. A long list of everything the team touched, in the order it happened, with the important part in paragraph four.
- They don't ask for anything. The client can't tell whether they need to act, so they don't.
- They arrive at random. One update on Tuesday, the next nine days later, a third in the middle of a thread about something else.
- They are hard to find later. When the client wants to check what was agreed, the update is buried in an inbox.
None of these are writing talent problems. They are structure problems, and structure is easy to fix.
What a weekly update is for
A weekly update has three jobs, in this order:
- Tell the client where the project stands in one glance.
- Get the decisions and inputs you need from them this week.
- Create a record that both sides can look back on.
Everything in your update should serve one of those jobs. If a sentence doesn't, cut it.
It also helps to remember how people read on screens. Nielsen Norman Group's research found that most web users scan rather than read word by word, and it recommends meaningful subheadings, bulleted lists, one idea per paragraph and putting the conclusion first (NN/g). Your client is reading your update between meetings, on a phone, with twenty other messages waiting. Write for that reader.
A five-part structure that works
Use the same five parts every week. Clients learn where to look, and you spend less time deciding what to write.
1. Status in one line
Start with a single sentence that answers "Are we on track?" For example: "On track for the October 24 launch; we need your feedback on the homepage by Wednesday." This follows the inverted pyramid approach of putting the most important information first, so readers get the main point even if they stop early (NN/g).
If you like status labels, keep them simple and honest: on track, at risk or off track. Explain any label other than "on track" in the same line.
2. Needed from you
This is the section clients act on, so put it second, not last. List each item with an owner and a date:
- Approve the homepage design (Dana) by Wednesday, October 15
- Send the final pricing copy (Sam) by Thursday, October 16
If you need nothing, say so: "Nothing needed from you this week." That sentence alone reduces anxious follow-up emails.
3. Done this week
Three to five bullets describing outcomes, not activity. "Finished the product page layout, ready for review" is useful. "Worked on product page" is not. Link to the files or previews so the client can see the work without asking.
4. Next week
Two to four bullets about what you'll work on and anything the client will see. This sets expectations and makes next week's update easy to write.
5. Risks and changes
Anything that could affect dates, budget or scope, plus any change requests that came up. Keep each to one or two sentences: what happened, what it affects and what you suggest. If a change adds work, this is where you note it, so it doesn't slip in unnoticed. Our guide on managing scope creep covers how to handle those conversations.
A copy-ready template
Adapt this to your project and keep it saved somewhere you can reuse it each week:
Weekly update: [Project name], week of [date]
Status: [On track / At risk / Off track]. [One sentence on why and what matters most.]
Needed from you
- [Action] ([person]) by [day, date]
- [Action] ([person]) by [day, date]
Done this week
- [Outcome, with link]
- [Outcome, with link]
Next week
- [Planned work]
- [What the client will see, and when]
Risks and changes
- [Issue]: [impact]. [Proposed next step.]
A filled-in example
Here is how that looks for a small website project:
Weekly update: Northwind website, week of October 6
Status: On track for launch on October 24. The one thing we need is homepage approval by Wednesday.
Needed from you
- Approve the homepage design (Dana) by Wednesday, October 15
- Send final copy for the pricing page (Sam) by Thursday, October 16
Done this week
- Homepage design v2 is ready for review, with your comments from last week applied
- Contact form now sends to your sales inbox; test it from the staging link
Next week
- Build the pricing and about pages
- You'll get a staging link for both on Friday
Risks and changes
- The new testimonials section you mentioned is not in the original scope. We estimate it at one extra day. Let us know if you'd like a quote or prefer to add it after launch.
The client can read this in under a minute and knows exactly what to do.
Writing tips that make updates easier to read
Front-load every line. NN/g's research on scanning suggests that readers often take in only the first words of headings and lines, and it recommends starting them with the most informative words (NN/g). Write "Homepage approval needed by Wednesday", not "As discussed, when you have a moment, it would be great if…".
Use plain language. The U.S. government's plain language guidance recommends shorter words, familiar terms and the active voice, which it says "makes it clear who should do what". That is exactly what an update needs. Replace internal jargon ("QA'd the CMS templates") with what it means for the client ("checked that every page template works when you edit content").
Use real dates. "By Wednesday, October 15" is clearer than "early next week" or "EOW". Include the weekday and the date, since either alone can be misread.
Link, don't attach. Attachments get lost and duplicated. Link to the file or preview in the place where the project's files live.
Bold sparingly. Bold the action items and the status, nothing else. When everything is bold, nothing stands out.
Keep a consistent subject line. "Weekly update: Northwind website, week of October 6" is easy to search for later.
Choose a rhythm and keep it
Consistency builds trust faster than polish. Pick a day and time and send the update then, every week, even when progress is small.
- End of week works well for summarizing progress and setting up the next week.
- Start of week works well when clients need to plan their own time around your requests.
Whichever you choose, avoid holding the update until something impressive happens. A short note on a quiet week ("Mostly behind-the-scenes work on the booking system; you'll see it in staging next Friday") keeps the client informed and avoids the silence that makes people worried.
How to deliver bad news
Every project has weeks where something slips. The weekly update is the right place to say so, early and plainly:
- Lead with it. Put the problem in the status line. Don't hide it under "Done this week".
- State the impact. Which date, deliverable or cost is affected, and by how much.
- Explain briefly. One or two sentences on the cause, without blame.
- Offer options. For example, keep the date with a reduced scope, or keep the scope with a new date.
- Ask for the decision you need, with a date.
Example: "At risk: the payment page will be two days late because the provider's test account took a week to arrive. We can keep the October 24 launch by launching without the gift card option, or move launch to October 28 with it. Please let us know which you prefer by Thursday."
What to leave out
- Detailed hour logs, unless the client asked for them
- Internal debates and every option you considered
- Long explanations of technical work the client doesn't need to understand
- Anything better handled in a quick call, such as sensitive feedback about a person
If a client wants more detail, they'll ask. Then you can point them to the files, notes or timesheet.
Make updates easy to find later
The third job of a weekly update is to create a record. That works only if the record is easy to find. Email threads are a poor archive: updates get mixed with unrelated messages, and new team members on the client side never see the history.
A dedicated place for updates solves this. In Clientwharf, for example, you post progress updates to a client's private portal, and the client sees them as a clean updates timeline alongside the project's files, approvals and requests. Clients can comment on an update, and the history stays in one place. Whatever tool you use, the principle is the same: one location per client, in date order.
Weekly update checklist
Before you send, check that your update:
- Starts with a one-line status
- Lists anything needed from the client, with owners and dates
- Describes outcomes, not activity
- Says what happens next week
- Flags risks and scope changes plainly
- Links to files instead of attaching them
- Uses real dates and plain language
- Can be read in under two minutes
- Goes out on the usual day
Good weekly updates are not long or clever. They are predictable, short and honest, and they make it easy for the client to do their part. If the "Needed from you" section is where things tend to stall, our guide to getting client approvals faster is a useful next step.
Frequently asked questions
How long should a weekly client update be?
Short enough to read in under two minutes. For most projects that means a one-line summary and a handful of bullets. Link to files and details instead of pasting them in.
What day should I send weekly updates?
Pick a day and keep it. Many teams choose the end of the week to summarize progress, or the start of the week so clients can plan. Consistency matters more than the specific day.
Should I still send an update if nothing happened this week?
Yes, keep it short. A two-line note explaining what is in progress and what happens next is better than silence, which clients tend to read as a problem.
How do I share bad news in a weekly update?
Put it near the top, state the impact on dates or scope plainly, explain what you're doing about it and say what decision, if any, you need from the client.
