Simply Broken
Exploring / The Weekly Client Update / v4
Exploration · v4 · 1 September 2026

The Two-Layer Client Update

Your weekly update has two readers inside one person. Serve them in the wrong order and a week of real work reads as noise.

You did the work, wrote it up honestly, and sent it Sunday night. Monday brings "thanks, looks good" and nothing you needed decided gets decided. The reflex is to write less, and then the work goes invisible instead. Both failures are the same mistake: one document, written for one reader, when there were always two.

Length used to be evidence of effort. It is not any more.

Anyone can now produce two thousand competent words about a week of work in about nine seconds, and clients know it. So a long update has stopped signalling diligence and started signalling the opposite: that nobody spent the twenty minutes deciding what actually mattered.

Short has become the expensive part, which makes it the part worth paying for. That is the whole argument for the format below: it is not a way to write less, it is a way to put the thinking where the client will actually meet it.

Two readers, one person

The person receiving your update reads it twice, in two different states, and wants completely different things each time.

The first read is on a phone, and lasts about thirty seconds. He wants three answers: is this on track, is anything stuck, is there something I have to decide.

He is between meetings, standing up, half listening to something else. If he cannot get all three answers before his attention runs out, your update failed, no matter how much work it describes. This is also the only read that ever happens on time.

The second read is at a desk, the night before your call. Now 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 the read that quietly decides whether the engagement gets renewed, and it is the one a short update starves.

A long update serves the second reader and buries the first. A short one serves the first and starves the second. Averaging them produces something that serves neither, which is what most weekly updates are.

You do not have to choose. You have a fold line already, and almost nobody uses it: your signature.

The framework

Put everything the client has to act on above your signature. Put everything he might want to look up below it. One email, two layers, and the signature is the boundary that tells him which is which.

A diagram of one email split into two layers by the signature line: a short decision layer above it and a long reference layer below it. LAYER ONE The decision layer Three lines of status. A numbered agenda. An open door. Read in thirty seconds, on a phone, between meetings. Everything he must act on lives here. YOUR SIGNATURE LAYER TWO The reference layer One block per project. Five fields, same order, every week. Read at a desk, the night before the call. Everything he might look up lives here.
The signature is already a visual break in every email ever sent. This framework just gives it a job.

What it looks like

A real weekly update from a GTM engineering team to a client, anonymised: names changed and the client's segmentation fields genericised. The bands mark where the signature falls.

Above the signature · the decision layer

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:

  1. 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.
  2. Companies assignment: who gets them and how many.
  3. 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

Below the signature · the reference layer
Completed this week

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
In progress

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

Layer one: above the signature

Three moves, in this order, and nothing else.

1. A scan, not a preview

Three lines of plain prose: what closed, what is open with hours remaining, then one sentence of forecast.

Put the single number that matters inline and leave the rest for layer two: "Intent tracking for all 7 ICP lists, around 1,200 companies." No bullets, no headings, no structure at all. It should be readable in the time it takes to walk to a meeting.

The forecast is the sentence 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 around.

It also puts a small checkable promise on the record every single week. Keep it four times and you have built something no amount of reassurance buys.

2. A numbered agenda, with your recommendation as item one

Do not give your recommendation a section of its own.

A block headed "My take" reads like an aside, and an aside can be skipped. The same words as item 1 of "For discussion tomorrow" read like the first item on the agenda, because that is exactly what they are. The words do not change. The position does.

Number them, so he can answer by number.

"On 2, give them 40 each" is a complete reply. Without numbers he has to quote your own text back at you to be understood, and the friction of doing that on a phone is often the entire reason a decision slides another week.

3. An open door

One line: "Let me know if there is anything else on your mind."

It costs nothing and it turns a broadcast into a conversation. What it replaces is the self-summarising closer, "we are excited to be your partner in growth", which no client has ever read to the end.

Layer two: below the signature

One block per project, grouped into Completed this week and In progress. Every block answers the same five questions, in the same order.

01What it isOne plain line. If a plain word works, do not use the tool name.
02BenefitWhat it buys the client, stated in his terms.
03ProgressWhat actually exists now. All the detail belongs here.
04What's LeftThe specific remainder, or the word "nothing".
05EffortHours spent. For open work, hours remaining and a completion date.

Same five, same order, every project, every week.

This is the part people want to improvise on, and improvising is the mistake. When the shape is identical week over week, the client stops reading for structure and starts reading for change, which is the whole point. Reordering costs him attention and buys you nothing.

Three of the five are easy. Two are where updates actually go wrong.

Benefit is written in his terms, never yours

"Views split by Decision stage, Tier 1 and Tier 2" is not a benefit. That is Progress, one line down.

The benefit is "the SDRs open the day with an intent-sorted view instead of a flat list."

The test: could he repeat it to his own boss, without you in the room?

If not, you wrote 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 who is usually the one deciding whether this continues.

Effort is the value story, not decoration

Most people leave hours out, because stating them feels like inviting an argument. It is the opposite.

Hours spent tell the client what he bought. Hours remaining plus a completion date tell him when the invoice stops growing. "~6 hours so far, estimated 3 more. To be completed next week" is the most reassuring line in the entire email, and almost nobody writes it.

One number per project, not a stat dump.

A single key figure in a parenthetical after the project title, and only where a real one exists. Some projects have no number worth stating; leave them bare.

Past roughly one number per block, a reader stops reading numbers as facts and starts reading them as decoration, and then the one that mattered slides past unnoticed along with the rest.

Bold only the section labels and the project titles.

Once the field labels are bold too, nothing stands out and the block reads heavier than it is. In a plain-text email body, Markdown asterisks stay literal asterisks, so either write in a rich composer or use Unicode bold characters, which survive a copy and paste into any client.

Four ways it still goes wrong

1

Marking something done that is not done

The most common defect in a weekly update, and the only one a client actually remembers.

In the example above, the properties validation was originally written as finished. It was not: one field was validated, one was unreliable, and two came from a source nobody could verify.

Moving it into In progress, with the remainder named, is not an admission of failure. It is the difference between an update a client can plan against and one he later discovers was optimistic.

"Done" is not the same as "no longer being worked on."

2

Stating a number you have not verified

If you do not know the hours, write them in square brackets and fill them in before you send: [~6 hours].

A bracket is honest, and it is impossible to send by accident. A plausible invented number is far more expensive than an obviously missing one, because it does not cost you that number. It costs you the client's trust in every other number in the email, including the true ones.
3

Writing like a brochure

Cut the self-summarising closers, and say what a number means.

"46.1%" is a number. "46.1%, below our 60% target" is information. And avoid the em dash, which now reads more than anything else as text a machine wrote.
4

Redesigning it every week

A weekly update is a series, not a document. Its value compounds because the shape does not move.

Once you have sent the same structure four times, the client can find any field without looking for it, and a change he needs to see leaps out. Improving the format feels productive and it resets that clock every time.
The only thing that should change from week to week is the content.
Take it with you

The skill

This whole framework, packaged as a skill for Claude. Give it your raw notes about the week and it writes the update in this shape: two layers, five fields per project, and every number it could not verify left in square brackets until you confirm it. Free, no attribution needed.

Download the skillZIP · 4 KB Read SKILL.md first
How to install it
  1. Claude Code: unzip it into .claude/skills/ in your project, or into ~/.claude/skills/ to have it everywhere. It loads on the next session.
  2. Claude apps: upload SKILL.md to a Project's knowledge, or paste its contents into the project instructions.
  3. Anything else: it is one Markdown file. Paste it in front of your notes and ask for the update.

Then say "write this week's client update" and paste your notes.