Weekly Status Update Email to a Client: 10 Templates

A weekly status update email exists to answer one question before the client has to ask it: are we still on track. It does that job in under 30 seconds of reading, which means most of the templates below are three to six lines long, not a project report with a cover page.

The ten formats here cover the easy weeks and the hard ones. Three of them exist specifically because a week with no visible progress, or a week where the client went quiet, is where most freelancers and agencies go silent too — and silence is what actually damages the relationship, not the lack of progress.

When to send this#

Same day, same time, every week. If Friday at 4pm is your slot, it stays Friday at 4pm whether the week was great or a total write-off. A client who gets updates on a fixed cadence stops needing to ask for them — a client who only hears from you when there's good news starts wondering what's happening the other weeks.

Weekly is the default cadence for anything running longer than two or three weeks. For a one-week sprint or a fixed-scope deliverable under five days, skip the weekly format and send a single completion or handoff note instead — a cadence email on a project that's already ending reads as busywork.

Keep the subject line boring on purpose: [Project Name] — Status Update, Week Ending [DATE]. A client scanning a crowded inbox should be able to tell it's this week's update without opening it, and a search of their inbox six weeks later should turn up every one of them in order.

What a good one contains#

Every format below shares the same four ingredients, just laid out differently. Leave one out and the client has to ask a follow-up question, which is the exact extra email this template is supposed to prevent.

• A date — [WEEK ENDING], so status updates are orderable and comparable across weeks
• What actually happened — completed work, not effort or hours spent
• What's next — the next concrete thing, not "continuing work on the project"
• Anything blocking progress — named plainly, with an [OWNER] and what's [NEEDED FROM YOU]

The templates#

Ten formats, from the 30-second weekly check-in to the pause notice nobody wants to send. Copy the one that matches this week and fill in the brackets — don't send a template with a bracket still in it.

1. Three-line summary#

The default for a normal, on-track week. Use this most weeks; save the longer formats for the weeks that need them.

2. RAG status#

Red/Amber/Green is worth the extra structure once a project has multiple workstreams, or once a client has explicitly asked for "a status color" — it lets them scan five projects in a portfolio review without reading five paragraphs. Don't introduce it on a single-workstream project nobody asked for it on; it adds ceremony without adding information.

3. Done / Next / Blocked#

A slightly more detailed cousin of the three-line summary, for weeks with enough happening that one line per bucket isn't enough. Still fits in one screen.

4. Milestone burn-up#

Use this on fixed-scope projects with a defined milestone list, where a client cares more about overall completion than this week's individual tasks. It shows direction, not just a snapshot.

5. The no-progress-this-week update#

For the week where the deliverable is genuinely the same as last week's — usually because you're waiting on the client, waiting on a third party, or the work is mid-flight on something with no visible checkpoint. Send it anyway. A skipped week reads as "nothing happened," a sent one reads as "nothing new to report, and here's why."

6. Pause notice#

The hardest one to send, and the one people avoid the longest. If the project is stopping — for budget, for a client-side reorganization, for a dependency that isn't coming — say so in the subject line, not three paragraphs in.

7. Ahead-of-schedule update#

Worth its own format because good news still needs the same structure — a client shouldn't have to guess whether "ahead of schedule" means the whole project or just this week's task.

8. Scope-change notice#

For the week a request came in that wasn't in the original scope. This is a status update with one extra job: getting the change written down before it becomes "didn't we agree to that" three weeks later.

9. Multi-workstream digest#

For a project with two or more parallel tracks — design and development, or three separate features shipping on different timelines. One status line per track keeps it scannable instead of turning into a wall of text.

10. Client-action-needed reminder#

Not a full status update — a short, standalone nudge for when the project's main blocker is a decision or an asset sitting in the client's inbox. Send it separately from the weekly update so it doesn't get buried in a longer email.

The hard version of this situation#

The genuinely hard week isn't the one with bad news — it's the one where the honest update is "we don't actually know yet," or where the blocker has been open for two weeks running and repeating it a third time feels like nagging.

Two rules cover most of it. First, never let a blocker appear in a status update without a name attached — [OWNER] and [NEEDED FROM YOU] — because an unowned blocker is the one that sits open for a month. Second, if the same blocker appears three weeks running, the fourth update should say so explicitly: "this is the third week this has blocked progress; flagging in case it needs a different escalation path than email." That sentence is uncomfortable to write and it's exactly the one that gets things unstuck.

What to do if there's no reply#

A client who stops replying to weekly updates is usually not ignoring the project — they're triaging their own inbox, and a status update with no action item is easy to skim and forget. The fix is upstream of the follow-up: make the update itself easy to act on.

1. 1

   Check whether the update actually needs a reply

   A green-status, no-blocker week doesn't need one — say so explicitly ("no response needed unless something looks off") so silence isn't ambiguous.

2. 2

   Separate the blocker from the update

   If something is genuinely stuck on the client, send template 10 on its own, with a subject line that names the ask, not buried inside the weekly digest.

3. 3

   Give one specific deadline, not a general nudge

   "Any update on this?" is easy to defer. "If we don't have this by Thursday, the delivery date moves to the following Monday" gives a concrete reason to act now.

4. 4

   Escalate to a call after two unanswered asks

   Two status updates with the same unresolved blocker is the point to ask for 15 minutes live, rather than sending a third email with the same request.

A faster way to send these every week#

Everything above still works by hand — a saved draft with the brackets filled in each week is a perfectly good system. What gets tedious is the surrounding work: finding what actually shipped this week across a scattered thread, remembering which blocker is now three weeks old, and getting the update out at the same time every Friday without it slipping to Monday.

AI Emaily drafts the weekly update from your Personal Context and the week's thread history — pulling in what actually happened rather than what you remember happening — and you approve it before it sends; nothing goes out without a review. We build AI Emaily. It won't invent a status you didn't tell it, and it won't send anything on its own — Copilot mode holds every draft for your review first.