The problem statement in a business report does more work than its length suggests. It tells the reader what went wrong, why it matters, and why someone commissioned a report about it. Skipped or written carelessly, it leaves every other section floating without context. Done well, it earns the reader's trust before they've reached page two.
What a problem statement actually is
A problem statement is a precise description of a specific situation that needs addressing. It isn't a list of complaints, a history of the organisation, or a preview of your recommendations. It answers three questions in roughly this order:
- What is the problem?
- Who or what does it affect, and how much?
- Why does it need to be addressed now?
The problem statement sits near the front of a report, typically after the title page and executive summary but before the scope, background, and methodology sections. Its job is to establish the "why" before everything else builds on top of it. If you haven't yet sorted out how those surrounding sections fit together, the guide on how to write a business report scope section covers the relationship clearly.
The most common mistakes writers make
Most problem statements fail in one of three ways.
They describe symptoms, not the problem. "Customer complaints have increased" is a symptom. "Customer complaints have increased by 34% in the past two quarters, concentrated in the post-sale support process" is the beginning of a problem statement. The difference is specificity and a stated cause.
They're too broad. A problem statement that could apply to any organisation in any industry won't help the reader understand why this report exists. Ground the statement in real figures, named departments, specific timeframes, or identified processes. Vague quantifiers do nothing: write the number, or name the examples.
They slide into solution mode. The problem statement isn't the place to preview your recommendations. That impulse is understandable, but it muddies the structure and can make the reader feel the conclusion was decided before the investigation began. State the problem cleanly. Let the findings and conclusions sections carry the answer.
How to structure a strong problem statement
Keep it short. Two to four paragraphs is the right target for most business reports. The structure below works for almost every context.
Paragraph 1: the current situation. Describe the state of affairs as it stands. Use specific data where you have it. "The warehouse dispatch team currently processes 220 orders per day using a manual logging system introduced in 2019." That's a current situation. It's factual, specific, and sets a baseline.
Paragraph 2: the gap or failure. Identify what's wrong with that current situation and quantify the impact. "Since October 2025, dispatch errors have averaged 12 per week, resulting in a redelivery cost of approximately $4,800 per month and a 9-point drop in the Net Promoter Score for the logistics team." Numbers anchor the claim. Without them, you're writing opinion.
Paragraph 3: the consequence of inaction. Tell the reader what happens if nothing changes. This paragraph justifies the existence of the report. "At the current error rate, projected redelivery costs will exceed the annual budget for logistics software by June 2027." Specific. Time-bound. Actionable.
Paragraph 4 (optional): the boundary of the problem. If there's a risk of scope creep, define what the problem statement does not cover. This can overlap with the scope section, but a brief sentence here saves confusion later.
Tone and language
Write the problem statement in plain, declarative sentences. Passive voice inverts the relationship between cause and effect and makes the report harder to parse. "Errors were recorded" is weaker than "The dispatch team recorded 12 errors per week." Put the subject first, keep the verb active, and stay close to the evidence.
Avoid hedging. "It appears that" and "it may be the case that" undermine the credibility of a statement that should be grounded in evidence. If you're not sure of a figure, use a range. If you don't have the data, say so directly and explain how the report will address the gap. The limitations section is the right place for uncertainty about your evidence; the problem statement is the right place to be direct about what you do know.
What to do when the problem is politically sensitive
Some reports are commissioned because something went wrong and someone is responsible. The problem statement still needs to be specific, but the language should describe the situation rather than assign blame. "The current approval process requires sign-off from four departments and averages 18 working days" is a factual description. "The finance department's slow approvals are costing the business clients" is an accusation in the wrong document.
State facts. Let the findings section build the case. Your credibility as a writer depends on appearing rigorous rather than partisan.
A short example
Here's a brief problem statement written for a fictional company. Notice the structure: current situation, specific gap, consequence, boundary.
Meridian Logistics currently processes inbound supplier invoices using a shared email inbox monitored by two accounts payable staff. The volume of invoices received has grown from 310 per month in 2023 to 540 per month in 2026, with no increase in staffing or system capacity.
Since January 2026, late payment penalties have totalled $22,400. Supplier complaints about payment delays rose from 4 in the first quarter to 17 in the second quarter. Three key suppliers have placed Meridian Logistics on 30-day prepayment terms, increasing short-term cash pressure.
If the current process continues unchanged, late payment penalties are projected to reach $90,000 by the end of the financial year. Two additional suppliers have indicated they may follow with similar prepayment terms.
This report addresses the invoice processing workflow only. Broader procurement strategy and supplier relationship management are outside its scope.
That's 160 words. It names specific numbers, a time frame, a consequence, and a boundary. A reader who finishes it knows exactly what problem the report is investigating and why it matters.
Before you write: one check worth doing
Before drafting the problem statement, confirm that you actually understand the problem. Talk to the people closest to the process. Review the data. Read the brief twice. A problem statement written before the investigation is done often describes the symptom the commissioner is most worried about, not the root cause the report uncovers. You can always revise the problem statement after the findings are in. Most writers don't, and their reports suffer for it.
Once the problem statement is solid, the rest of the report has a foundation. The background section can explain the history that led to the problem. The methodology can justify the approach used to investigate it. The findings can confirm or complicate what the problem statement predicted. Every section earns its place because the first one told the reader why it exists.