Aug 15, 2026
Updated
Written by Gregory Shein, CEO & Founder
Client Reporting for Agencies: A Weekly Update That Leads to Decisions
Build a client report around progress, remaining work and decisions. Follow a Northstar website-launch example and distinguish task counts, delivery judgement and portal access.
A useful client report answers four questions: what changed, what remains, what could affect delivery, and what decision is needed? A task board supplies some of the evidence. The project owner still has to explain what that evidence means.
Use a client reporting portal for access to the records the client is allowed to see. Use a short prepared update for the interpretation and decisions. A live chart cannot decide whether an unfinished test is a launch risk or whether a new request belongs in the agreed scope.
Start with a reporting agreement
At kickoff, agree who receives the report, which decisions they can make, the channel, the reporting day and the person preparing it. Give each update an as-of date so readers know which version of the project it describes.
| Item | Practical reporting rule |
|---|---|
| Reporting period | State the dates covered and when the records were reviewed |
| Progress | Describe completed deliverables and the work still open |
| Dates | Keep the agreed baseline separate from proposed changes |
| Risks | Name the consequence and the action to reduce it |
| Decisions | Identify the request, decision owner and response date |
| Next update | Say when the next report is due or what would trigger an earlier update |
The weekly status report template gives you a structure to fill in. Preparing or downloading that template does not send it to the client. Share the completed report through the channel you agreed.
Worked example: Northstar website launch
This fictional demonstration follows Northstar Studio (Demo) and Website launch (Demo). The reporting snapshot is 28 September 2026.
The baseline contains six delivery tasks, of which four are complete. The two remaining tasks are:
| Remaining task | Due date | What the client needs to understand |
|---|---|---|
| Test enquiry form | 2 October | The enquiry path still needs its final test |
| Approve launch | 9 October | Launch approval remains a separate decision |
4 ÷ 6 × 100 = 66.7%, displayed as 67%. This is a count of completed tasks. It does not establish that 67% of the hours, budget or risk is behind us. A final acceptance task can carry more delivery risk than several small completed tasks.
There is also a pending scope proposal, CR-001: newsletter signup. The proposal estimates 4 hours × $125 = $500. If the client approves it, the proposed launch date becomes 12 October instead of 9 October. The requested decision date is 2 October. Until there is written approval, the baseline launch date remains 9 October and the extra work remains a proposal.
A completed weekly update
The following is a prepared report for that demonstration, not an automatically generated or sent message:
Northstar website launch — update as of 28 September 2026
Progress: Four of six baseline tasks are complete (67% by task count). Two remain: Test enquiry form, due 2 October, and Approve launch, due 9 October.
Delivery assessment: Amber — a proposed scope change needs a decision before we revise the launch plan. This is the project owner's judgement, separate from the task percentage.
Current baseline: Launch remains planned for 9 October. No scope or date change has been approved.
Decision requested by 2 October: Accept or decline CR-001, adding newsletter signup for $500. Approval would move the proposed launch date to 12 October. If declined, retain the original scope and 9 October baseline.
Next actions: Complete the enquiry-form test, record the change decision, and confirm the launch approval step. Prepare the next weekly update on 5 October, or earlier if the decision changes the plan.
This report distinguishes a fact, a judgement and a proposal. That separation prevents a client from reading “67% complete” as a delivery guarantee, or treating a discussed change as an accepted commitment.
Choose a cadence by what can change
| Update | When to prepare it | What it should contain |
|---|---|---|
| Weekly delivery update | On the agreed weekday | Progress, remaining work, risks and decisions |
| Decision update | When a material scope, price or date decision is recorded | What was agreed, by whom, which version and the effect on the plan |
| Immediate exception | When waiting until the next report would remove a useful choice | The issue, consequence, options and action needed |
| Closeout report | At the agreed completion or handover point | Delivered scope, open follow-ups and acceptance record |
These are operating habits, not automatic Corcava report schedules. Assign an owner to prepare and share each report.
Use Corcava records as inputs
Review the team's project tasks, dates and relevant reports before preparing the client update. Select the intended project, people and period for time reporting. If you export a staff report, inspect its columns before sharing: a staff export can include financial fields that are not shown in a client report view.
A signed-in viewer's project assignments and associated client records affect different parts of the app. An administrator's dashboard or report is not proof of what that client account sees. Verify access using the intended account before treating the portal as your reporting channel; the client visibility guide explains the checks.
A public invoice page is another specific view. It can show an invoice's details and balance, but it is not a full client portal or a project status report. Keep invoice status separate from delivery status.
Keep the report short enough to act on
Before sharing, check five things:
- Every number has a stated basis: task count, recorded hours, invoice balance or another defined measure.
- Current commitments and proposed changes are labelled separately.
- Each open decision has an owner and a response date.
- The recipient can open every link you include with their intended access.
- The report contains no internal cost, unrelated client information or commentary you did not intend to share.
For the Northstar case, the useful outcome is a clear decision on CR-001 and a checked delivery plan. It is not a longer dashboard. Continue with the change request workflow, the client portal requirements checklist or Corcava's client portal overview.