Free FMEA Template
Failure mode and effects analysis (FMEA) finds what could go wrong in a process before customers feel it, and ranks the risks so you fix the biggest first. Start from a filled-in service process example, then run your own on the blank worksheet; RPN is calculated for you.
What is in the pack
- Filled-in example first: FMEA of an online order returns process, before and after the actions
- Blank FMEA worksheet: RPN calculated, high-risk rows highlighted
- Rating scales for severity, occurrence and detection (1-10), written for service processes
- The worksheet as a Word document, plus a printable PDF (example, blank and rating scales)
What is FMEA?
FMEA (failure mode and effects analysis) is a structured way to list the ways a process can fail, what each failure does to the customer, why it happens and how likely you are to catch it. It started in engineering and manufacturing, and works just as well for service processes such as returns, onboarding or billing.
Each failure mode gets three scores from 1 to 10: severity (S), how bad the effect is; occurrence (O), how often the cause happens; and detection (D), how likely your current controls are to catch it before the customer does (10 means they will not). Multiply them to get the risk priority number: RPN = S × O × D, from 1 to 1,000.
A root cause analysis explains a problem that already happened; FMEA looks ahead. Use it when you design or change a process, and after an incident to see where else the same kind of failure could happen.
Example: FMEA of an online order returns process
Illustrative example, not customer data. This is page 1 of the template; page 2 is the same worksheet, blank.
| # | Process step | Failure mode | Effect on the customer | S | Cause | O | Current control | D | RPN | Recommended action | Owner, due | New S | New O | New D | New RPN |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Return request | Customer cannot find the return option for a marketplace item | Customer contacts support or gives up; complaint, low rating | 5 | Return button hidden for marketplace orders in the app | 6 | Monthly review of tickets tagged "return" | 7 | 210 | Show the return button on every eligible order; tag "can't find return" tickets | Product manager, week 4 | 5 | 2 | 4 | 40 |
| 2 | Return label | Return label email not sent | Customer cannot send the item back; refund delayed, repeat contacts | 6 | Label service times out at peak hours, with no retry | 4 | None: customers contact support | 8 | 192 | Automatic retry; label also downloadable on the order page; same-day alert for unsent labels | Engineering lead, week 3 | 6 | 2 | 3 | 36 |
| 3 | Receiving | Returned parcel received but not linked to the order | Refund never starts; customer chases support | 7 | Parcels without the printed label go to a manual pile | 5 | Weekly review of the manual pile | 6 | 210 | Pre-printed return label in every parcel; alert when the carrier shows a return delivered but not scanned within 2 days | Warehouse lead, week 2 | 7 | 3 | 3 | 63 |
| 4 | Inspection | Item wrongly graded as damaged by the customer | Refund refused or cut; dispute or chargeback | 8 | No photo or grading standard; inspectors judge differently | 4 | Supervisor reviews disputes after customers complain | 8 | 256 | Photo at receiving and a grading guide with examples; second inspector before any refusal | QA lead, week 5 | 8 | 2 | 2 | 32 |
| 5 | Refund | Refund paid after the 5-day promise | "Where is my refund?" contacts, complaints, chargebacks | 6 | Finance runs refunds twice a week | 7 | Weekly report of refunds older than 5 days | 6 | 252 | Daily refund run; alert for refunds older than 3 days | Finance operations manager, week 6 | 6 | 3 | 3 | 54 |
| 6 | Notification | Customer not told that the refund was paid | Extra contacts asking about the refund | 4 | No refund email for partial refunds | 5 | None: customers ask support | 8 | 160 | Refund email for every refund type; refund status on the order page | CRM manager, week 4 | 4 | 2 | 4 | 32 |
| 7 | Refund | Wrong amount refunded on a split-payment order | Customer loses money or the company overpays; trust and compliance risk | 9 | Refunds for split-payment orders are entered by hand | 2 | Finance checks every manual refund daily | 5 | 90 | Refunds only from the order record, split payments handled by the system; second approver for exceptions | Finance operations manager, week 3 | 9 | 1 | 2 | 18 |
| Total RPN | 1,370 | 275 | |||||||||||||
RPN 200 or more: high (red). 100 to 199: medium (amber). Any severity 9 or 10 is treated as high, whatever the RPN. These thresholds are a team choice, not a standard.
Total RPN fell from 1,370 to 275. Before the actions, the biggest risk was the inspection step (256), not the most frequent failure: late refunds happen more often (O 7) but are easier to catch. Row 7 has the lowest RPN (90) but severity 9, because the customer can lose money, so it got an action anyway.
How to run an FMEA, step by step
- 1Pick the process and its scope, and map the steps from start to end. Bring the people who run it: front line, operations, product, finance.
- 2For each step, list the failure modes: the ways the step can go wrong.
- 3For each failure mode, write the effect on the customer and score severity (S).
- 4Write the cause and score occurrence (O); write the current control and score detection (D).
- 5Calculate RPN = S × O × D. Sort by severity first, then RPN, and agree which rows need action.
- 6Give each action an owner and a due date. When it is done, score S, O and D again and record the new RPN.
FMEA rating scales (1-10)
Written for service processes. Agree on the scales before you score, and keep them the same between FMEAs so the numbers can be compared.
| Rating | Severity (S): effect on the customer | Occurrence (O): how often the cause happens | Detection (D): will current controls catch it? |
|---|---|---|---|
| 10 | Safety, legal or regulatory breach, with no warning | Almost every time: 20% of cases or more | No control; nobody would notice |
| 9 | Customer loses money or data; a regulatory complaint is likely | 10-20% | Noticed only by chance |
| 8 | Customer cannot complete the task; dispute or chargeback likely | 5-10% | Found only when the customer complains |
| 7 | Major delay or rework; customer has to chase several times | 2-5% | Found by an occasional manual check (monthly or less) |
| 6 | Noticeable delay; customer contacts support | 1-2% | Found by a regular manual check (weekly) |
| 5 | Customer is annoyed and has to make an extra effort | 0.5-1% | Found by a daily manual check or report |
| 4 | Minor inconvenience that most customers notice | 0.1-0.5% | Automatic report that someone has to read |
| 3 | Minor inconvenience that few customers notice | 0.01-0.1% | Automatic alert to an owner, the same day |
| 2 | Barely noticeable | Less than 0.01% | An automatic check stops it before it reaches the customer, almost always |
| 1 | No effect on the customer | Prevented by design: cannot happen | Error-proofed: it cannot reach the customer |
RPN or action priority?
RPN weighs severity, occurrence and detection equally, so very different risks can get the same number, and a severe but rare failure can rank low. In the example, 9 × 2 × 5 = 90 sits below 4 × 5 × 8 = 160, yet only the first can cost a customer money. That is why the 2019 AIAG & VDA FMEA handbook replaced RPN ranking with action priority (high, medium, low), which looks at severity first, then occurrence, then detection. Whichever you use, read severity first: act on every severity 9 or 10, then work down the list.
Related free templates
Frequently asked questions
What is FMEA?
Failure mode and effects analysis: a structured way to find how a process can fail, what each failure does, why it happens and how well you would catch it, so you can fix the biggest risks first.
How do you calculate RPN?
Multiply the three scores: RPN = severity × occurrence × detection. Each runs from 1 to 10, so RPN runs from 1 to 1,000. In the example, the inspection step scores 8 × 4 × 8 = 256.
What RPN is too high?
There is no universal cut-off. Many teams act on the top of the list and on any severity 9 or 10. This template highlights 200 and above in red and 100 to 199 in amber; change the thresholds to suit your process.
What is the difference between FMEA and root cause analysis?
FMEA looks ahead at failures that could happen; root cause analysis explains a problem that already happened. They work together: after an incident, add the failure mode to your FMEA so the new control is tracked.
Is the FMEA template free? Is there an Excel or Word version?
Yes. The printable PDF downloads without an email. The Excel workbook (example, blank worksheet with RPN formulas, rating scales) and the Word version are sent to your email for free. For Google Sheets, upload the .xlsx file to Google Drive and open it with Google Sheets.
Can FMEA be used for customer experience?
Yes, for any process with steps that can fail: returns, onboarding, billing, support. That is why the severity scale in this template is written from the customer's side.
Where do the failure modes come from?
From the team, from past incidents and from what customers already tell you: complaints, tickets and reviews show which failures they actually run into. Pivony runs root cause analysis on all of your customer feedback, not a sample.
Have thousands of complaints, reviews or tickets?
Pivony runs root cause analysis on all of your customer feedback, not a workshop sample.
Get a free root cause audit