Root Cause Analysis for Recurring Small-Business Problems

When the same mistake returns after a reminder or retraining session, investigate what allowed it to happen. A missing field, an unclear approval, or a faulty handoff can look like an employee error until you trace the actual work records.

Root cause analysis is a way to investigate a recurring problem before choosing a fix. For everyday small-business problems, start by examining actual examples, tracing where the failure became possible, and checking your explanation against evidence. A simple Five Whys conversation often helps, but the number five isn’t a rule, and one chain of questions may miss a second cause.

Start with a problem you can observe

“Our billing process is broken” covers too much. A useful problem statement would say: Some completed service jobs reached billing without the approved final scope, leaving the bookkeeper unable to prepare the invoice. That describes the failure, where it occurs, and the missing information without deciding who or what caused it.

Gather a small sample of affected job records alongside a few that went through normally. Compare dates, handoffs, and exceptions. The manager may discover that routine jobs are invoiced quickly while jobs with extra approved work get stuck. That difference gives the team something worth investigating.

Keep an immediate problem from getting worse while you investigate. If an invoice is missing, restore the required job documentation and resolve it with the appropriate owner. Then investigate why it happened. This separation between containing the current issue and preventing another one is essential for practical problem-solving.

Use the Five Whys to build a possible explanation

Gather the people who actually touch the work, including anyone who handles exceptions. Start with the problem statement and ask what made the failure happen. For each answer, ask why that condition existed. Avoid treating the first person who appears in the chain as the root cause.

Here is a fictional example showing how the conversation might go. The answers are hypotheses until someone checks the records and tools.

Question	Possible answer to investigate
Why was the invoice delayed?	Billing never received the approved scope of extra work.
Why was that scope missing?	The closeout record contained only a completion photo and a short note.
Why didn’t the record include approved changes?	The closeout form had no field or linked reference for a changed work order.
Why was the field missing?	The original form was designed around routine jobs with unchanged scope.
Why wasn’t that gap found when the form changed?	The rollout test covered a routine completion but not a job with an approved change.

The final answer suggests a design and testing failure rather than a careless employee. It doesn’t prove the answer is correct. Check several affected closeout records, the form configuration, any approved change orders, and what billing actually sees. If the facts don’t match the chain, rewrite it.

The American Society for Quality describes the Five Whys as an investigation method, and the Institute for Healthcare Improvement notes that more than one contributing cause may exist. In practice, a missed invoice might also involve an export failure, incorrect permissions, or an unclear supervisor handoff. Follow those branches if the evidence points to them.

Know when this simple technique isn’t enough

Five Whys is handy for an understandable recurring failure with a short chain of events, like information missing at a handoff. It is less suitable as your entire investigation when multiple systems interact, causes are disputed, or the potential harm is severe.

For a workplace injury, suspected fraud, a safety failure, or a regulated incident, use the reporting and investigation obligations that apply and involve qualified personnel. Do not use a quick Five Whys worksheet in place of an appropriate formal investigation. Even in an ordinary business process, stop claiming a single root cause when the evidence shows several contributors.

Make room for the employee who sees the problem most often. A supervisor may assume someone “forgot to save,” while the employee knows the save control is hidden on a small screen or appears only after a particular status is selected. A quick demonstration can change the investigation substantially.

Turn the evidence into a corrective action

A credible action changes the condition that allowed the failure. In the billing example, retraining might be useful, but the more durable fix may be to link the approved change order to the closeout record, make the billing-ready state conditional on that reference, and test the exception before rollout.

Write the action so someone knows exactly what to do and how success will be checked:

Decision	Example action
Evidence supporting the cause	Several delayed jobs show the same missing change-order reference; routine jobs do not.
Immediate containment	Office coordinator collects the missing approved scope for affected invoices.
Corrective change	Process owner updates the closeout form and its handoff rule.
Owner and timing	Office manager assigns a named owner and an achievable test date.
Practice test	Run a completed job with changed scope and confirm billing receives the approved reference.
Follow-up	Review a small set of actual changed-scope jobs after rollout and check whether the missing-reference problem recurs.

This example is deliberately specific about what must change, but it doesn’t invent a percentage improvement. Choose a measure your existing records can support. If the issue is too rare for a percentage to mean much, a case-by-case review may be better.

Watch for the common wrong fixes

“Tell staff to pay more attention” is attractive because it’s quick and costs nothing to announce. It can also shift blame onto people without addressing the system they use. An extra mandatory checkbox is another easy mistake: it may add work while providing no useful evidence or decision.

Before adding a control, ask what failure it will catch, when it will catch it, and who can act. If a booking must not be confirmed without an approved time slot, the check belongs before confirmation, not on a report a manager reads after the customer arrives.

Don’t assume a new software system will solve an unassigned decision. A tool can route a ticket, but someone still has to define when it changes hands, what information is required, and what happens when it cannot proceed.

Copy this short root cause analysis worksheet

Use these prompts with two or three people who know the work. Write down facts separately from guesses so the investigation doesn’t harden an assumption into policy.

When you’ve identified a real handoff failure, you may need to map the process, update the appropriate SOP, and train employees on the new version. Keep those tasks connected rather than filing away the analysis after the meeting.

Back to Operations.