Root Cause Analysis Template (With a 5 Whys Example)
By the SystemaFlow team · Updated November 2026 · Share this
It's the third month running that the client invoices have gone out late. Each time, someone stayed late, chased the missing figures and got them sent. Each time it felt fixed, and the next month it happened again.
A root cause analysis template is a one-page form that takes one repeat problem from what happens, back through why it happens, to a cause you can change, then records one fix, who owns it and how you'll check it worked. The 5 Whys is the simplest way to fill in the middle: ask why the problem happens, then why that happens, and stop when the answer is something in your own hands.
Below there's a template to copy, a 5 Whys tool you can fill in on this page, a worked example, a short guide to fishbone diagrams for problems with several causes, and how to turn a cause into a fix that lasts.
Here's the example we'll use. Tamberly Studio is a small design studio we made up for our training material. Priya runs it, and Grace has just taken over invoicing. The details are invented.
Root cause analysis template (copy this)
One problem per page. Copy this into Word, Google Docs or wherever your team keeps its notes.
ROOT CAUSE ANALYSIS: ONE REPEAT PROBLEM WHAT HAPPENS The problem (what you can see, without blaming anyone): How often: Who found it, and when: What it costs (time, money or goodwill, roughly): THE CAUSE What it looked like (the first explanation anyone gave): Why 1: Why does the problem happen? Why 2: Why does that happen? Why 3: Why does that happen? Why 4: Why does that happen? Why 5: Why does that happen? The real cause (the first answer that's in your own hands): THE FIX One change that removes the cause: Who owns it: Starts on: Where it's written down (the checklist, SOP or page to update): THE CHECK What you'll count to know it worked: Check on (date): Result: NEXT ACTIONS Action | Owner | Due date | Status
What each part is for:
| Part | What goes in it | Why it's there |
|---|---|---|
| What happens | Plain facts: what goes wrong, how often, what it costs | So you're fixing a real, repeated problem and can say why it's worth the time |
| What it looked like | The first explanation anyone gave | Because the first explanation is so often wrong, and writing it down lets you test it |
| The whys | Each answer becomes the next question | To get past the symptom to something you can change |
| The real cause | The answer you stopped at | So everyone agrees what the fix has to remove |
| The fix | One change, one owner, one start date, and where it's written | So it lasts beyond the week everyone remembers it |
| The check | Something you can count, and a date | Without it, you only hope the problem's gone |
Try the 5 Whys on your own problem
Pick something that's gone wrong at least twice. A missed follow-up, a late payment or a job that keeps coming back for rework will all do.
Your 5 Whys
Describe one problem, then answer each why. Stop when the answer is something you can change. What you type stays in your browser and is gone when you close the page, so copy it before you leave.
Your root cause shows here once you've answered a why. It's the last answer in your chain.
You don't have to fill all five. If you stopped at a person ("because Sam forgot"), ask one more why: why does the job depend on Sam remembering?
Also on its own page: the free 5 Whys tool, to keep open while you work through a problem.
How to run a 5 Whys that finds the real cause
The method is usually credited to Toyota's production system. It's simple, which is why it's easy to do badly. These habits make the difference.
- Describe the problem, not the person. "Invoices go out after the 3rd working day" gives you something to work on. "Grace is slow" gives you an argument.
- Take one problem at a time. A page listing ten problems gets fixed by nobody.
- Write down the first explanation, then test it. It's what everyone already believes, and it's often wrong.
- Answer from evidence. Look at the dates, the emails and the job itself. If you're guessing, say so and go and check.
- Stop when the answer is in your own hands. "The client's slow to reply" isn't something you can change. "We don't chase until the deadline has passed" is.
- Ask the people who do the work. They'll tell you which answer is true. If the cause sits with another team, bring them in before you choose the fix.
Where it goes wrong. A chain that ends at a person ("because Sam forgot") has stopped one why too early. People forget, so the useful question is why the work relies on someone remembering. A chain can also branch: if two answers to the same why are both true, follow each one. When you find you've got several branches, a fishbone diagram will help (there's more on that below).
A 5 Whys example: late invoices at Tamberly Studio
This is a made-up example, taken from our free pack. In August, Grace has just taken over invoicing. Client invoices have gone out after the 3rd working day of the month for the last two months in a row. The cash arrives later, and about two hours a month go on chasing timesheets.
Everyone's first explanation was that Priya was too busy, and only she knew how to send the invoices. Grace asked why instead.
| Question | Answer |
|---|---|
| The problem | Client invoices go out after the 3rd working day of the month |
| Why 1: Why do they go out late? | They can't be sent until every timesheet for the month is in |
| Why 2: Why aren't the timesheets in? | They arrive late, because people fill them in once a month, from memory |
| Why 3: Why does nobody catch that sooner? | Until this week, nobody owned collecting them |
| The real cause | Timesheets are filled in once a month from memory, and nobody owned collecting them |
Three whys were enough, because the third answer was something the studio could change.
The fix: everyone fills in their timesheet before leaving on Friday, not once a month from memory. Grace checks at 16:00 and asks anyone who's missing. She owns it, it starts on Monday 17 August and it's written into step 1 of the studio's invoicing task card.
The check: every timesheet in every Friday, and August's invoices out on the 3rd working day. Grace will look on Thursday 3 September. The first Friday, they were all in on time.
Priya wasn't the cause. If the studio had acted on the first explanation, it would have moved the work to someone less busy and kept the late timesheets.
Fishbone diagram, in brief
Some problems have several causes at once. The 5 Whys follows one chain, so it can miss the others. A fishbone diagram, also called an Ishikawa diagram, puts the problem at the "head" and lists possible causes along "bones" grouped under headings.
Manufacturing teams often use six headings that begin with M, such as machines, methods and materials. For a small service business, plainer headings work better:
| Heading | Ask |
|---|---|
| People | Does the person have the skill, the time and someone to cover? |
| Process | Are the steps clear, in the right order, with a clear handover? |
| Tools | Is the software, template or access getting in the way? |
| Information | Is it written down, and does it reach the right person in time? |
| Clients and suppliers | Does what comes in arrive late, incomplete or changed? |
| Timing and workload | Does the problem cluster in busy weeks or around certain deadlines? |
You don't need a drawing. A list works as well:
FISHBONE: [the problem] People: Process: Tools: Information: Clients and suppliers: Timing and workload: Most likely causes (pick two or three, then run a 5 Whys on each):
A made-up but typical case: a small agency's proposals keep going out late. Under Process there's "no agreed date for the first draft". Under Information, "pricing for new services isn't written anywhere". Under Timing and workload, "proposals land in the same week as month-end reporting". The team picks the first two and runs a 5 Whys on each.
From the cause to a fix and a check
Finding the cause is half the job. These rules turn it into a change that stays put.
One fix, aimed at the cause. If the cause is "nobody owns collecting timesheets", the fix gives someone that job. Telling people to be more careful doesn't touch the cause.
Make it specific. Compare these:
| Weak fix | Stronger fix |
|---|---|
| Remind everyone about timesheets | Timesheets done before leaving on Friday; Grace checks at 16:00 |
| Be more careful with client briefs | "Brief signed off" becomes step 1 of the project checklist, owned by the project lead |
| Train Sam again | Write the job as a one-page SOP, then Sam does it once while the writer watches |
Give it one owner and a start date. The RACI chart post explains why one name works better than two.
Write it where the work happens. Update the checklist, task card or SOP people already use. A fix that lives only in the meeting notes fades once the meeting's forgotten.
Choose a check you can count, with a date. "All timesheets in by Friday for four weeks" can be checked. "Timesheets are better" can't.
If the problem comes back, ask why again. It means the cause you found wasn't the real one, or there was a second. That's useful information, and it's why the check matters.
A fix that needs a reminder every week is a sign the process around it is missing an owner, a trigger or a review. That gap is what makes a process into a system.
When root cause analysis is overkill
Save it for problems that repeat or cost real money. A one-off mistake that took ten minutes to put right needs an apology and nothing more.
| Situation | What we'd do |
|---|---|
| A one-off slip, quickly fixed | Fix it and move on |
| The same thing has gone wrong twice | A quick 5 Whys, on your own or with one colleague |
| It keeps happening and it costs time, money or a client's goodwill | The full template, with the people involved |
| Several things seem to be causing it at once | A fishbone first, then a 5 Whys on the likely causes |
| A whole process feels slow and leaky | Walk it step by step before you fix any one part |
If you've got more repeat problems than time, what to systemise first will help you pick the one that matters most. If you've fixed things before and they didn't hold, why business systems don't work covers the usual reasons.
Want the full version?
When the repeat problem is a task that keeps getting missed, Missed Task Rescue in the Ops Fundamentals pack recovers it the same day, matches one of four causes to its fix and checks it over the next two times the task falls due. It's in the Setup and Foundations Mini Vault. To walk a whole workflow step by step and time every wait, use the Workflow Audit System in the Ops Audit and Optimisation pack, part of the Strategy to Execution Core Vault. Both are done-for-you templates in Word and PDF.
See what's in the Setup and Foundations Vault →Or get all 352 systems, and every one we add later, with Masterworks: $999, paid once.
Was this helpful?
Frequently asked questions
- What is a root cause analysis template?
- A one-page form for a single repeat problem. It records what happens, works back to the cause you can change, then sets one fix with an owner and a dated check that the fix worked.
- What's the difference between the 5 Whys and a fishbone diagram?
- The 5 Whys follows one chain of causes by asking why again and again. A fishbone diagram lays out many possible causes under headings, so it suits problems with several causes at once. You can use the fishbone to find the likely causes, then a 5 Whys on each.
- Do you always have to ask why five times?
- No. Five is a rule of thumb. Stop when the answer is something in your own hands that would stop the problem if you changed it. That might take three whys or seven.
- Is there a free 5 Whys template?
- Yes. Copy the template on this page, or fill in the 5 Whys tool and copy the result. The editable Word and PDF version is Fix It Once, which comes in our free pack, The Business Operating Manual, when you sign up with your email.
- Can I do a root cause analysis on my own?
- You can start alone, but check your answers with the people who do the work. They know which explanation is true, and a fix they helped choose is more likely to stick.
