customer-updatelisted

# Customer Update A customer update is not an email to a person. It goes to a list, it gets forwarded to people who were never on the list, and it is read in eleven seconds by someone with no context who wants to know one thing: **does this affect me, and do I have to do anything.** Answer that in the first two lines or the rest is not read. The failure this exists to prevent: **the update written from your side of the glass.** A paragraph about your infrastructure, your roadmap process or your team change, with the thing that actually affects them somewhere in the middle, unmarked. --- ## What this needs **Shared context.** If an `account-context` document exists, read it first: the segments and the contract shapes. Those decide who gets which version. Where it is absent, carry on and name the assumption. **Minimum: what is changing, when, and who it touches.** Enough for the segmentation, the subject line and the draft. **Better with** the account list with contract and usage detail, so impact can be assessed rather than assumed, and any legal or security obligation attached to the notice. **Best with** a prior update of the same type that went well or badly, because the format matters more than the wording and yours may already be set. --- ## Step 1: Decide whether this is one message or several The most consequential decision and the one made least deliberately. **Segment by impact, never by mailing list.** If five per cent of the list is badly affected and n