Two readers, one email
A weekly client update is read by two people who happen to be the same person: the client on his phone with thirty seconds, and the same client at his desk tomorrow, preparing for the call. Most updates serve one and lose the other. This is the format that serves both, the worked example it came from, and the seven rounds of editing that produced it.
The problem
Write a long update and the ask gets buried under six paragraphs of delivery detail. Write a short one and the work becomes invisible, and invisible work does not get renewed. Both failures come from the same mistake: treating the update as one document for one reader.
On his phone, thirty seconds
He wants three answers: is this on track, is anything stuck, is there something I have to decide. If he cannot get all three before he stops reading, the update failed, however much work it describes.
At his desk, before the call
He wants the record: what exactly was built, what it cost in hours, what it buys him, what is still open, and when it lands. This is also the reader who decides whether the retainer was worth it.
The format
Above the signature: a greeting, a three-line scan, and a numbered agenda. Below it: one block per project, five fields each, in the same order every week. The reference layer needs no header of its own, because its position already says what it is.
What it is
One plain line. No jargon, no tool names if a plain word will do.
Benefit
What it buys the client, in his terms, not yours.
Progress
What actually exists now. This is where the detail belongs.
What's Left
The specific remainder, or the word "nothing".
Effort
Hours spent. For open work, hours remaining and a completion date.
Same five, same order, every project, every week. The client learns the shape once and reads it at a glance forever. Reordering it costs him attention and buys nothing.
The worked example
A real update from a GTM engineering team to a client, anonymised: names changed and the client's segmentation fields genericised. Everything structural is exactly as it was sent. The band marks where the signature falls.
Subject: Weekly Update - Week 36
Hi Daniel,
How is it going?
Quick summary of where we stand (full summary below):
Completed this week: Intent tracking for all 7 ICP lists ~1200 companies, Updating the suppression list.
In Progress: ICP properties validation (3-4 hours remaining), Companies enrichment (2-5 hours remaining). We are likely going to finish both next week.
For discussion tomorrow:
- We have a good enough list to start working on. I suggest we start assigning companies to the SDRs now, and in parallel, review the enrichment process to complete what's needed.
- Companies assignment: who gets them and how many.
- Companies enrichment: we're considering an AI-based flow instead of the current automation tool.
Let me know if there is anything else on your mind.
Best,
Ariel Cohen
GTM Engineering As Service
1. CRM intent tracking for the ICP lists (7 lists, ~1,200 companies tracked)
- Track which ICP companies are already showing buying signals, so the SDRs start with warm accounts.
- Benefit: SDRs open the day with an intent-sorted view instead of a flat list; cuts research time per account by ~30%.
- Progress: live in the CRM. Web visit views for lists 2.1-2.5 and 2.6-2.7, split by Decision stage, Tier 1 and Tier 2. Research views per list, and the same for ICP companies not yet in the CRM.
- What's Left: nothing, we will tune the views as real traffic comes in.
- Effort: ~8 hours
2. Suppression list
- Keep the list of companies we never contact accurate.
- Benefit: no outreach lands on accounts you flagged; protects existing relationships.
- Progress: updated with all your feedback. Done.
- What's Left: nothing.
- Effort: ~1 hour
3. ICP properties validation
- Check that the data fields behind the ICP lists are reliable enough to act on.
- Benefit: SDRs will be able to trust the list they get and produce more.
- Progress: Segment Affiliation is validated (keyword workflow, reliable enough to use). Category Flag is workflow-based and not reliable yet. Verified Country and Audience Cohort come mostly from a partner's imports, and we can't verify the original data source.
- What's Left: improve the Category Flag workflow; decide together how much to trust Verified Country and Audience Cohort.
- Effort: ~6 hours so far, estimated 3 more. To be completed next week
4. Companies enrichment
- Complete the missing data on ICP companies so outreach is personal, not generic.
- Benefit: fuller company records with less manual work per account.
- Progress: reviewing the current process. We're considering an AI-based flow instead of the current automation tool.
- What's Left: choose the approach (on tomorrow's agenda), then run it across the list.
- Effort: ~2 hours so far, estimated 4 more, to be completed next week
Nine rules
Everything the client must act on goes above the signature
Recommendations, decisions, agenda items, anything with a question in it. Below the signature is reference only.
An ask buried under six project blocks did not get asked.
This is the rule that survived every round of editing untouched, including the round where the client rewrote the whole email himself. It is the load-bearing idea: position in the email is a claim about urgency, and putting a decision under the reference material tells the reader it can wait.
The summary is a scan, not a preview
Three lines: what closed, what is open with hours remaining, one sentence of forecast. Plain prose, no bullets, no structure. Put the single number that matters inline.
The forecast line is the one most updates never contain.
"We are likely going to finish both next week." A status report says where things are. A forecast says where they will be, which is the only part a client can plan against. It also puts a small, checkable promise on the record every week, which is how trust gets built in a retainer relationship.
Your recommendation goes in the agenda, not in a box of its own
A section headed "My take" reads like an aside that can be skipped. The same words as item 1 of "For discussion tomorrow" read like the first item on the agenda, which is what it is.
Number the agenda so the client can answer by number.
"On 2, give them 40 each" is a complete reply. Without numbers the client has to quote your text back to you to be understood, and the friction of that is often the whole reason a decision slides another week.
Every project answers the same five questions, in the same order
What it is, Benefit, Progress, What's Left, Effort. No project gets a bespoke shape because it feels different this week.
Benefit is written in the client's terms, never yours
"Views split by Decision stage, Tier 1 and Tier 2" is Progress. "SDRs open the day with an intent-sorted view instead of a flat list" is Benefit.
The test: could he repeat it to his own boss without you in the room?
If not, it is a feature. Features justify an invoice to the person who already understands the work. Benefits justify it to the person above him, who does not, and that is usually who decides whether the engagement continues.
One key number per project, not a stat dump
A parenthetical after the title, and only where a real number exists. Some projects have none worth stating; leave them bare.
Four numbers per project is not four times as informative.
This was learned the expensive way in round three, after a version that carried three or four stats per project. The verdict was one word: confusing. Past about one number per block a reader stops reading numbers as facts and starts reading them as decoration, and then the one that mattered goes past unnoticed too.
Effort is not decoration, it is the value story
Hours spent tell the client what he bought. Hours remaining plus a completion date tell him when the invoice stops growing. Both together are the most reassuring line in the email, and most updates omit them.
Never state a number you have not verified
If you do not know the hours, write them in square brackets and fill them before sending. A bracket is honest, and it is impossible to send by accident.
A plausible invented number costs you every other number in the email.
In the drafting of the worked example every effort figure and every benefit claim started life bracketed, because none of them existed in the source material. They were unbracketed in one deliberate pass, once a human who knew the real hours had read them. That is the whole discipline: the bracket makes an invention visible for exactly one decision, then it goes away.
Bold is wayfinding, not emphasis
Bold the section labels and the project titles. Nothing else. Once the field labels are bold too, nothing stands out and the block reads heavier than it is.
In a plain-text email, bold has to be Unicode characters.
Markdown asterisks stay literal asterisks in a plain-text mail body, and some clients render them and some do not. Unicode mathematical bold letters survive the draft, the send and a copy-paste into any client, which is why the worked example uses them. Writing directly in a rich-text composer is the other correct answer.
The house writing rules underneath
Four constraints that apply to every outbound sentence, not just to this format.
No self-summarising closers. "We are excited to be your partner in growth" says nothing and sounds like a brochure. End with an open door instead: "Let me know if there is anything else on your mind."
Say what a number means. "46.1%" is a number. "46.1%, below our 60% target" is information.
Keep the sender's own voice. This is a structure, not a script. The greeting, the humour, the way somebody says hello are theirs. Structure the update; do not replace the person writing it.
How it was made: seven rounds
The format was not designed. It was edited into existence, one instruction at a time, and every rule above is the residue of a specific correction. The rounds are worth reading because the wrong turns are as instructive as the destination.
Before you send: a sixty-second check
- Any square brackets left? Fill them or cut them.
- Search for the em dash character. It must return zero.
- Does anything above the signature need the reader to act? If not, you forgot the ask.
- Does every project have all five fields, in order?
- Does every open project have hours remaining and a completion date?
- Is anything marked done actually done? A project with a caveat belongs in progress, with the caveat named.
- Read the top block alone. Does it answer on track, anything stuck, anything for me?
Written from a real GTM engineering update, anonymised: names changed and the client's segmentation fields genericised. The structure, the numbers and the seven rounds of editing are unchanged. The last check is the one that catches the most: a project described as done, with a sentence explaining why it is not quite, is the single most common defect in a weekly update, and the only one a client remembers. Back to the topic