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. You wrote it up honestly, project by project, and you sent it on Sunday night. On Monday the client replies "thanks, looks good" and nothing you actually needed a decision on gets decided. On Thursday he asks a question the update answered in its third paragraph.

The reflex after that is to write less. So the next update is four lines, and now the opposite thing happens: the work goes invisible. Nobody argues with a four-line update and nobody remembers it either, and at renewal time there is no record that the month was worth what it cost.

Both failures come from the same mistake. You wrote one document for one reader, and there were always two.

Two readers, one person

The person receiving your update reads it twice, in two different states, and they want completely different things.

The first read is on a phone, and it lasts about thirty seconds. He is between meetings. 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 his attention runs out, your update failed, no matter how much work it describes.

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 also the read that decides, quietly, whether the engagement gets renewed.

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

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 reader who stops at your signature has everything he needs to act. A reader who keeps going gets the whole record. Nobody is asked to wade past material meant for the other one.

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 this week. 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. It should be readable in the time it takes to walk to a meeting.

The forecast is the line most updates never contain, and it is the most valuable sentence in the email. "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 actually plan around. It also puts a small checkable promise on the record every week, which is how trust accumulates in a retainer.

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

Anything forward-looking goes here: your recommendation, the decisions you need, the questions for the call.

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 what they are.

Number them. Numbering means the client can reply "on 2, give them 40 each" without quoting anything back to you. The friction of having to quote your own text 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 converts 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.

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.

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

"Web visit views split by Decision stage, Tier 1 and Tier 2" is not a benefit. That is Progress, and it belongs one line down.

The benefit is "the SDRs open the day with an intent-sorted view instead of a flat list." The test: could the client repeat this 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 it is the one almost nobody writes.

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.

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

Marking something done that is not done

This is 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."

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.

Writing like a brochure

Cut the self-summarising closers. Say what a number means: "46.1%" is a number, "46.1%, below our 60% target" is information. And avoid the em dash, which more than anything else now reads as text a machine wrote.

Redesigning it every week

A weekly update is a series, not a document. Its value compounds precisely 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.

Where this came from

This framework was not designed. It was edited into existence, one correction at a time, starting from a real update that was already good and still was not landing. Every rule above is the residue of a specific instruction.

The pattern across all seven is one direction. Every correction removed structure and added decision. Each round stripped a piece of scaffolding that had been added to demonstrate thoroughness, and what was left standing is short, dense and entirely about what the reader has to do next.

Before you send

Sixty seconds, every week.

• Any square brackets left? Fill them or cut them.
• Search for the em dash. It should 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?

The worked example is a real update, anonymised. The structure, the numbers and the seven rounds of editing are unchanged. Earlier versions