What a Good Friday Client Report Actually Contains

Most Friday reports are written for the person sending them, not the person reading them. They list what the team did — the meetings attended, the tickets closed, the hours logged — because that's the easiest thing to write when you're tired and it's 4:45pm. The client reads it, feels vaguely reassured, and then emails you Tuesday asking a question the report should have already answered.

That's the actual test of a weekly report: does it reduce the number of questions you get asked next week, or does it just prove you were busy this week? Those are different documents. Most people write the second one and wonder why the client still calls.

Busy is not the same as informative

A report that says "the team worked on the checkout flow, had three sync calls, and made good progress" tells the client nothing they can act on. It's not false. It's just unusable. The client can't forward it to their boss, can't make a decision from it, and can't tell from reading it whether the project is on track or quietly slipping.

A report that says "checkout now handles failed payments correctly; the retry logic still needs your decision on how many attempts before we email the customer" tells the client exactly what changed, exactly what's blocked, and exactly what they need to do. It takes about the same time to write. It's just organized around the reader's next move instead of the team's last five days.

The seven sections, in order

This is the structure I use across client accounts. The order matters almost as much as the content — it front-loads the parts a busy client will actually read and pushes the parts that exist mainly for your own protection to the bottom.

Week of [date]

1. SHIPPED
What is live, done, or delivered this week — not started, not "in progress."

2. CURRENT STATE
Where the project stands right now, in plain terms. One paragraph, no jargon.

3. EVIDENCE
A link, a screenshot, a number. Something the client can look at without asking you.

4. RISKS
What could go wrong, and what it would cost if it did. Not vague "concerns."

5. DECISIONS NEEDED FROM YOU
Specific questions with a deadline. Not "let us know your thoughts."

6. NEXT WEEK
What you'll do, contingent on the decisions above.

7. NOT DONE
What you explicitly did not do this week, and why — scope, priority, or blocked.

Seven sections sounds like a lot for a weekly email, but each one is usually two or three sentences. The whole report should fit on one screen without scrolling. If it doesn't, something in sections one through four is trying to be a status meeting instead of a report.

Section 7 is the one everyone skips, and it's the one that saves you

"Not done" feels like admitting failure, so most people leave it out. That's backwards. If you don't say what you didn't do, the client assumes everything they asked for is being handled and finds out otherwise three weeks later, at the worst possible moment. A single line — "we did not start the admin dashboard redesign this week; it's scheduled for next sprint" — costs you nothing and prevents a much worse conversation later.

An annotated sample

Here's what it looks like filled in, for a fictional but typical mid-project week.

Week of March 3

SHIPPED
- Checkout now correctly handles declined cards and shows a retry prompt.
- Order confirmation emails include the itemized receipt (previously just totals).

CURRENT STATE
Checkout is functionally complete except for the retry-limit decision below.
We're on track for the March 17 launch date.

EVIDENCE
Test checkout: [link]. Try card 4000 0000 0000 0002 for a decline scenario.

RISKS
The payment provider's sandbox has been slow this week (10-15s response
times). If that persists in production it will feel broken to customers.
We're monitoring; will flag by Wednesday if it doesn't improve.

DECISIONS NEEDED FROM YOU
1. How many retry attempts before we email the customer instead of
   showing another retry button? We recommend 2. Need your answer by
   Monday to stay on schedule.

NEXT WEEK
- Implement whichever retry limit you choose.
- Start on order history page.
- Continue monitoring payment provider response times.

NOT DONE
We did not touch the admin dashboard this week — it's scoped for after
launch per our January call, not dropped.

Notice what's missing: no meeting count, no hours logged, no "great progress this week!" The client doesn't need a mood. They need to know what changed, what to check, what to decide, and what's still coming. Everything else is padding that makes the report feel substantial without making it useful.

Evidence is the section people fake

"Evidence" doesn't mean a paragraph describing the work — that's just restating section one. It means something the client can click, look at, or verify without emailing you back. A staging link. A before-and-after screenshot. A number from an analytics tool. If your evidence section only ever contains prose, it isn't evidence, and the client's trust in your "shipped" claims will erode slowly and silently until they start asking for calls to confirm things a report should have already shown them.

Decisions needed is not a suggestion box

The phrase "let us know if you have any questions" is where reports go to die. It puts the burden of finding the open item back on the client, who is busy and will not go looking. Every item in the decisions section should be a specific, answerable question with a deadline attached. "How many retry attempts, by Monday" gets answered. "Any thoughts on the checkout flow?" gets ignored until it becomes a blocker you have to raise on a call.

This is also where scope creep gets caught early. If a decision keeps getting deferred, that's worth naming directly the following week: "this is the second week we've asked about retry limits — we'll proceed with our recommendation of 2 unless we hear otherwise by Wednesday." That sentence is not passive-aggressive. It's the report doing its job, which is preventing a surprised client three weeks from now.

Why this fits how the work actually happens

Teams that run their delivery in Team and Tricks tend to find this template easier to fill in honestly, because the report is a summary of things that already exist rather than a reconstruction from memory on Friday afternoon. A Classic task's progress reports hold the narrative of what actually happened during the week; checklist items with attention flags show what's blocked or waiting on someone; requests show what's been asked of the client and whether they've answered. The weekly report becomes an act of selection — what does the client need to see — instead of an act of recall.

That's a smaller point than it sounds. The failure mode for most weekly reports isn't a bad template. It's that nobody wrote anything down during the week, so Friday afternoon becomes an archaeology exercise, and archaeology produces vague sentences about progress because vague sentences are all the excavator can reconstruct.

The report is a contract, not a diary

A diary records what happened to you. A contract states what's true and what's owed. The best client reports read like the second thing: here is what changed, here is what we need from you, here is what we didn't touch and why. That framing is uncomfortable at first, because it forces you to name gaps you might rather leave fuzzy. It's also the only version of the report that actually stops the Tuesday email asking what's going on.