How agencies keep clients updated on project progress

Agencies keep clients updated with a small, predictable system that both sides agree at kickoff. Set a cadence and channel, keep a client-facing view of progress against each deliverable, send a short update in the same format every time, and end each update with what the client needs to decide, review, or help with, and by when.

What does a client update system include?

A client update system has a few fixed parts: a place where current progress always lives, a short written update on a set rhythm, a call kept for discussion, and a running record of decisions and approvals. Each part has its own job, so the client always knows where to look for progress, requests, and past sign-offs.

• A status view: one place showing each deliverable, where it stands, and the evidence behind it (a link to the draft, the build, the test result). This is the source of truth, and everything else points to it.
• A written update: a short email on a fixed day that says what changed, what is next, and what you need from the client.
• A call: kept for discussion, reviews, and decisions.
• A decision log: every decision and sign-off the client has given or still owes, with dates. The fields are in the decision log section below.

ActiveCollab argues that a shared progress report can replace repeated check-in meetings, emails, and calls. That is the aim here: the written update and the status view carry the routine information, so meetings can be about choices.

Which channels should agencies use for client updates?

Use email for any client update that needs a reply, a client-facing status view for current progress, and a scheduled call for tradeoffs and decisions. For agencies, a shared chat channel works well for quick questions and coordination, while approvals belong in email, where the decision and its date stay easy to find later.

Share progress where clients already are, through a link they can open without an account. Breeze makes the case that clients often resist adopting an agency's software, and suggests guest links and views that need no account. Before you share any view, check that it holds only client-ready notes.

A shared chat channel with the client sits right beside your team's internal channels, so a message meant for colleagues can land in front of the client. Keep shared client channels separate from internal channels, and move any sign-off from chat into email.

How often should you update clients in each project phase?

Send clients a written update weekly or biweekly while work is active, with an extra update at each milestone and a lighter rhythm for long-running work. Breeze suggests weekly or biweekly for active projects and monthly for long-term work, and Lucen recommends weekly or biweekly with ad hoc updates at milestones.

Adjust the rhythm to the phase instead of fixing one cadence for the whole engagement:

Agree this table with the client at kickoff. The LinkedIn collaborative article makes the same point: settle frequency and format at the start and stick to them. The kickoff agreement note further down gives you a place to record it.

What goes in every client update?

Open every client update with a one-sentence status, then list what was done, what comes next, what is waiting on the client, and the decisions needed with dates. Keeping the same sections in the same order each time lets the client find the request quickly and forward the summary to their own leadership unchanged.

Lead with the health summary because your contact often passes it on. Lucen points out that the person you update often has to share it with executives who are not familiar with project management, so plain language matters. ActiveCollab lists status, blockers, budget, wins, and next steps as the core of a work-in-progress report.

How do you choose the status label?

Choose the status label by testing the next milestone date and the budget against three agreed definitions: on track, at risk, and off track. Writing these definitions down once and sharing them with every lead means each client account uses the same labels, so a client reading two updates from your agency sees the same meaning.

• On track: the next milestone date holds, and anything waiting on the client is still within its reply-by date.
• At risk: a milestone date is in doubt, or a client item is late but the date can still be kept with a decision or extra help.
• Off track: a milestone date or the budget will be missed unless the client agrees a change in scope, date, or budget.

When a lead is unsure between two labels, pick the less comfortable one and explain why in the status sentence.

What does a good client update look like?

A good client update fits on one screen: a subject line carrying the status label, a one-sentence summary, short lists of done, next, and waiting on the client, then any decision with options, a recommendation, a reply-by date, and the default action. The format below is a copyable template, followed by an illustrative on-track version.

Subject: [Project name] update, [date]: [On track / At risk / Off track]

Status: [One sentence on overall health and the next milestone date.]

Done since last update:
- [Deliverable]: [what changed] ([link to evidence])
- [Deliverable]: [what changed] ([link to evidence])

Next:
- [Deliverable]: [what happens next], due [date]

Waiting on you:
- [Item, e.g. brand assets / content / access], needed by [date] so [milestone] stays on [date]

Decision needed:
- [Question], options [A] or [B]. We recommend [A] because [reason].
  Please reply by [date]. If we have not heard by then, we will [default action].

Budget: [Within budget / note on change, with link to change request]

Full status: [link to status view]

The last line of the decision block matters most. Saying what happens if there is no reply turns a vague request into a clear choice.

This on-track example is illustrative. Every name, date, and link is a placeholder to replace with your own.

Subject: [Project name] update, [date]: On track

Status: On track. [Milestone] is set for [date], and your review of [Deliverable 1] is the next step.

Done since last update:
- [Deliverable 1]: second round of revisions finished and ready for your review ([link to draft])
- [Deliverable 2]: [section] moved to the test environment ([link to test site])

Next:
- [Deliverable 1]: final version for your sign-off, due [date]
- [Deliverable 2]: remaining sections in testing by [date]

Waiting on you:
- [Asset or access] for [section], needed by [date] so [milestone] stays on [date]

Decision needed:
- [Question about Deliverable 1]: [option A] or [option B]. We recommend [option A] because [reason].
  Please reply by [date]. If we have not heard by then, we will go ahead with [option A].

Budget: Within budget.

Full status: [link to status view]

Who owns the client update?

Make the project or delivery lead the owner of every client update: the lead sends it, signs it, and answers for its content. The team supplies the facts by keeping tasks and evidence current, and a senior reviewer checks any at-risk or off-track update before it reaches the client.

1. Team members update their tasks and attach evidence before an agreed cutoff, such as the afternoon before the update goes out.
2. The lead drafts the update from that evidence, adds the decisions and asks, and sends it.
3. An account or practice lead reviews any at-risk or off-track update. ActiveCollab recommends a check for accuracy and positioning so internal-only remarks stay internal.
4. A named backup sends the update when the lead is away, using the same format.

How do you keep updates accurate without rebuilding reports by hand?

Draft each client update from the task tool where the team already records tasks, deliverables, and evidence. When that record stays current, preparing the weekly client update becomes a review of what changed since the last one, and the lead can spend the time on the client's language and the decisions needed.

• Map each client deliverable to the tasks or tickets behind it, so progress rolls up without retyping.
• Ask the team to attach evidence (a link, a file, a demo) when they close work.
• Use your tool's saved filters or views to list what changed since the last update.
• Draft from that list, then edit for the client's language. AI drafting helps here when the lead reviews and directs every draft before it goes out.
• Copy each decision and sign-off from replies into the decision log on the day it arrives.

Before sending, the lead runs through a short review:

Pre-send review for [Project name], [date]
[ ] Items whose status changed since the last update are all listed under Done or Next
[ ] Every deliverable marked done has evidence attached or linked
[ ] Client items past their reply-by date are named, with what moves as a result
[ ] Decisions answered since the last update are in the decision log and reflected in Next
[ ] The status label matches the agreed definitions
[ ] Nothing internal (margin, staffing, internal debate) appears in the email or the shared view

How do you tell a client a project is at risk?

Write to the client as soon as a milestone comes into doubt, ahead of the scheduled update, and follow with a call. An at-risk update states the cause, the impact on dates or budget, your recommended fix, and the decision you need, so the client can act on it from the email alone.

Illustrative wording:

Subject: [Project name]: [milestone] at risk, decision needed by [date]

[Milestone] is now at risk of moving from [date] to [date].
Cause: [plain description, e.g. content for [section] arrived after the review window].
Impact: [what moves, and any budget effect].
Options:
  A. [Keep the date by reducing scope to X]
  B. [Keep scope and move the date to Y]
We recommend [A/B] because [reason].
Please choose by [date]. I have held time on [day] if a call would help.

If the fix changes scope or budget, link the change request in the same email and record the client's choice in the decision log.

How do you tell a client a project is off track?

Tell a client a project is off track in an email, copied to the person who controls budget or scope, as soon as the lead knows a milestone date or the budget will be missed. The off-track email names the cause, the impact, the options (reduce scope, move the date, or approve a change request), and a reply-by date.

Have your account or practice lead review the email before it goes, then offer a call the same week. Illustrative wording, with placeholders only:

To: [Primary decision owner at client]
Cc: [Client budget or scope owner], [Your account or practice lead]
Subject: [Project name]: [milestone] off track, decision needed by [date]

Status: Off track. [Milestone] will miss [date] and/or the budget will exceed [amount] unless we agree a change.
Cause: [plain description of what happened and when we found out].
Impact: [Milestone] moves from [date] to [date]. Budget effect: [amount, or none].
Options:
  A. Reduce scope: defer [item] to [later phase], keep [date] and the agreed budget.
  B. Move the date: keep full scope, deliver on [new date], budget [unchanged / plus amount].
  C. Approve a change request: add [time or people] to keep scope and [date], at [amount].
     Change request: [link]
We recommend [A/B/C] because [reason].
Please reply by [date]. Until we hear from you, we will [hold work on X / continue on Y].
I have held [time] on [day] to talk it through.

Budget overruns and scope changes often arrive on their own, outside an off-track update. These two blocks drop into any update:

Budget: [Phase or deliverable] has used [amount] of [amount]. At the current rate we expect
to finish at [amount], which is [amount] over the agreed budget, because [reason].
Options: [reduce scope to X] or [approve the change request: link]. Please reply by [date].

Scope change: On [date] you asked for [new item]. It sits outside the agreed scope.
Adding it moves [milestone] to [date] or adds [amount]. The change request is here: [link].
We will start on [new item] once you approve it, and keep [current work] on plan until then.

Whichever option the client picks, add it to the decision log with the date and a link to their reply.

What should a sponsor decision log record?

A sponsor decision log records every decision and sign-off the client has given or still owes: when it was raised, who at the client owns it, the reply-by date, the default if no reply arrives, the outcome, and a link to the email or change request. Keep one decision log per project, next to the status view.

A shared spreadsheet or a page in your existing tool works. Copy these columns:

| Date raised | Decision or sign-off | Owner at client | Reply-by date | Default if no reply | Outcome and date | Link to email or change request |
|---|---|---|---|---|---|---|
| [date] | [e.g. approve [deliverable] for launch] | [name, role] | [date] | [default action] | [approved / changed / open], [date] | [link] |

The log turns a disputed memory into a lookup. When a client asks why a date moved, point to the row.

What do you do when a client stops responding?

When a client stops responding, resend the single decision in a shorter form, restate the reply-by date and what you will do if no answer arrives, and then widen the audience in steps you agreed earlier. Agreeing those follow-up steps at kickoff means following up on a quiet client is simply the shared plan.

1. Resend the single decision on its own, with the reply-by date and the default action.
2. working days before the reply-by date, send a short reminder that names what moves if there is no answer. In Unblockd, asks to the sponsor by email get "a first reminder after 3 days and another the day before the deadline, up to 3 automatic reminders per ask."
3. If the date passes, apply the default you stated, tell the client you have done so, and update the status view and decision log.
4. If the blocker is still open, raise it with the client's sponsor or account owner through the escalation route you agreed.

What goes in a client kickoff agreement note?

A client kickoff agreement note records how updates will work on the account: the cadence for each phase, the day the written update goes out, the call rhythm, which channel carries approvals and which carries quick questions, who decides at the client, how escalation works, and where the status view lives. Send the note for the client's confirmation.

Copy and fill in:

Subject: [Project name]: how we will keep you updated

Hi [client contact],

Here is what we agreed at kickoff. Please reply to confirm or correct anything.

Written update: every [day], by email, to [recipients].
Cadence by phase:
- Discovery: [weekly update], call [rhythm]
- Delivery: [weekly update], call [rhythm]
- Review rounds: update at the start and close of each round
- Launch: update every [X] working days in the final [X] weeks
- After launch / retainer: [monthly summary]
Calls: [day and time], for reviews and decisions; we will cancel when the agenda is only status.
Approvals and sign-offs: by email reply to [lead name].
Quick questions: [shared chat channel name].
Primary decision owner at [client]: [name, role].
Escalation: if a decision passes its reply-by date, we will [apply the stated default],
then contact [escalation contact, role] after [X] working days.
Status view: [link]. Decision log: [link].
Status labels: on track, at risk, off track, as defined in [link or attached note].

Thanks,
[Your name]

How do you roll this out across your client accounts?

Write your agency's cadence table and update format down once, then apply them account by account, starting with the client whose project has the most decisions waiting. A shared format and decision log help that relationship first, and each later account reuses the same kickoff note, status view, and update template.

1. Write your agency's version of the cadence table, the status definitions, and the update format.
2. For each account, send the kickoff agreement note and record the client's confirmation.
3. Set up the status view and decision log for that project.
4. Send the first update in the new format and ask the client whether it gives them what they need to pass on internally.
5. Review the format with your leads after [X] update cycles and adjust.

Start with the kickoff agreement note above: fill it in for your next client account and send it before the next client meeting.