--- name: weekly-client-update description: Write or restructure a weekly client update, project status email, or delivery report to a client. Use whenever someone needs to turn raw notes about a week's work into an email a client can scan in thirty seconds and still act on, or when an existing update reads long, buried, or vague about effort and benefit. Covers agency, consultancy, freelance and internal-team updates. --- # The Weekly Client Update Turn raw notes about a week of work into an update that serves two readers at once. Full write-up, worked example and the seven editing rounds this came from: https://simplybroken.com/explore/clientupdates ## The core idea A weekly update is read by two people who happen to be the same person. **The client on his phone, thirty seconds.** He wants three answers: is this on track, is anything stuck, is there something I have to decide. **The same client 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. Most updates serve one and lose the other. A long update buries the ask; a short one makes the work invisible, and invisible work does not get renewed. **The fix is two layers in one email.** The decision layer sits above the signature. The reference layer sits below it. A reader who stops at the signature has everything he needs to act. A reader who keeps going gets the whole record. ## The template ``` Hi , Quick summary of where we stand (full summary below): Completed this week: , . In Progress: (N hours remaining), (N hours remaining). For discussion tomorrow: 1. 2. 3. Let me know if there is anything else on your mind. Best, COMPLETED THIS WEEK 1. (key number, if there is one worth stating) • • Benefit: • Progress: • What's Left: • Effort: ~N hours 2. • ... same five fields IN PROGRESS 3. • ... same five fields • Effort: ~N hours so far, estimated N more. To be completed ``` Bold the section labels and the project titles only. In a plain-text email body, Markdown asterisks stay literal asterisks, so use Unicode bold characters (𝗟𝗶𝗸𝗲 𝘁𝗵𝗶𝘀) which survive copy and paste into any mail client. In a rich-text composer, use its own bold. ## The nine rules 1. **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. 2. **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. Put the single number that matters inline. The forecast line is the one most updates never contain, and it is the only part a client can plan against. 3. **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" read like the first item on the agenda. Number the agenda so the client can answer "on 2, give them 40 each" without quoting anything back. 4. **Every project answers the same five questions, in the same order:** what it is, Benefit, Progress, What's Left, Effort. Same shape every project, every week. The client learns it once and then reads for change instead of for structure. 5. **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. 6. **One key number per project, not a stat dump.** A parenthetical after the title, and only where a real number exists. Past about one number per block a reader stops reading numbers as facts and starts reading them as decoration, and the one that mattered goes past unnoticed too. 7. **Effort is the value story, not decoration.** 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. 8. **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: `[~6 hours]`. A bracket is honest and impossible to send by accident. A plausible invented number costs you the credibility of every other number in the email. 9. **Bold is wayfinding, not emphasis.** Section labels and project titles. Nothing else. Once the field labels are bold too, nothing stands out. ## House writing rules - **No em dashes.** Use a comma, a period or a colon. It is the strongest single tell that text came out of a language model. - **No self-summarising closers.** Cut "we are excited to be your partner in growth" entirely. End with an open door instead. - **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 they say hello are theirs. Structure the update; do not replace the person writing it. ## Two judgement calls **"Done" is not the same as "no longer being worked on."** A project with a caveat attached belongs in IN PROGRESS with the caveat named. This is the most common defect in a weekly update and the only one a client remembers. **A weekly update is a series, not a document.** The value compounds when the shape stays identical week over week. Resist redesigning it. The only thing that should change every week is the content. ## How to run this When given raw notes: 1. Sort the work into COMPLETED and IN PROGRESS. Apply the "done is not done" test to anything the notes call finished. 2. Write the five fields per project. Pull What it is and Progress from the notes; write Benefit yourself in the client's terms. 3. **Bracket every value the notes do not contain:** all effort figures, all benefit claims, any number. Never quietly assert one as fact. 4. Write the scan block last, once you know what the projects say. 5. Move all forward-looking material into the numbered agenda above the signature. 6. Run the checklist below, then hand it over with a one-line note saying what was invented and what came from the source. ## Before sending: the 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? - Read the top block alone. Does it answer on track / anything stuck / anything for me?