# Weekly client project update template

Start from the last update actually sent. Reconcile every open commitment with current evidence.
Use the project's agreed cadence and escalation path. Reporting labels below are suggested wording,
not ProjectHubs status values. All completed examples are fictional, not customer evidence.

## Blank 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

Repeat per relevant deliverable:

- Item / scope revision / submitted version:
- Current state: In progress / Correction required / Awaiting client review / Accepted
- Evidence or decision reference:
- Next action / owner / target:
- Release or deployment state and evidence, if relevant:

### Decisions needed

Repeat per decision:

- Stable decision ID / question:
- Options and recommendation:
- Decision maker / response target:
- Original response target and follow-up history, if carried forward:
- 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:
- Superseding decision reference, if applicable:

### Next period

- Planned work / owner / target / dependencies:
- Work that can continue while a decision is pending:
- Next update date:
- Earlier escalation trigger and agreed route:

## Completed fictional example: U-01

Project: Wholesale orders portal
Reporting period: 29 June-3 July 2026
Issued: 6 July 2026
Prepared by: Delivery lead
Recipients: Authorized client owner and designated reviewers
Previous update: Start of this two-cycle example

### Summary

CSV export needs a filter correction. A client review session is proposed for 10 July;
the reviewer and time are unconfirmed. Scope S4 / CR-014 revision 2 remains the baseline.

### Deliverable

- CSV export / S4 / build B17.
- State: Correction required.
- Requirement: Apply the selected status and date filters.
- R-014 revision 1: Prepared data has eight paid and four pending orders within the date range.
  Selecting paid orders exports twelve rows, including four unwanted pending rows.
- Correction C-01: Engineering lead owns assessment and correction.
- Target corrected submission: 8 July, subject to required checks completing.
- Release/deployment state: Not established by this review example.

### Decision D-02

- Question: Confirm an authorized reviewer and 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.
- Consequence: The proposed review session cannot be confirmed until the response is recorded.
- Follow-up: Delivery lead checks the response on 7 July.

### Next period

- Engineering submits a corrected build with fresh evidence.
- Engineering correction can continue while D-02 is pending.
- Saved filter 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.

## Completed fictional example: U-02

Project: Wholesale orders portal
Reporting period: 6-10 July 2026
Issued: 13 July 2026
Prepared by: Delivery lead
Recipients: Same intended client recipients as U-01, subject to access review
Previous update: U-01, issued 6 July

### Summary

Corrected CSV export submitted on B18. Client review is pending.
The proposed 10 July session was not confirmed. S4 remains unchanged.

### Deliverable

- CSV export / S4 / B18, submitted 8 July.
- State: Awaiting client review.
- Evidence: R-014 revision 2 / E18 records repeated checks; the paid-order check returns eight matching rows.
- Preserve B17's failed result and C-01 alongside the replacement evidence.
- Client acceptance: No decision recorded at the reporting cutoff.
- Next action: Client reviewer reviews B18 after D-02 is resolved; delivery lead coordinates support.
- Release/deployment state: Not established by this review example.

### Decision D-02 carried forward

- Question: Confirm reviewer and review slot. Still open at cutoff.
- Original response target: 7 July.
- Follow-up history: Delivery lead followed up on 7 and 10 July; no confirmation recorded.
- Options: Confirm the newly 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. Preserve the original target above.
- Consequence: Review remains pending and acceptance timing is unconfirmed.
- Follow-up: Delivery lead contacts the client owner on 14 July.

### Changes since U-01

- Correction: B17 failure now has a B18 engineering recheck in R-014 revision 2 / E18.
- Proposed review: 10 July was not confirmed; 15 July is now proposed.
- Agreed review date: Still unconfirmed.
- Scope: S4 unchanged; saved presets remain deferred.
- Acceptance: Still awaiting a client decision.

### Next period

- Support review and record the actual 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.

## Working reconciliation before U-02

| Previous line | Current evidence | Reported position |
| --- | --- | --- |
| B17 correction C-01 | B18 submitted; E18 recheck recorded | Awaiting client review |
| D-02, target 7 July | Follow-ups 7 and 10 July; no confirmation | Still open with history and revised response target |
| Proposed 10 July review | Slot was not confirmed | 15 July proposed; agreed date unconfirmed |
| Presets deferred | No later scope decision | Deferral remains in effect |

## Before sending

- Check every unresolved line from the last sent report.
- Verify dates, scope, submitted versions, evidence and decision records.
- Identify accepted, replaced or withdrawn decisions explicitly; preserve their references.
- Open client-facing links with the intended access level.
- Remove internal-only and unrelated client information.
- Confirm response targets, follow-up owners and escalation arrangements.
- Save the actual sent update and delivery reference for the next reporting cycle.

## Background

[Atlassian project-status template](https://www.atlassian.com/blog/wp-content/uploads/Atlassian-Project-Status-template.pdf)
keeps original and revised expected dates alongside actions, risks and dependencies.
The worked example here is a suggested adaptation for software client reviews.