Symptoms vs. Root Causes: What Should You Actually Fix?

A customer support team has a problem.

Eighteen percent of their tickets are missing the company's four-hour response target. Leadership wants the number down, and the pressure is building. The team starts discussing possible reasons: Monday volumes are too high, staffing is too low, tickets aren't being routed correctly, the notification system is unreliable, some requests are more complicated than others, and billing questions seem to get stuck with another department.

All of those things could be true.

But none of them is a root cause simply because someone said it in a meeting.

This distinction matters because improvement teams often move too quickly from seeing a symptom to deciding what must be causing it. Once a plausible explanation takes hold, the conversation can shift immediately to fixing it. The problem is that a plausible explanation is still only a theory until the evidence supports it.

A Symptom Tells You Something Is Wrong. It Doesn't Tell You Why.

The 18% of tickets missing the response target is a symptom. It tells the team that something about the current process is not producing the expected result.

It does not tell them why.

The temptation is to immediately attach a cause to the symptom. "We're understaffed." "The routing rules are broken." "Mondays are the problem." "The billing team is too slow."

Any of those statements might eventually turn out to be supported by the data. At this point, though, they are hypotheses.

That distinction is one of the most important habits in root cause analysis: separate what you know happened from what you think caused it.

The symptom is observable. The cause still needs to be investigated.

Start by Mapping the Possible Causes

Before deciding what the cause is, it can help to organize the possibilities.

A Cause and Effect Matrix or Ishikawa Diagram can be useful at this stage because it gives the team a structured way to organize possible causes instead of letting the loudest theory in the room become the investigation's starting point.

The important word is possible.

A Fishbone Diagram does not prove that every item on it is a cause. It helps the team make its thinking visible and gives the investigation somewhere structured to begin. The next step is determining which of those possible causes are actually supported by evidence.

For the support team, the diagram might contain possible contributors involving people, methods, technology, measurement, workload, routing, and other parts of the process.

The objective is not to fill the diagram with as many ideas as possible. It is to avoid jumping to a conclusion before the team has considered what else could explain the symptom.

A Plausible Cause Is Still Only a Theory

Suppose the team discovers that response times are particularly poor on Mondays.

It would be easy to conclude that Monday workload is the root cause.

But what if Monday also happens to be the day when the least experienced support agents are scheduled? Or when a particular automated routing process runs? Or when another department sends a large batch of requests into the support queue?

The pattern is worth investigating. It is not proof by itself.

This is where data becomes important. Instead of asking which explanation sounds most convincing, the team can start asking questions that can actually be tested.

Are response times consistently worse when ticket volume increases? Are particular categories of tickets more likely to miss the target? Do tickets routed to a specific team wait longer? Does the problem occur only at certain times? Is there a measurable difference between tickets handled through different channels?

The investigation becomes much more useful when each theory leads to a question that can be checked.

Why Multiple Causes Can Exist at the Same Time

Real processes are rarely as simple as finding one culprit and removing it.

A customer support response-time problem might have several contributors. High Monday demand could increase the queue. A routing rule could send some tickets to the wrong team. A particular ticket type could require information from another department. Staffing could make the process more sensitive to those conditions.

Each of those factors could contribute to the symptom without any one of them explaining the entire problem.

This is another reason to be careful with the phrase "the root cause." Sometimes an investigation identifies one dominant cause. Sometimes it identifies several contributing causes. Sometimes the cause is different for different segments of the process.

The goal is not to force every problem into a single-cause explanation. The goal is to understand what is actually driving the result well enough to decide what should happen next.

Don't Confuse Correlation With Causation

A pattern in the data can be extremely useful without automatically proving cause and effect.

Imagine that tickets submitted through the website have a much higher rate of missed response targets than tickets submitted by email. That is a useful finding. It tells the team where to investigate.

But there could still be another explanation. Website submissions might contain more complex requests. They might be routed differently. They might be submitted at different times of day. Or the website form itself might be missing information that email requests usually contain.

The observed relationship is a reason to investigate the connection, not permission to declare the explanation proven.

This is where structured analysis becomes valuable. The team can examine the data, test competing explanations, and determine whether the suspected relationship actually holds up.

Sometimes the Root Cause Is Not Something You Can Eliminate

Finding a genuine root cause does not automatically mean the correct response is to eliminate it.

Some causes are outside the organization's control. Some are technically possible to eliminate but would cost more than the problem they create. Some are inherent to the process or environment. Others occur rarely enough that designing an elaborate prevention mechanism would create more complexity than value.

This is an important distinction because root cause analysis should lead to a decision, not automatically to a mandate to eliminate every cause that can be identified.

The useful question becomes:

Now that we understand what is causing the problem, what is the most appropriate way to deal with it?

Depending on the situation, that might mean eliminating the cause, reducing its frequency, reducing its impact, containing the resulting problem, detecting it quickly, automating a response, recovering from it, or accepting the remaining risk.

When You Measure the Wrong Thing, People Optimize the Measurement

There is another problem that can make root cause analysis surprisingly difficult: sometimes the organization is measuring the wrong thing in the first place.

Consider a call center where employees are measured heavily on Time-to-Completion, or Average Handle Time. The intention may be reasonable. The company wants to reduce waiting, improve efficiency, and avoid spending unnecessary time on individual calls.

But what happens when the metric becomes the thing employees are judged on?

An employee who spends fifteen minutes carefully understanding a customer's problem and resolving it completely may look worse on the performance dashboard than an employee who finishes the same type of call in four minutes.

The four-minute call looks efficient.

But what if the customer still has the problem?

What if the customer calls back the next day? What if another employee then has to investigate the same issue? What if the customer has to explain the entire situation again? The first employee's Time-to-Completion may look excellent while the overall process has actually become less efficient.

The company has optimized the measurement instead of the process.

This is a subtle but important distinction. Reducing unnecessary call time can absolutely be a legitimate improvement objective. If an employee can resolve a customer's problem completely in five minutes instead of ten because unnecessary steps have been removed, that is a real improvement.

The problem comes when call duration becomes a proxy for performance without considering what happened to the customer and the rest of the process after the call ended.

A better investigation would ask what the organization actually wants the process to accomplish. Was the customer's problem resolved? Did the customer need to contact the company again? Was the issue escalated? Did another employee have to perform rework? How much total effort was required before the customer's problem was actually resolved?

Those questions can completely change the interpretation of the original metric.

A long call is not automatically a bad call. A short call is not automatically a good call.

The same principle applies far beyond call centers. A warehouse can optimize the number of orders picked per hour while creating more picking errors. A software team can optimize the number of tickets closed while increasing defects and rework. A hotel can optimize check-in time while making the guest's overall experience worse. A finance team can optimize invoice processing speed while increasing the number of invoices that require correction later.

In each case, the metric may be measuring something real. The problem is assuming that improving that number automatically means the process itself has improved.

This is why a useful process measure needs to be connected to the actual outcome the customer or organization cares about. Otherwise, people can rationally optimize the metric they are being measured against while unintentionally making the overall process worse.

When you measure the wrong thing, people will optimize the measurement instead of the process.

That is not necessarily a failure of the employees. If the system rewards short calls, employees have a rational reason to shorten calls. If it rewards tickets closed, people have a reason to close tickets. If it rewards units produced, people have a reason to maximize output.

The improvement question therefore has to go one level deeper: what behavior is this metric actually encouraging, and does that behavior improve the outcome we really care about?

Sometimes the Best Fix Is to Be Ready for the Failure

There is another option between eliminating a root cause and simply watching for the symptom: design the process to respond when the event happens.

This matters when a condition is known, occasional, and outside your control. If you know something will eventually happen, the question changes from "How do we stop this from ever happening?" to "What happens when it does?"

This is also one of the reasons Failure Mode and Effects Analysis is so useful. An FMEA is not based on the assumption that every possible failure mode can be eliminated. It asks teams to think ahead about what can go wrong, what the consequences would be, how likely or detectable the problem might be, and what controls or actions are appropriate.

In other words, sometimes good process design means preparing for failures that can and will happen rather than pretending they can all be prevented.

That response might be manual, but it doesn't have to be. Automation can detect a condition, trigger a predefined response, and in some cases recover the process without anyone having to intervene.

Consider a system that occasionally loses power. You may not be able to prevent the power outage itself. But you can design the environment around it: backup power can keep the system running through a short interruption, monitoring can detect a longer outage, and the system can be configured to restart automatically when power returns. If one layer of protection fails, another layer of response may be required.

The same thinking applies to business processes. A payment service may occasionally become unavailable. A supplier may miss a delivery. A network connection may fail. A system integration may stop responding. A particular type of customer request may occasionally require much longer than normal to resolve.

You may not be able to eliminate the event. You can still decide what should happen when it occurs.

This is where prevention, detection, response, and recovery become useful ways to think about process design. Cybersecurity has developed this thinking extensively: protect against what you reasonably can, detect problems when they occur, respond quickly, and recover from the resulting disruption.

The same logic applies to process improvement. A well-designed process does not assume that every failure can be prevented. It also asks what will detect the failure, what response should be triggered, how much of that response can be automated, and how the process will return to normal afterward.

Prevent what you reasonably can. Detect what still happens. Respond quickly. Recover reliably.

That is not giving up on root cause analysis. It is recognizing that resilience is part of good process design.

The parallels between cybersecurity and Lean Six Sigma go further than this. Cybersecurity has developed many practices that closely resemble Lean Six Sigma principles, from proactively identifying risks and potential failure modes to detecting problems, responding to them, and designing systems that recover reliably. We explore that connection in more detail in our article on How Cybersecurity Implemented Lean Six Sigma Principles.

Containment Is Not the Same as Corrective Action

This distinction is particularly important when the root cause cannot be immediately eliminated.

Imagine that a known system integration occasionally stops responding. The long-term corrective action might be to redesign the integration. But that could take weeks or months.

In the meantime, the process still needs to work.

A monitoring rule could detect when the integration stops responding. An automated retry could attempt the transaction again. If that fails, the system could route the transaction to a fallback process or alert someone to intervene.

None of those actions necessarily removes the underlying cause. They reduce the impact of the failure and prevent the failure from becoming an uncontrolled customer or operational problem.

That is containment and recovery, and it can be the right response while a longer-term corrective action is being developed.

It is also possible that containment is the appropriate permanent solution. If the underlying event is rare, expensive to eliminate, and inexpensive to detect and recover from, designing a reliable response may make more sense than attempting to eliminate the event itself.

When the Right Answer Is to Monitor, Automate, and Recover

Monitoring becomes particularly valuable when a condition cannot be reliably prevented but can be detected.

The important distinction is what happens after the monitoring detects something.

A dashboard that shows a problem after it has already caused significant damage is useful information, but it is not necessarily an effective control.

A stronger design connects detection to a defined response.

The sequence might look something like this:

Detect the condition → trigger the response → recover the process → escalate if recovery fails.

Automation can make this particularly powerful. Instead of waiting for someone to notice that a process has stopped, the system can identify the condition immediately, execute a predefined recovery action, and only involve a person when the automated response cannot resolve the problem.

This is especially useful when the failure is predictable enough to define in advance but too infrequent to justify constant human attention.

The objective is not to automate everything. It is to make the response appropriate to the problem.

What This Looks Like Back at the Support Team

Returning to the support team's 18% missed-response problem, the first step should not automatically be to find a way to make employees answer tickets faster.

The team should first understand what the metric represents and whether improving it would actually improve the customer's experience and the overall process.

If tickets are being answered quickly but customers frequently have to contact the company again, reducing response time further may not solve the real problem. The process could simply be moving the work somewhere else.

Perhaps Monday demand is genuinely higher and creates a predictable queue. In that case, the process could use a workload trigger to redistribute work or bring in additional capacity before the queue becomes excessive.

Perhaps billing tickets are consistently delayed because another department has to provide information. That might call for a process change to remove or shorten the handoff.

Perhaps routing errors are sending tickets to the wrong queue. That could require a correction to the routing logic combined with monitoring to detect future failures.

Or perhaps some unusual requests will always take longer because of their nature. Trying to force every request into the same response-time target may not be the right answer. The better solution could be to identify those requests immediately, communicate the expected response time, and route them through an appropriate process.

And if the investigation shows that employees are being pushed to close interactions quickly because their performance is heavily tied to Time-to-Completion, the KPI itself may be contributing to the behavior the company is trying to correct.

The symptom is the same: a ticket missed the four-hour target.

But the appropriate response can be completely different depending on what the investigation actually finds.

Structured Tools Help Keep the Investigation Honest

Root cause analysis does not have to rely on whoever happens to have the strongest opinion in the meeting.

Structured tools can help. Five Whys can help a team work deeper into a cause. A Cause and Effect Matrix or Ishikawa Diagram can organize possible causes. Pareto analysis can help identify important contributors. Process data can reveal patterns that aren't visible from a meeting-room discussion. Statistical analysis can help determine whether an apparent relationship is actually supported by the data.

These tools do not replace judgment. They give the investigation a structure that makes it harder to skip important questions.

And sometimes the analysis leads somewhere unexpected.

The most useful discovery may not be a cause that can be eliminated. It may be a cause that needs to be reduced, a failure that needs to be detected earlier, a response that should be automated, or a risk that needs to be consciously accepted and managed.

Where the Concept Ends and the Real Skill Begins

Knowing the difference between a symptom and a cause is the useful judgment this article is actually about. So is knowing when a suspected cause is still only a hypothesis, when multiple causes may be contributing, and when eliminating the root cause is not the only sensible response.

Applying those ideas well requires more than knowing the names of a few tools. It requires defining the problem properly, collecting useful data, separating evidence from assumptions, testing competing explanations, and choosing a response that fits the actual risk and economics of the situation.

The same is true of FMEA, Fishbone analysis, Pareto analysis, statistical testing, and the other tools used during improvement work. Knowing what a tool does is different from knowing when to use it, how to use it correctly, and how to turn what it tells you into a sustainable process change.

That practical application is where Lean Six Sigma becomes more than a collection of tools. It becomes a disciplined way of understanding how processes actually behave and deciding what to do about what you find.

What the Support Team Changed

The investigation did not produce one magical fix.

Instead, the team separated the different contributors and addressed each one according to what the evidence showed.

Monday demand was handled with a workload trigger and a defined response. The billing handoff was redesigned to reduce unnecessary waiting. Routing errors were corrected and monitored. Unusual requests were given a different path rather than being forced through a process designed for routine tickets.

Most importantly, the team stopped treating the original symptom as though it automatically contained its own explanation.

The next time response performance drops, the question is no longer simply, "What should we fix?"

It is:

What is actually happening, why is it happening, and what is the most appropriate way to deal with it?

Sometimes that means eliminating the root cause. Sometimes it means reducing it. Sometimes it means containing the effect. Sometimes it means detecting the failure and automatically recovering from it.

Root cause analysis is not just about eliminating causes. It is about understanding the cause well enough to decide what the process should do next.

Frequently Asked Questions