Status updates get skipped because writing them feels like work with no output. The fix is to stop composing them. A status update is a form with four fields, and once you can see the fields, the message takes under a minute.

The four-part structure

  1. Where it is

    The stage, in the words the client understands. One short sentence.

  2. What changed

    What moved since they last heard from you. If nothing moved, say that — it is still an answer.

  3. What happens next

    The next step and roughly when. This is the part that prevents the follow-up email.

  4. What you need

    Anything outstanding from them, stated plainly. If nothing, say "nothing needed from you" — clients read silence as a request.

When work has moved forward

Standard progress updateCopy and adapt · {{fields}} are yours to replace

Subject {{project}} — moved to {{stage}}

Hi {{first_name}},

{{project}} has moved to {{stage}}.

What changed: {{what_changed}}
Next: {{next_step}}, expected {{date}}.

Nothing needed from you right now — I will come back when it moves again.

{{your_name}}
Milestone reachedCopy and adapt · {{fields}} are yours to replace

Subject {{milestone}} is done — here is what happens next

Hi {{first_name}},

{{milestone}} is complete as of today.

That means {{plain_language_consequence}}. The next stage is {{next_stage}}, which usually takes {{duration}}.

I will send the next update on {{date}}.

{{your_name}}

The second line matters more than the first. Clients rarely know what a completed milestone means for them until you say it.

When nothing has moved

This is the message most people skip, and it is the one that does the most work. Silence during a slow stretch is when clients start to worry, and a worried client sends three emails instead of one.

No change this weekCopy and adapt · {{fields}} are yours to replace

Subject {{project}} — no change, next update {{day}}

Hi {{first_name}},

Quick one: {{project}} is still at {{stage}}. This stage typically runs {{duration}}, so this is on track rather than stuck.

Nothing is blocked and nothing is needed from you.

Next update {{day}}.

{{your_name}}
Waiting on a third partyCopy and adapt · {{fields}} are yours to replace

Subject {{project}} — waiting on {{third_party}}

Hi {{first_name}},

{{project}} is with {{third_party}} and we are waiting on their response. Submitted {{date_submitted}}; their usual turnaround is {{duration}}.

I have {{what_you_did_to_chase}}. There is nothing further either of us can do to speed this up, so I would suggest we check in again on {{date}}.

{{your_name}}

Naming what you already did to chase is what stops the client asking you to chase.

When you are waiting on them

The failure mode here is politeness that obscures the ask. If the client has to read twice to work out what you need, the document arrives late or not at all. Put the request on its own line and make it specific.

First requestCopy and adapt · {{fields}} are yours to replace

Subject One thing needed to move {{project}} forward

Hi {{first_name}},

{{project}} is ready to move to {{next_stage}}. To do that I need one thing:

  • {{specific_item}}

Once that arrives, {{what_happens_next}} — usually within {{duration}}.

{{your_name}}
Second request, with the cost of delayCopy and adapt · {{fields}} are yours to replace

Subject Still need {{specific_item}} for {{project}}

Hi {{first_name}},

Following up on {{specific_item}}, which I asked about on {{date}}.

The file is paused at {{stage}} until it arrives. If it reaches me by {{deadline}}, we stay on track for {{target_date}}. After that, {{honest_consequence}}.

If it is easier to send a photo or a partial version, that works — I can start with that.

{{your_name}}

The last line removes the most common reason people do not reply: they are waiting until they can send the complete, perfect version.

When something has gone wrong

Delays damage relationships far less than discovering a delay late. The structure that works is: the fact, the cause, the new date, and what you are doing. Apologising at length before stating the fact makes the reader anxious for longer.

Delay noticeCopy and adapt · {{fields}} are yours to replace

Subject {{project}} — new date of {{new_date}}

Hi {{first_name}},

{{project}} will not make {{original_date}}. The new date is {{new_date}}.

Cause: {{cause_in_one_line}}.
What I am doing: {{action}}.
What this changes for you: {{impact_or_none}}.

Sorry for the change. I would rather you heard it now than closer to the date.

{{your_name}}

When the work is finished

Completion and handoverCopy and adapt · {{fields}} are yours to replace

Subject {{project}} is complete

Hi {{first_name}},

{{project}} is complete as of {{date}}.

What you have: {{deliverables}}
Where it is: {{location}}
{{outstanding_payment_line}}

If anything needs adjusting, reply here and I will pick it up.

{{your_name}}

Keep any outstanding balance on its own line. Burying it in a paragraph is the most common reason a final invoice sits unpaid for a fortnight.

Making these stick

Before you send any status update

  • Does it name the current stage in words the client uses?
  • Does it say what changed, or explicitly that nothing did?
  • Does it give a next step and a rough date?
  • Does it state what you need — or that you need nothing?
  • Could someone unfamiliar with the project understand it?
  • Did it take under two minutes to write?

If the last item fails, the template is wrong for your work — shorten it. A template you rewrite every time is not a template, and within a month you will be back to sending updates only when someone asks.