A checklist for what belongs in a weekly or monthly client report — and what to cut. Ordered by reader priority, with examples of each section done well.
This is a reference — not a template. Every agency’s reports should feel like the agency, not a filled-in Notion doc. But the underlying structure is remarkably consistent across good reports, and it is remarkably inconsistent across bad ones. Below are the seven sections that earn their place, in the order the client wants to read them.
The single most important change of the week, in one sentence, before anything else. No preamble, no greeting-as-section. If you can’t identify a headline outcome, the headline is itself a signal: “This week was infrastructure investment — no customer-facing change, but the groundwork for the feature we agreed on the April 3 call is now in place.”
The test: if the client forwarded only the first sentence of your email to their co-founder, would the co-founder understand what happened this week? If yes, the sentence is doing its job.
A flat list of everything that landed in production this week, grouped by business area (“onboarding,” “admin panel,” “data pipeline”), not by team or ticket. Each bullet has two parts: what changed, and why it mattered.
Keep the total to under seven items. If there are twelve, consolidate. Three related refactors on the billing service become “Billing: three performance improvements that together drop the monthly invoice generation time from 90 seconds to 15.”
Work started but not finished this week. Clients hate being surprised next week by something they didn’t know was happening. This section is the pre-emption: “Here’s what we’re working on now so that nothing in next week’s report is a shock.”
Include an expected landing date for each. If you can’t commit to a date, say so — “exploring the shape this week, should have an estimate by Friday” — which is itself useful information.
This is the section most agencies omit and most clients value most. If there is any decision, however small, where the team needs the client’s input before next Monday, it goes here. Surfacing decisions in the report is better than in Slack because:
Anything that might affect the agreed timeline. Each risk gets three parts: what it is, why it matters, what you’re doing about it. A risk with no mitigation is a complaint — and clients shouldn’t have to help you mitigate your own risks, that’s what they hired you for.
If there are no risks this week, omit the section entirely. A manufactured “risk” for completeness is worse than silence.
A short, stable set of numbers the client can compare week over week. Stability is more important than completeness: if you tracked uptime and p95 last week, track them this week too. A changing metric set implies the agency is cherry-picking flattering numbers.
Good candidates: deploys this week, p95 response time on a named endpoint, error rate, a business metric tied to what you built (checkout conversion, sign-up completion). Bad candidates: LOC shipped, tickets closed, standups held. Those are engineering-team metrics, not client metrics.
The report ends forward-looking. What will the client see in next week’s report? What conversations might come up? Are there any dates, launches, or external dependencies they should be aware of?
This section is short on purpose — three or four sentences at most. Its value is calibrating the client’s expectations for the next seven days so the next report lands in a context they already understand.
A few things creep into agency reports by habit, and every one of them should be cut:
The seven sections compress into a surprisingly short document — usually a paragraph of lede, two short lists, two or three inline questions, and a closing paragraph. 400–700 words is plenty. Anything longer is usually padding.
Most of the raw material for sections 2 and 3 is already in your commit log and PR titles. Pulling it out by hand is where the 45 minutes go. If you want that step skipped — while still having the human review gate that keeps the report trustworthy — commitplain builds the draft from your real commits and hands it to you for edit and approval. The seven sections above are a good lens for what to keep, cut, or rewrite before you send.
commitplain reads your real GitHub commits and drafts an executive client report in your tone — reviewed and approved by you before anything reaches your client.
See how it worksMost weekly client reports get skimmed in twenty seconds and filed. Here's the shape of the ones that don't.
7 min readJira tickets describe what you planned. Commits describe what you shipped. When those two diverge — and they always do — the client report should follow the commits.
6 min readNon-technical clients don't need to understand your code. They need to understand what changed for them, and why it was worth what they paid for it.
8 min read