Business Writing

Business writing — outcome first

Verified 2026-07-29.

Load the user's recorded preferences before drafting — register, formatting and house style are already captured per domain:

python3 ~/.claude/skills/user-preferences/scripts/prefs.py load email          # or presentations, tone

A live instruction always overrides a stored preference.

1. The one rule

Lead with the outcome. Not the background, not the chronology, not the process.

Most workplace writing is assembled in the order the work happened — context, then what we tried, then what we found, then what it means. Readers consume in the opposite order and most stop early. Senior readers skim, and they skim from the top.

✗  "Following the review we began in March, we assessed four vendors against
    the criteria agreed with the working group, and after testing..."

✓  "Recommend we go with Vendor B. £40k cheaper over three years and the only
    one that meets the retention requirement. Decision needed by 14 Aug.

    Detail below."

BLUF — bottom line up front. Answer first, then the reasoning that supports it, then the evidence that supports that. Someone who stops after one paragraph should still have the thing you needed them to know.

The honest caveat: brevity can cut something load-bearing. BLUF is not "make it short" — it is "put the conclusion first". A risk, a caveat or a dependency the reader must act on belongs above the fold, not sacrificed to it.

2. Decide what you want before you write a word

Every piece of workplace writing has exactly one of four jobs. Naming it first is what makes the draft write itself:

If you cannot name the job, do not send it yet — that is the actual reason a draft feels wrong.

Then write the ask as a sentence, not an implication. "Let me know your thoughts" converts to nothing, because nobody knows what agreeing looks like. "Can you approve the £12k by Friday so we can order?" does.

Where an ask is buried at the end, the reader who skims never reaches it — and skimming is the normal case, not the rude one.

3. Structure that survives a skim

Answer → because → evidence. Each layer supports the one above it, and each is optional to the reader.

• First sentence carries the message. Not a greeting, not context-setting. If someone reads only that line, what must they know?
• One idea per paragraph, with the point in the first sentence of each.
• Bold the two or three things that must not be missed — and no more, because bolding everything bolds nothing.
• Bullets for parallel items, prose for reasoning. A bulleted argument loses the connective tissue that made it an argument.
• Put detail below a clear break — "Detail follows", an appendix, a linked doc. That protects the skim-reader without starving the person who needs the specifics.
• Assume a phone screen. Long paragraphs are a wall; three lines is a paragraph.

4. Per surface — what changes, and what does not

The lead-with-the-outcome rule never changes. Length and formality do.

The subject line is the only text guaranteed to be read. Make it the message: Approval needed: Vendor B, £12k, by Fri 14th beats Vendor update. Front-load it — mobile notifications truncate at around forty characters.

On chat: the "hello, are you free?" opener wastes a round-trip. Ask in the first message.

5. The so-what test

Every paragraph must answer: so what, for this reader? Anything that fails is your interest, not theirs — process detail, how hard the work was, who was in which meeting.

• Numbers, not adjectives. "Significantly improved" is unquotable; "cut from 6 days to 2" travels and survives being repeated by someone else.
• Translate into their currency. Engineers hear latency, finance hears cost, risk hears exposure, executives hear revenue and reputation. The same fact needs different units per audience.
• Cut hedging. "It may be worth potentially considering whether we might" is one word: "Should". Hedging reads as either lack of confidence or lack of a view — neither is what you meant.
• Say the thing. If the project is late, "the project is late" outperforms every softer phrasing, and the softer phrasings are transparent anyway.

6. Bad news and risk

Lead with it. Burying bad news is the single most damaging habit in workplace writing, because the reader discovers it later, usually from someone else, and now the concealment is the story.

Order: what happened · impact · what you are doing · what you need · when you will next update.

• Own it without over-apologising. One sentence of accountability, then the plan. Extended apology shifts the reader's attention to managing your feelings.
• Do not stack qualifiers around a risk. A risk hedged into vagueness is a risk you have technically disclosed and functionally hidden — and that distinction gets tested afterwards.
• Give a date for the next update, even when there is nothing to report yet. Silence is read as deterioration.

7. Register

Match the reader, not the org chart. Peers, senior stakeholders and external clients need different formality; none of them need jargon.

• Plain English wins at every level, and most reliably at the top. Dense internal jargon is invisible to precisely the audience that decides things.
• Expand an acronym on first use, always. The cost is four words; the cost of not doing it is a reader who quietly disengages.
• Warmth is not padding. One human line is worth keeping; three paragraphs of preamble are not.
• Read it aloud. If you would not say it, do not send it — that single check removes most of what makes business writing bad.

If a draft reads as AI-written, the fix is specificity, not vocabulary — details only you could know. See human-voice-writing.

8. Cutting

Write it, then cut a third. Nearly every first draft carries a third it does not need.

Cut first, in this order: throat-clearing openings · restating the question · process narration · anything the reader already knows · adverbs · sentences that only introduce the next sentence.

If it will not fit, the problem is usually that you have not decided what you are asking for (§2). Length is a symptom.

9. Anti-patterns

• Chronology before conclusion — the default failure.
• Not naming the job the writing has to do.
• An implied ask — "let me know your thoughts".
• The ask at the bottom, where a skim-reader never reaches it.
• Confusing BLUF with brevity, and cutting a load-bearing risk.
• Subject lines that name a topic instead of carrying the message.
• "Hi, are you free?" as a standalone chat message.
• Status updates that are task lists with no "so what".
• Adjectives where numbers exist.
• Hedging stacked around a real risk.
• Burying bad news, then being asked why it was buried.
• Bolding everything.
• Bulleted arguments that lose the reasoning between the points.
• Unexpanded acronyms.
• Sending the first draft without cutting a third.