The Friday-afternoon status email is one of the highest-leverage moments in a client engagement — and most agencies write it from recollection. Why that fails, and what to do instead.
Friday afternoon, 3:47 PM. The project manager opens a blank email, stares at it for ten seconds, types “Hi Ana — quick update on this week,” and pauses. They open Slack in the next tab. They scroll the team’s channel looking for merged-PR notifications. They remember that Juan was working on the Stripe retry logic and they think it shipped Tuesday, but maybe it was Wednesday. They hop to GitHub. They give up on GitHub, switch to Jira, find three tickets closed this week, copy the titles, go back to the email. Fifteen minutes in, the email has one paragraph and no content.
Forty-five minutes later, the email is sent. It is okay. Not good — okay.
This scene plays out at thousands of software agencies every Friday. The weekly status email is one of the highest-leverage pieces of communication in the entire engagement, and we produce it by reaching into our own recollection, scrolling Slack for breadcrumbs, and reconstructing the week like a detective. This is a bad process for three specific reasons.
When you write a status email from recollection, you remember the things that were interesting to the team: the gnarly bug, the architectural debate, the late-night hotfix. You forget the things that were boring to the team but mattered to the client: a small copy change on the checkout page, a permissions tweak, a caching improvement the Ops lead shipped on her own.
The client, reading the report, cannot tell the difference between “this wasn’t in the report because it didn’t happen” and “this wasn’t in the report because the PM forgot.” Both produce the same suspicion — that the team isn’t doing as much as they’re billing for — and the agency has no defense against it because the report was built from memory, not evidence.
The reason the PM spends 45 minutes building the report is that they are re-deriving a fact they already have: what the team shipped this week. The commit history is the source of truth. The PR titles are the captions. The merge dates are the timeline. Everything a status report needs is already present in the repo — it just needs to be filtered, grouped, and translated into executive language.
“Filtering, grouping, and translating” is not a creative task. It is a transformation task — the kind software is good at. Automating the first draft costs the agency almost nothing and gives it back the 45 minutes it was spending on remembering.
Here’s the subtler reason agencies are slow to automate this work: the fear that an auto-generated report will be wrong, embarrassing, or tone-deaf. That fear is correct about a one-shot automation that blasts the draft straight to the client. It is incorrect about automation with a mandatory human review step.
The PM’s real value in the weekly-report process isn’t the draft. It’s the editing, the context-adding, the tone-tuning, the decision to include a line like “the CTO and I are going to review the cache strategy on Monday” that only a human close to the engagement can author. Move the 45 minutes out of drafting and into editing and the quality of the final report increases. The writer is now editing evidence instead of inventing prose.
The replacement process has five steps and takes 3–5 minutes:
The review gate is non-negotiable. It’s the reason a commit-based reporting tool can be trusted with a client relationship in the first place. (commitplainmakes this gate the centre of the product — no report ever leaves the dashboard without your explicit approval, unless you deliberately turn on automation for a project you’re confident in.)
Before you write this week’s report from memory, spend one minute on your repo. Open the commit log for the last seven days. Scroll it once. Notice three things the client should know about that you were not planning to mention. That’s the gap between the report you were going to write and the report you should write.
Once you see the gap, the case for moving the first draft out of your head becomes obvious. Writing client reports from memory is not a skill — it’s a tax. Everything you used to spend those 45 minutes doing is now done in the 3 minutes you spend reviewing a draft built from the actual record.
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