Diagnose a client problem by defining the observed difficulty, comparing plausible causes, and checking evidence that could change your recommendation. Keep the requested deliverable separate from the reason the client believes it is needed.
“We need a redesign” describes a proposed response. It does not establish whether the problem is unclear messaging, unsuitable traffic, a broken inquiry route, or something else.
Sometimes the client's request is already appropriate. Diagnosis should test the relevant assumptions, including your own, without creating unnecessary analysis.
A freelance discovery call can establish the context; diagnosis then checks the explanations that matter.
Define the problem before explaining it
Start with something specific enough to investigate.
“Our sales are poor” is too broad. “Qualified inquiries from the website declined after the booking process changed” gives you a population, an observed change, and a possible time boundary.
Ask what the client means by the key terms. A lead, qualified lead, booked appointment, and paying customer are different outcomes. If different people use the same word differently, the analysis can appear precise while answering the wrong question.
Write a preliminary statement that includes:
- Who or what is affected.
- What is happening compared with the intended result.
- Where and when it occurs.
- What evidence is available.
Keep the suspected cause separate. “The booking form is broken” is a conclusion; “Fewer visitors complete the booking process” is a problem to investigate.
Compare explanations instead of falling in love with one
Consider this fictional brief: a consultant requests ten new articles because website inquiries have fallen.
There are several plausible explanations. Fewer relevant visitors may be arriving. The service offer may be unclear. The form may not work. Measurement may have changed. More than one explanation may apply.
| Possible explanation | Evidence that would support it | Evidence that would weaken it |
|---|---|---|
| Less relevant traffic | Fewer visits from sources that previously generated suitable inquiries | Relevant traffic is stable across comparable periods |
| Form or routing failure | A test submission fails or does not reach the responsible person | Tests arrive successfully and recent real submissions are handled |
| Offer mismatch | Suitable prospects repeatedly misunderstand or reject the service proposition | Prospects understand the offer and the drop occurs later in the process |
| Measurement change | The inquiry tracking event changed when the reporting drop appeared | Independent inquiry records show the same decline |
This table does not prove any cause. It shows which checks could change the recommendation.
If a test identifies a broken form, publishing ten articles does not resolve that failure. If the form works and relevant traffic has fallen, content might be part of the response—but the topics and distribution still need investigation.
Read the decision map as text
- Less relevant traffic?: Compare relevant visits across suitable periods. Stable relevant traffic weakens this explanation.
- Form or routing failure?: Test submission and receipt by the responsible person. Successful tests weaken, but do not eliminate, this explanation.
- Offer mismatch?: Check where suitable prospects misunderstand or reject the offer. A later-stage drop suggests checking other causes.
- Measurement changed?: Check tracking changes against independent inquiry records. Matching declines in independent records weaken this explanation.
Fictional situation: website inquiries have fallen. More than one cause can apply. These checks do not establish a diagnosis by themselves.
Use “why” questions carefully
The American Society for Quality's root-cause analysis guidance describes several approaches to finding causes, including examining changes and failed controls. Its five-whys guidance is another useful starting point for exploring a causal chain.
Repeatedly asking why can expose assumptions. It can also produce an increasingly confident story that nobody has tested.
For example:
Why are proposals late? Because project managers are busy.
That answer might be true, incomplete, or wrong. Perhaps pricing approvals sit with one unavailable director. Perhaps each proposal includes unnecessary custom work. Perhaps “late” was never defined.
Treat each answer as something to investigate. There is no rule that the fifth answer is the real cause, and a client-service problem may involve several interacting conditions.
Choose the smallest useful evidence check
You do not need an extensive audit for every question. Choose a check that could distinguish between the leading explanations.
Examples include tracing a few recent inquiries, testing the relevant workflow, comparing the current and previous brief, or speaking with the person who performs the affected task.
Match the check to the stakes. A quick observation may justify fixing an obvious typo. It is a weak basis for replacing a business-critical system.
Be equally careful with sample size. Three inquiry journeys may reveal a handoff failure worth correcting. They cannot establish the business's overall conversion rate or show how common the failure is.
Hypothesis testing log
Keep one record for each explanation you are testing. This working log extends the cause-and-evidence approach above: record contrary evidence before choosing a recommendation.
Hypothesis: [Possible cause, not a conclusion] Supporting evidence: [Observation / source / date] Contradicting evidence: [What weakens this explanation] Test: [Smallest useful check / owner / date] Sample / period: [Cases examined / comparison window / selection limits] Environment / route: [Device, browser or work setting / entry route / version] Finding: [What happened] Confidence / limit: [What this supports / what remains untested] Decision: [Retain / revise / reject / unresolved] Next check: [Action / owner / due date]
Worked log: revise the explanation when evidence changes
Hypothetical teaching log, October 29, 2026. These are invented observations showing how to document a check, not test results from a real client.
- Hypothesis: fewer suitable visitors explain the inquiry decline. Supporting evidence: the client reports fewer inquiries. That report establishes the symptom to investigate, not its cause.
- Sample / period and contrary evidence: comparable records for September 1–30 and October 1–28 show stable daily visits from the same relevant sources. Source coverage and the meaning of “relevant” are checked with the client. These windows do not rule out seasonality or a change in visitor intent.
- Test / environment: the consultant submits labeled test T1 through the current service-page form on October 29, desktop Chrome, with an authorized synthetic address. The confirmation page appears, but the responsible person finds no receipt in the agreed inbox or spam check. A second labeled test T2 from the mobile contact-page route reaches the inbox. Record the actual device/browser versions, timestamps and form versions in a live investigation.
- Finding and confidence / limit: one tested route failed while another succeeded. This weakens a site-wide traffic explanation and a claim that every inquiry route is broken. It supports investigating the desktop service-page route; it does not identify the technical cause, quantify historical losses or prove all mobile submissions work.
- Decision / next check: the authorized site owner compares form routing and recipient settings for the two routes. After correction, the consultant repeats both labeled journeys on October 30 with the same stated conditions and confirms receipt with the inbox owner. Both arrive in this fictional retest. The record retains the original failure and correction evidence. Expand testing to other material routes or devices before making a broader reliability claim.
The successful retest supports proceeding with that corrected route under the tested conditions. It does not establish that extra content is unnecessary forever, or that historical conversion has recovered. Those require their own evidence.
When evidence is missing: mark the finding “unresolved,” name the access or record required, and assign its next check. If the missing evidence could change the proposed work, pause that commitment or scope a bounded assessment. Do not treat an untested hypothesis as a confirmed root cause.
State the recommendation at the right confidence level
Use language that distinguishes what you know from what you infer:
- Observed: “The test submission did not reach the monitored inbox.”
- Supported interpretation: “The current routing appears to be preventing this type of submission from reaching the team.”
- Remaining uncertainty: “We have not established whether earlier inquiries were also affected.”
- Recommended action: “Repair and retest the routing before increasing acquisition spending.”
Do not inflate the business impact. If you cannot quantify lost inquiries or revenue, say that. A plausible operational problem is enough to justify an appropriate investigation without inventing a financial loss.
Check the pattern against an exception
An explanation becomes more useful when it can account for both the problem and a situation where the problem does not occur.
In the fictional inquiry example, suppose direct email inquiries receive prompt replies while form inquiries do not. That difference points you toward the form's routing and ownership. If both routes show the same problem, the investigation may need to examine a shared handoff instead.
The exception narrows the next check; it does not establish causation by itself. Compare relevant cases and consider other differences, such as inquiry quality, staffing, or when each request arrived.
Ask the client for a recent example that worked, as well as one that failed. Then write what differs and which difference you can test. This keeps diagnosis from becoming a story built only from confirming evidence.
If a client already has a verified problem and a suitable, bounded request, use that evidence. You do not need to invent a deeper cause to demonstrate expertise or sell an assessment.
Document the agreed diagnosis with a problem statement from discovery notes that distinguishes evidence from assumptions.
Apply the same test outside a website project
Hypothetical consulting example: a studio says proposals are late because writers lack capacity. A consultant traces three delayed proposals from October 1–28: writing finished before the promised date, but pricing approval waited with an absent director. One on-time proposal had an available authorized substitute. That contrary case shifts the next check toward approval coverage, rather than hiring a writer.
The studio owner checks approval timestamps and delegation authority before testing a backup route on the next eligible proposal. The three selected cases justify inspecting that handoff; they do not establish how common the delay is or prove that a substitute will remove every cause. If the timestamp records are missing, the cause stays unresolved.
Know when to stop investigating
Diagnosis is useful when it improves a decision. It becomes wasteful when every answer triggers another round of analysis without changing the action.
Ask whether the remaining uncertainty could materially change the recommendation. If not, proceed with a bounded step and monitor what happens. If it could, define the further work needed and who should perform it.
Some problems exceed your competence or the available access. A designer should not present an unsupported security diagnosis as fact. A copywriter cannot responsibly attribute a revenue decline to one message without examining other relevant changes.
Explain those limits and involve the appropriate specialist when necessary.
A supported conclusion gives you a basis to package a service around suitable work.
Give the client a conclusion they can challenge
End with a short explanation of the problem, the evidence, the leading interpretation, and the proposed next step. Ask what contradicts your understanding.
For the fictional website brief:
The immediate issue is that inquiry submissions are not reaching the monitored inbox in our test. We have not measured the historical impact. I recommend repairing and verifying that route before deciding whether new content is the next priority.
That is more useful than “Your real problem is strategy.” It identifies a specific decision and leaves room for correction.
Before drafting a service offer, write one sentence stating why the proposed work addresses the supported problem. If you cannot do that yet, the next task is to resolve the missing evidence—not to make the offer sound more persuasive.