Client project status updates: progress, risk and decisions

A project status update for a client should explain the completed outcome, remaining work and any decision they need to make. Do not replace it with an internal board screenshot or an unsupported percentage. Build the message from verified facts about the agreed deliverable.

Start with the question the client needs answered

The team is delivering three service pages and the client asks “how are we doing?”. They may need to know what to review, whether to supply copy or whether the earlier plan remains feasible. Ten task names do not automatically answer those questions. Identify the stage outcome and what the recipient needs for their own action.

Avoid sending only column names and technical language used by performers. The client need not understand team organisation to recognise “two pages ready for review, the third awaiting copy”. B2B customer support covers organisational communication. This update explains delivery state rather than copying every internal action, particularly when those actions do not affect the client’s next decision.

Before writing, identify the stage you are discussing. A project may contain separate work for a later month while the client asks about the current three pages. Do not present other tasks as delays to this deliverable. The update boundary should match current agreements rather than every item in the workspace, so the completed scope remains visible.

Collect five fields for a specific update

Prepare a small card manually from the latest agreements. Each field answers a recipient question: completed result, remaining work, blocker, decision and next check.

Do not turn “working on it” into a completed outcome. A scheduled task does not become done merely because an owner is already assigned; report the actual result rather than its preparation.

↔ Scroll the table sideways to see all columns.

If page A is in a test environment, call it ready for review rather than publicly available. Review readiness and publication are different outcomes. Comments gathered after that review are easier to manage with the guide to website design feedback from clients.

Provide a review location only when the recipient actually has access. A link is not proof of readiness until its relevant access and contents are checked, especially when the team can open it but the client cannot.

The first days working with a client cover initial agreements. A status card uses their current version. If scope changed later, preserve that difference in the comparison so the client does not receive a report about work they no longer expect. The title may remain similar while its agreed deliverable has changed.

Check information currency before sending the summary

Yesterday’s comment may be accurate for yesterday’s stage but not today’s response. The team could have received copy or found a problem in a supposedly ready view.

Read the latest result for the reported scope. Do not send an old blocker list without checking that it remains applicable; a copied update can contradict the actual work.

1. Select the reported outcome.Identify the stage the client asks about. Separate later scope from current delivery.
2. Confirm the ready portion.Check what can actually be shown or treated as complete. A finished draft is not automatically published.
3. Verify the remaining obstacle.Establish the missing text, decision or team action. Do not assign the blocker to the client without a current check.
4. Identify the next action.Name the real operation and responsible person. Separate a planned check from guaranteed completion.

A done task may concern only one portion of the stage. Inspect the outcome description, not just its colour. From support request to task explains connecting conversation source and work.

The update should refer to what was checked rather than a default interpretation of status, including any remaining review needed before publication.

A complete three-page update with one decision

Template: “Pages A and B are prepared for the agreed review at the location identified in our conversation. These are review views, not publication confirmation. For C, we have the layout and draft description but no selected text for use. Please confirm the C description version. After that decision, we will check completeness and establish the next available delivery action.”

Continue the same message: “Please do not resend the logo or A and B content; we have those materials. If C requires a scope change, identify the difference before we proceed. We are not currently confirming a new date for the entire stage. The next update will follow the missing-input check.” Use this only when the example matches the actual case.

When the blocker belongs to the team, change the message: “A and B are ready for review. We found a layout gap in C and are correcting it; no further material is needed from you now. The next action is checking the revised view.” Do not use the missing-copy version to transfer responsibility conveniently; the explanation needs to match who must act.

When the agreed stage has been checked, identify the outcome: “We confirmed the scope of A, B and C and the agreed links. The stage is ready for the next action established in our process. The separate request for another language is outside this confirmation.” Replace the general next action with the actual chosen step without implying automatic acceptance by the client.

Describe risk conditionally rather than inventing a percentage

“80% complete” explains little without a shared measurement definition. One difficult remaining decision can affect the outcome more than several finished minor actions.

Here you describe the ready portion and uncertainty affecting the remainder instead of inventing a percentage. The client can then understand what is actually usable and what prevents the next outcome.

Risk could be: “Without approved C copy, its page review cannot be completed.” This is a dependency rather than a verdict that the whole project is late. If the effect on the earlier plan needs team review, identify that stage. Do not present an assumed delay as an already agreed new date; the underlying check is still open. The same caution applies when an outage hits many customers: instead of a fix time, you give the time of the next update, as described in the guide to coordinating customer updates during an incident.

Give the client a decision they can make. “We need materials” is weaker than “select B or supply the specified C revision”. Missing client materials covers that input.

A status update need not repeat an entire file list when one answer is required; it should explain the decision’s relationship to the next result.

If a new need requires separate assessment, identify it outside the current outcome. Do not add every planned idea as unfinished current delivery. Show both the confirmed stage and new-scope boundary. This allows a discussion of impact without hiding additional work inside a summary or making the original completed result appear incomplete because another proposal exists.

Use Projects context without sending a raw board

In Meetlead Projects, descriptions, comments, status, owner and links provide task context. You need an account, website, permissions, active Projects installation and a plan with access. The team manually checks outcomes and writes the client update. The tool does not guarantee an automatic client report; the message depends on verified facts the team selects.

Do not promise a client portal, access to the whole board or automatic exports. Use the actual agreed channel and share the scope the recipient needs.

Internal comments may contain information unsuitable for that message. Preserve the response outcome so the next update refers to what was communicated, including any decision the client then supplies.

• The message concerns the current agreed stage.
• Review readiness is not called publication.
• The blocker has a particular cause and current state.
• The client can make the requested decision from the supplied information.
• Dates and percentages were not guessed.
• The next action follows the actual process.

A new request may concern correcting behaviour or adding a capability. The next guide distinguishes a bug from a new feature before that subject changes the current outcome description. Classification should precede adding it as remaining work in the reported stage, so the update retains a clear delivery boundary.

When the client needs a short answer

Must every task be described? No.

Select outcomes, risk and the recipient’s decision. Add details that explain a particular problem.

An update can be brief and unambiguous without copying the entire board. The number of internal activities does not determine what the client needs to know next.

Does no new message mean no progress? Not automatically.

Check actual work and results. If the outcome has not changed, say so with the current obstacle.

Do not invent progress merely to fill a summary. A factual unchanged state with an actionable blocker can be more useful than a vague positive update.

Can an approximate date be shared? Only with an agreed basis and conditions. Distinguish it from a guarantee and identify uncertainty affecting delivery.

Without a capability check, identify the next review point instead of inventing a date. The update should make the estimate’s limits understandable rather than conceal them in optimistic language.

Atlassian presents updates covering progress, issues and next actions. The three-page example is our proposed message: project status template.