Root Cause Analysis Template (2026): A Copyable RCA for Revenue, Margin and Stock Problems

TL;DR

This root cause analysis template is built for business metrics: revenue dips, margin drops, conversion falls and stock gaps. It records a measurable problem statement, a timeline of verified events, a 5 whys table that demands evidence and a source at every step, contributing factors, and a corrective action with an owner, a due date and a check. Copy it as a table or as plain text below. A dashboard can show a margin drop without showing the email that approved a pricing exception, which is why the template asks where each answer came from. It is published by Sentra, which understands how a company really runs, and acts on it before anyone asks. Sentra connects ERP, CRM and HRIS records with the conversations behind them so each row can cite its source.

What root cause analysis is, and why business metrics need their own version

Root cause analysis (RCA) identifies why a problem occurred so you can correct the cause rather than only the symptom. ASQ describes it as a collective term for the approaches and tools used to uncover causes of problems. For a business metric the work follows five steps: define the change, collect evidence, identify possible causes, test them against the evidence, then document and carry out a corrective action.

Traditional RCA tools grew out of quality control. The fishbone diagram, associated with Kaoru Ishikawa, sorts possible causes into categories such as people, process and equipment. The 5 whys method follows each answer with another why. The fishbone organizes candidate causes, while the 5 whys tests one chain of explanation. Neither substitutes for evidence about a specific metric.

A seized pump gives you a component to inspect. A margin drop may require you to connect a BI report to transaction records and to an email approving a pricing exception. For revenue, conversion or stock problems, you need to trace what changed in the metric and which recorded decision or event caused it.

The root cause analysis template

Copy the template below for any metric problem. Every answer in the 5 whys table needs both evidence and a way to find its source. The template also records who owns the corrective action, when it is due and how you will check that it worked.

Template as a table

Template as plain text

ROOT CAUSE ANALYSIS

Problem statement
  [Metric] changed from [baseline] to [observed] during [period] for [segment],
  a change of [amount / %]. Impact: [impact]. (No assumed cause.)

Timeline (verified events only)
  Date/time | Event | Evidence | Source (record + location)

5 whys
  1. Why did [metric] change?      Answer | Evidence | Source | Verified? Y/N
  2. Why did [answer 1] happen?    Answer | Evidence | Source | Verified? Y/N
  3. Why did [answer 2] happen?    Answer | Evidence | Source | Verified? Y/N
  4. Why did [answer 3] happen?    Answer | Evidence | Source | Verified? Y/N
  5. Why did [answer 4] happen?    Answer | Evidence | Source | Verified? Y/N

Contributing factors
  [Factor] | Source

Corrective action
  Owner: [name]  Action: [change]  Due: [date]  Outcome: [measurable target]

Verification
  Owner: [name]  Check on: [date]  Metric: [metric]  Target: [value]  Result: [ ]

For each source, record enough detail to retrieve it: a report date, an email subject, a meeting date, or the name and date of an owner's statement. Restrict sensitive records to the people already permitted to see them. If a row rests on an assumption, mark it unverified and gather evidence before treating it as a cause. Five rows are a starting structure, not a rule to stop after the fifth answer.

Worked example: a quarter-end margin drop

In this illustrative example, gross margin fell from 32% in Q3 to 27% in Q4. A BI dashboard showed the decline. The analyst checked renewal records and approval conversations rather than assuming a single pricing decision caused the whole change.

Problem statement. Q4 gross margin was 27%, down from 32% in Q3, a five percentage point decline in the share of revenue retained after direct costs. Timeline. A sales meeting took place on 18 December. The sales director approved a discount by email on 19 December, and the account manager entered the quote on 20 December. Finance saw the decline in the BI dashboard on 3 January.

Contributing factor. The pricing system did not require finance approval above the standard rate. Corrective action. The finance lead will add a finance approval step for discounts above 8% by 31 January. Verification. Next quarter, the finance lead will check the exception log to confirm that every quote above the threshold was approved before it was sent.

The example does not yet prove that the 18% discount caused the full five-point company-wide decline. The analyst would need to compare the affected renewals' revenue and costs with the rest of Q4 first. A variance analysis that splits the margin change by customer and price does that sizing. If the December meeting notes do not record the decision, the fifth answer also remains a hypothesis.

Why the first plausible answer may be wrong

Under deadline pressure, it is easy to mistake the first explanation on a dashboard for the cause of a falling metric. Investigators skip evidence collection, treat hearsay as fact and recommend fixes based on assumptions. An ERP report might show that a stockout preceded a revenue dip, but it cannot explain why the buyer held the reorder if the approval happened in email. A supplier's OTIF report for the same weeks can look healthy too, because it counts only the orders that were placed.

It helps to separate physical causes, such as the observable shortage, from human causes, such as the buyer's decision, and latent causes, such as an approval rule that delayed the order. A chat thread might show that the buyer followed an outdated rule rather than misreading a forecast. Fixing the forecast would leave the rule in place.

The 5 whys follows one causal chain, but a business metric often has several contributing causes. Use a fishbone diagram to map alternatives when one chain cannot account for the whole change, and treat every plausible answer as a hypothesis until the system record and the conversation behind it agree.

How to run the analysis without stalling

• Keep it blameless. Ask what information a pricing manager had when approving an exception, not who caused the margin drop. People explain decisions more fully when they are not defending themselves.
• Keep the group small. Bring in the people who can explain the metric or retrieve the records, and give one person the evidence log.
• Look before the reporting period. Find when the metric first changed, then check earlier approvals and conversations. Record the date a decision was made separately from the date its effect appeared in ERP, CRM or BI.
• Separate facts from hypotheses. Keep verified events in the timeline and possible causes in the conclusion. If an approval record is missing, mark the question open.
• Close the loop. Assign someone to check whether the corrective action worked. If the metric stays low after a rule changes, reopen the analysis and record the decision in a decision log so the next team can see what was tried.

How Sentra connects metric changes to decisions

Sentra understands how a company really runs, and acts on it before anyone asks. It reads email, chat, meetings and documents alongside ERP, CRM, HRIS and BI data, and works out what is true now and why. An ERP record can show a lower invoice price without recording why someone approved the discount. Sentra links the price to the email thread or meeting note where the approval happened, so the analyst sees an approved exception instead of guessing at a data entry error, and it raises the developing problem to the person who can act.

A named person approves anything Sentra raises before it reaches anyone else. Every claim cites its source, and permissions follow the source. Sentra replaces none of the company's systems. At Lenskart, time to root cause fell from 3 to 4 days to about 30 minutes in Sentra's own measurement as of October 2026.

FAQ