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.
Write the executive summary last — put it first
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 this section. 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.
Background: context, not history
Background explains why this 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.
Recommendation: specific, assignable, timed
"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.
Key Takeaways
- The executive summary contains the conclusion, not an introduction — write it last, put it first
- Background answers "why does this matter now?" — it's context, not history
- Analysis shows your reasoning and the alternatives you rejected, not just the data
- A recommendation names a specific action, an owner, and a timeline
- Interpret data — don't just present it and expect readers to draw the same conclusion you did
Try it in WolfScribed
Open a project and use the Scene Planner to put these ideas into practice.