Structuring Business Documents
A business document has to communicate clearly to people who are distracted, skeptical, and often reading it for the first time. Its structure should make the recommendation obvious, the reasoning accessible, and the action clear — even to someone who only reads the first paragraph.
Published · Updated
What goes in an executive summary?
The executive summary contains the conclusion: the recommendation and the outcome. It is not an introduction. It doesn't tell you what the document is about — it tells you what you should do and why.
Most readers will only read the executive summary. Write it for them. If they read nothing else, they should know what you're recommending, what it will accomplish, and what it will cost.
Write it last, once you know exactly what you're recommending and why. An executive summary written before the analysis is usually wrong by the time the document is finished. One page max. One paragraph if possible.
What belongs in the background section?
The background section explains why the document exists and why the problem matters now. It is not a chronological account of how the situation developed, and it is not a comprehensive review of everything relevant to the topic.
Ask: what does the reader need to know to understand why this recommendation is urgent? That's the background. Everything else is the temptation to include everything you know.
Common error: a background section that's really a project history, a literature review, or an explanation of why it took so long to get to this point. Cut it. Readers don't need the backstory — they need the setup.
Analysis: evidence and options
The analysis section presents the evidence and reasoning behind the recommendation. Show the options you considered and explain why you rejected the alternatives — this builds credibility and preempts the obvious objections.
Data should be interpreted, not just presented. "Revenue declined 18% in Q3" is data. "Revenue declined 18% in Q3, primarily driven by a 34% drop in enterprise renewals following the pricing change in August" is analysis.
The analysis section is where skeptics will look first. Make it airtight. Acknowledge uncertainty where it exists — pretending it doesn't is worse than admitting it.
What makes a good business recommendation?
A good recommendation is specific, assigned to an owner, and tied to a timeline. "We should improve our processes" is not a recommendation. "We should hire two additional QA engineers by Q2 to reduce the defect rate from 4.2% to under 2%, assigned to the engineering lead for implementation" is a recommendation.
A recommendation without a specific action, an owner, and a timeline gives readers nothing to act on. Vague recommendations produce vague outcomes.
If there are dependencies, risks, or conditions, name them here — not buried in the analysis. A decision-maker needs to know the caveats before they decide, not after.
An executive summary, weak and strong
Weak: "This document reviews our customer support operations and discusses several options for improvement going forward." The weak summary tells the reader what the document covers but not what it recommends.
Strong: "We recommend moving first-line support to a shared inbox with response-time targets, starting next quarter. This should cut average response time from two days to under one day, at a cost of one additional hire. The support manager will lead the rollout, with a review after three months."
The strong version states the recommendation, the expected result, the cost, the owner, and the timeline in four sentences. A reader who stops here can still make a decision.
Adapting the structure to the document type
A one-page memo compresses the same logic: recommendation in the first paragraph, a short paragraph of reasoning, then the specific ask. A longer proposal adds sections on options, risks, and implementation.
Status reports flip the emphasis: lead with what has changed and what decisions are needed, not with a list of completed tasks. Incident reports lead with impact and current status before explaining causes.
Whatever the format, keep the principle: the most important information for the decision-maker comes first, and supporting detail follows for those who need it.
Use headings that state conclusions rather than topics. "Costs will fall 15% by year two" is more useful than "Cost analysis."
Put detailed data in tables or appendices and summarize what the data shows in the main text. Readers should never have to study a table to discover your point — tell them what it shows, then let them check.
Before you send
Read only the executive summary and the recommendation. Could a decision-maker act on them without reading anything else? Then check:
- every number in the summary matches the analysis
- the owner named in the recommendation has agreed to it
- the risks section includes the objection you most expect to hear
Fixing these before sending saves a round of follow-up questions.
Exercises
- 1
Write the executive summary
You manage a small team whose project is running late. Write a four-sentence executive summary recommending one course of action, including the expected result, the cost, the owner, and the timeline.
- 2
Turn data into analysis
Take three raw facts, for example "sign-ups fell 10% in March," "a competitor launched a free plan in February," and "our prices rose in January." Write a paragraph that interprets them and supports a recommendation.
- 3
Restructure a real document
Choose a report, proposal, or long email you have written. Move the recommendation to the top, rewrite topic headings as conclusion headings, and move detailed data into an appendix.
Sources and further reading
- The Pyramid Principle — Barbara Minto
- Federal Plain Language Guidelines: Organize — plainlanguage.gov
- Inverted Pyramid: Writing for Comprehension — Nielsen Norman Group
Try it in WolfScribed
Draft in a Business project so the analysis checks your document against business-writing conventions.