Weekly Client Project Update Template: Carry Decisions Forward

A weekly client project update should show what changed since the previous report, which deliverables still need review and what decision the client needs to make. Start from last week's open commitments. Carry each one forward with its current evidence and next action.

Copy the template below into your existing reporting channel. The worked example follows a CSV export across two reporting cycles. A failed review gets corrected, a client decision remains open and the proposed review date changes visibly.

Copy the weekly client project update template

Write the summary after checking the underlying records. Identify the reporting period and link the previous update so a reader can follow changes. Use the client's agreed reporting cadence; weekly is a starting point for this template.

Download the editable weekly update template and two-cycle example.

CLIENT PROJECT UPDATE

Project / reporting period / report date:
Prepared by / intended recipients:
Previous update reference:

SUMMARY
Current position and the reason:
Next agreed milestone / date / current outlook:

DELIVERABLES
Item / scope revision / submitted version:
Current state: In progress / Correction required /
               Awaiting client review / Accepted
Evidence or decision reference:
Next action / owner / target:

DECISIONS NEEDED
Stable decision ID / question:
Options and recommendation:
Decision maker / response target:
Work affected / consequence if still unresolved:
Follow-up action / owner:

CHANGES SINCE THE PREVIOUS UPDATE
Previous commitment:
Current position and supporting reference:
Original date / proposed date / agreed date:
Reason for change / confirmation still needed:

NEXT PERIOD
Planned work / owner / target / dependencies:
Next update date and earlier escalation trigger:

These are suggested reporting labels, not ProjectHubs status values. Add a release or deployment state when it matters to the recipient. Name the evidence for that state rather than treating acceptance as proof that software is live.

Carry one software project through two updates

Everything in this example is fictional, including dates, records and results. The project is a wholesale orders portal. Scope S4, approved through CR-014 revision 2, includes a CSV export and defers saved filter presets. The export must respect the selected filters and the agreed access rules.

The example continues the scope-swap branch in our change request guide. It separates implementation evidence from the client's acceptance decision, as in the software sign-off checklist.

Update 1: correction required, review slot unconfirmed

The delivery lead sends U-01 on 6 July 2026. On build B17, selecting paid orders returns twelve rows from prepared data containing eight paid and four pending orders. Correction C-01 is open. The review session is proposed for 10 July, but the client has not confirmed a reviewer or time.

U-01 | Orders portal | 29 June-3 July 2026
Issued: 6 July 2026

Summary: CSV export needs a filter correction. A client review
session is proposed for 10 July; reviewer and time are unconfirmed.

Deliverable: CSV export / S4 / B17
State: Correction required
Evidence: R-014 revision 1 records four unwanted pending rows.
Next: Engineering lead owns C-01. Target corrected submission:
8 July, subject to the required checks completing.

Decision D-02: Confirm an authorized reviewer and a review slot.
Options: Confirm 10 July, or propose an alternative slot.
Recommendation: Confirm 10 July if the reviewer is available.
Decision maker: Client owner. Response target: 7 July.
Impact: The proposed review session cannot be confirmed yet.
Follow-up: Delivery lead will check the response on 7 July.

Next: Submit the corrected build with fresh review evidence.
Saved presets remain deferred under CR-014 revision 2.
Next routine update: 13 July. Escalate earlier if the corrected
submission or proposed review session can no longer be supported.

D-02 has a stable identifier because it may appear again. The update gives the client a specific response to make. It also keeps the correction with the engineering lead; the pending reviewer decision does not explain the filtering defect.

Update 2: corrected build submitted, the same decision still open

On 8 July, the team submits B18 with evidence pack E18. The repeated paid-order check returns the expected eight rows. The delivery lead follows up on D-02 on 7 and 10 July. At the 13 July reporting cutoff, the client has not confirmed a review slot.

U-02 | Orders portal | 6-10 July 2026
Issued: 13 July 2026 | Previous update: U-01

Summary: Corrected CSV export submitted on B18. Client review
is pending. The proposed 10 July session was not confirmed.

Deliverable: CSV export / S4 / B18
State: Awaiting client review
Evidence: R-014 revision 2 / E18 records the repeated checks.
The paid-order check returns eight matching rows.
Next: Client reviewer reviews B18 after D-02 is resolved.
Client acceptance: No decision recorded at this cutoff.

Decision D-02: Still open. Confirm reviewer and review slot.
History: Response target 7 July; follow-ups 7 and 10 July.
Options: Confirm proposed 15 July slot, or provide an alternative.
Recommendation: Confirm 15 July if the reviewer is available.
Decision maker: Client owner. Revised response target: 14 July.
Impact: Review remains pending; acceptance timing is unconfirmed.
Follow-up: Delivery lead contacts client owner on 14 July.

Change: Proposed review moved from 10 July to 15 July.
Agreed review date: Not yet confirmed.
Correction: C-01 engineering recheck recorded against B18.
Scope: S4 unchanged. Saved presets remain deferred.

Next: Support client review and record its outcome against B18.
Next routine update: 20 July. If D-02 remains open on 14 July,
use the agreed escalation path and reassess the proposed slot.

B18's evidence supports the engineering recheck. The report still says “awaiting client review” because no client acceptance is recorded. Keep the B17 failure and C-01 history available when linking the replacement evidence.

The revised response target does not erase 7 July. U-02 preserves that date and the follow-ups. It also names 15 July as a proposal. The client can see what moved and what still needs confirmation.

Reconcile the previous report before writing the next one

Take each open line from U-01 and find its current record. The following comparison is the working check behind U-02.

Give every earlier commitment a supported current state. If a decision has been made, record its outcome and reference. If a later decision replaces it, identify the replacement. If evidence is missing, name the question and investigation owner.

Atlassian's project-status template keeps original, current and newly expected completion dates alongside actions, risks and dependencies. The comparison above applies that useful date history to a client review decision.

Explain a blocker without assigning blame

“Waiting on client” leaves the next step unclear. D-02 states who can respond, which response is needed and what remains unconfirmed. Report the observed condition and its effect on the work.

Separate what can continue from what depends on the response. In U-01, engineering can correct the filter while the client arranges a reviewer. In U-02, the team can prepare review support, but it cannot record an acceptance decision on the client's behalf.

Use the project's agreed escalation route when a response target passes. A security incident or a threatened milestone may need an earlier message than the next routine update. Record the follow-up and any resulting decision in the same project record.

Check the version the client will receive

Before sending, verify each build, date and decision reference against its source. Open the intended attachments with the client's access level. Share a suitable client-facing record when the working evidence includes internal material.

• Keep internal rates, staffing debates and unrelated client information out of the update.
• Check that a completed task has the evidence needed for the state you report.
• Retain unanswered decisions with their original references and follow-up history.
• Save the actual sent version so the next cycle starts from what the client received.

A prepared report remains a draft until it has been sent. Keep preparation and delivery records distinct if the team later needs to establish when the client was informed.

Use the template on your next reporting cycle

Open the last update your client received. Choose one unresolved decision and one deliverable awaiting review. Complete their current state from the evidence, then write the summary. An email thread and your existing tracker may be enough when those references stay connected.

ProjectHubs is being developed around delivery records, client visibility and human decisions. The product overview explains that direction. Confirm available capabilities in a walkthrough.

Bring two consecutive client updates to a ProjectHubs walkthrough. Use them to identify where a changed commitment or an unanswered decision becomes hard to follow.