A client problem statement turns discovery notes into a concise account of who is affected, what is happening, why it matters, and what remains uncertain. It should help the client confirm the problem before you recommend work. It should not turn every comment from a call into a fact, a root cause, or an approved requirement.
The useful output is a shared basis for the next decision. A polished paragraph that hides conflicting evidence is less useful than a provisional statement that names the missing check.
Read the decision map as text
- Sort the notes: Separate observed evidence, reports, and hypotheses.
- Describe the problem: Name who is affected, what happens, and the context.
- Record uncertainty: State unknown causes and unverified consequences.
- Confirm with the client: Invite corrections before proposing the solution.
Separate the record from your interpretation
Start with the original notes. Keep direct observations, reported experiences, your interpretation, and unresolved questions distinct.
| Note type | Example from a fictional inquiry workflow | How to use it |
|---|---|---|
| Client report | “Some inquiries wait until someone notices them” | Attribute it to the person who reported it |
| Reviewed evidence | Several sample inquiries have no recorded owner | State the sample and what was inspected |
| Hypothesis | Unclear ownership may contribute to slow replies | Test it before calling it the cause |
| Requested solution | “We need a new CRM” | Treat it as an option to evaluate |
| Unknown | Whether all intake channels have the same problem | Name the investigation needed |
A transcript can preserve words, but it cannot determine which claims are accurate. If AI summarizes the call, check every statement against the recording or notes and the materials reviewed. In particular, look for invented agreement, missing caveats, and a hypothesis rewritten as a conclusion.
Use the evidence questions in our guide to diagnose a client problem when the notes do not support a clear cause.
Find the decision the statement must support
A problem statement used to decide whether discovery is needed can be provisional. A statement used to justify a substantial implementation requires stronger evidence and clearer boundaries.
Ask: what will somebody authorize after reading this? A research task, a revised brief, a prototype, or a full project? Match the confidence of the statement to the consequence of that decision.
If the next step is only to inspect the intake process, you do not need to claim that a new CRM will increase sales. You need to explain the uncertainty that the inspection will resolve.
Build the statement around four elements
Use these elements as prompts, not as a rigid sentence formula:
- People and context: who encounters the problem, and in which situation?
- Observed or reported gap: what is happening compared with what is needed?
- Consequence: why does the gap matter, and what supports that claim?
- Boundary and uncertainty: what is included, and what still needs checking?
Nielsen Norman Group's problem-statement guidance similarly treats the statement as a way to frame discovery. The application here adds an explicit distinction between evidence, reports, and hypotheses for client-service decisions.
Do not start by filling in a solution name. “The business needs automation” says what you want to sell. It does not explain the problem automation would address.
Once the statement is confirmed, align scope, price, and outcome before writing the proposal.
Use a copyable problem-statement worksheet
Fill in the following with your actual evidence:
Copy-and-customize template: Replace the text in square brackets with your project details before using it.
People and setting: [Who experiences the issue, and where?]
Current gap: [What happens now, and what needs to happen?]
Evidence: [Source, sample, period, and limitations.]
Working hypothesis: [Possible cause / supporting and contradicting evidence / check needed; leave unconfirmed until tested.]
Impact: [Observed effect, reported effect, or risk.]
Unknowns: [Questions that could change the recommendation.]
Boundary: [The process or situation included in this investigation.]
Client confirmation: [Who reviewed this / date / corrections / pending confirmation.]
Next decision: [What should be confirmed or checked before proceeding?]
Not every field needs a paragraph. A simple project may fit on half a page. The worksheet is complete when it supports the decision, not when it reaches a particular length.
Worked example: from messy notes to a defensible statement
This example is fictional. The counts demonstrate how to qualify evidence; they are not client results or benchmarks.
Imagine your notes say:
- The founder says sales follow-up is inconsistent.
- The team receives inquiries through a web form and a shared inbox.
- A sales-record export reviewed October 29, 2026 contains a convenience sample of 12 form/shared-inbox inquiries received October 1–28; four have no recorded next action. The sample is not claimed to represent every inquiry.
- One person believes another person is handling the form submissions.
- The client asks for a new CRM and says revenue is being lost.
A weak statement would be:
The company's outdated CRM causes lost revenue, so it needs a modern automated sales system.
That conclusion assumes a cause, asserts an unmeasured loss, and commits to a solution.
A more useful statement is:
Problem statement v1, October 29, 2026: In the 12 form/shared-inbox inquiry records selected from October 1–28, four lack a recorded next action in the sales export. The founder also reports inconsistent ownership. These findings limit visibility of who is handling those inquiries, but do not establish that follow-up did not occur. Response-time and sales effects remain unmeasured. Check the four journeys and their ownership before choosing a system change.
The revised statement still leaves room for the client to disagree. Perhaps actions were taken but not recorded. That would reveal a visibility problem rather than establish that follow-up never happened.
Describe impact without inventing a business case
Different evidence supports different kinds of impact:
| Available information | Responsible wording |
|---|---|
| Client reports frustration | “The client reports difficulty tracking…” |
| A sample shows missing records | “In the reviewed sample…” |
| Comparable timing records exist | Describe the period, unit, and comparison |
| Revenue effect is unknown | State the operational gap and leave the revenue effect open |
You can explain a plausible risk without claiming it occurred. “An unassigned inquiry may go unanswered” is a risk. “The business lost $20,000” requires evidence connecting the actual inquiries to a verified financial effect.
If the client supplies a number, ask where it comes from. An estimate may be useful, but label it as an estimate and retain its assumptions. Do not make it more precise merely because the proposal would look stronger.
Return to the discovery call questions when a missing answer changes the recommendation.
Resolve competing versions of the problem
Different stakeholders may describe different experiences. The founder may see slow sales, while the account manager sees incomplete inquiries and operations sees unclear ownership.
Keep those accounts visible rather than averaging them into “communication issues.” Identify where they agree, where they differ, and which evidence could resolve the difference.
Sometimes the right output is two related statements. One might describe intake visibility; another might describe lead quality. Combining them prematurely could lead to buying software to solve a demand problem.
If the person who approves the project was not on the discovery call, ask whether they have reviewed the problem framing. Agreement from an interview participant does not automatically authorize the engagement.
Ask the client to validate the interpretation
Send the statement with a specific review request:
Please check whether this describes the intake problem accurately, especially the ownership gap and the two channels included. The sales impact remains unverified. If the statement misses another intake route or misstates what was reviewed, please identify that before we define the implementation scope.
Do not ask only “Does this look good?” Identify the parts that need validation. Record factual corrections separately from new requests for work.
Confirmation means the framing is accepted for the stated next step. It does not mean every cause is proven or every recommendation has been approved.
Keep the statement alive as evidence changes
Version the statement with the discovery record. Update it when new evidence changes the affected group, the gap, the impact, or the boundary. Explain what changed and why.
Version 2: follow-up happened but was not recorded
Continuation of the fictional sample: on October 30, the sales lead checks the four flagged journeys against the shared inbox. Dated reply threads show follow-up for three; the fourth has not yet been reconciled. The team had acted on those three inquiries without updating the sales record. Preserve both sources and dates rather than replacing the original observation with a claim that everything was fine.
Problem statement v2, October 30, 2026: The sales export lacks next-action records for four of the 12 selected inquiries. Shared-inbox threads confirm that three received follow-up; one journey remains unresolved. The supported problem is an incomplete shared record of follow-up and ownership for this sample, not four proven unanswered inquiries. A sales or revenue effect is still unknown. The next decision is to test an explicit owner-and-update step for the reconciled route, while the sales lead traces the remaining journey before considering system replacement.
Client confirmation: the sales lead corrects the interpretation on October 30; the founder accepts v2 as the basis for that bounded process check. The sales lead owns the unresolved journey and reviews it November 2, 2026, at 3:00 p.m., America/New_York. This confirms the framing for the next check, not an implementation purchase or a proven business-wide cause.
The convenience sample and two intake routes remain the boundary. Other routes, historical completeness and overall response-time performance require separate evidence. Keep v1 and its correction trail so later readers can see why the recommendation changed.
For your next discovery review, turn one set of notes into this worksheet. Mark every unsupported cause as a hypothesis, then ask which uncertainty matters most before recommending work.