What is an 8D report?
An 8D report documents how a quality complaint was solved in eight disciplines: from the team (D1) through problem description, containment, root cause analysis, corrective actions, effectiveness validation and prevention to closure (D8). Customers – especially in automotive – don't judge it by length, but by whether it proves the defect will not come back.
Three ground rules
- 1.Evidence beats statements: anything not in the report or not proven counts as not done.
- 2.Every root cause needs an action – and every action must target a root cause.
- 3.Engineering beats appeals: the less an action depends on human attention, the stronger it is.
Build the right team
An 8D handled only by the quality department is almost always spotted by the customer. The team must understand the defect technically and be allowed to implement changes.
Name the process and inspection owners
Bring in the person who owns the process where the defect was created – and the person responsible for the inspection that missed it.
Make sure the team has authority
At least one member must be able to approve process or design changes. Otherwise corrective actions stay declarations of intent.
State names, functions and roles
Team leader, members, departments and contact details belong in the report. Include maintenance for equipment issues and logistics – and where relevant purchasing and supplier quality – for delivery issues.
Typical weaknesses
- Only one person nominated
- Quality department only
- No one from production or engineering
- Unclear roles and responsibilities
Describe the problem in measurable terms
A good problem description is precise enough that an outsider would recognise the defect – and it contains no causes or solutions yet.
Answer the W-questions completely
What (part, characteristic, defect mode), where (process step and detection point), when (production and detection date, shift, lot), how many (quantity, share, ppm) and how often (frequency, previous cases).
Describe the detection, not the origin
D2 describes where, when and by whom the defect was detected. Where it was created usually cannot be stated reliably yet – that is what the root cause analysis in D4 clarifies.
Quantify the deviation
Reference the drawing, specification or standard and the measured actual value. “Quality issue found” is not a problem description.
Bound the suspect quantity
Lot or batch numbers and time ranges from traceability show which parts may be affected.
Attach evidence
Photos, sketches, measurement reports and an is/is-not analysis make the description verifiable.
Protect the customer immediately
D3 decides whether more defective parts reach the customer. Customers look closely at whether every stock location really was covered.
Check every stock location
Finished goods, work in process, raw material, external warehouses, goods in transit and customer stock. Goods in transit are forgotten most often.
Sort with an instruction and a limit sample
A 100% inspection only counts if it is clear who inspects to which instruction – and that the method reliably detects the defect.
Define and mark a clean point
From which date or lot is the material proven good, and how is it marked? Tell your customer.
Document the results
Owners, dates, quantity checked and defects found belong in the report.
Not real containment
- “Operators were made aware”
- Retraining without physical control
- Extra visual check without a limit sample
- No clean point, no stock review
Really find the root cause
Most 8D reports fail at root cause analysis – and customers read it most critically. A complete analysis answers three questions separately.
Occurrence root cause
Why was the defect physically created? Which process condition, mechanism or safeguard failed?
Detection root cause
Why did the existing controls not catch the defect before delivery?
Systemic root cause
Why did the management system allow these gaps – for example in change management, FMEA or lessons learned?
“Human error” is not a root cause
Phrases like operator error, carelessness, training issue or “procedure not followed” describe an event. Keep asking why the process allowed it.
Prove the cause
Check that the cause explains every fact from D2. Most convincing is a trial showing the defect appears with the cause and not without it.
Show your method
5-Why chains, an Ishikawa diagram or an is/is-not comparison show the customer how you reached the cause.
| Weak statement | Strong statement |
|---|---|
| Operator forgot the weld. | The control logic allowed cycle completion without confirming the weld. |
| Wrong machine setting. | Access rights allowed an unapproved parameter set to be loaded. |
| Inspector missed the defect. | The inspection method could not reliably detect the defect at the specified limit. |
| Nobody noticed. | The control plan did not include the affected characteristic at this point. |
Actions that actually work
Every confirmed root cause – occurrence, detection and systemic – needs at least one dedicated permanent action.
How robust is your action?
From weak (top) to strong (bottom)- Awareness / communication– depends almost entirely on attention
- Retraining– rarely enough on its own
- Additional inspection– detects defects, does not prevent them
- Audits, dual approval– administrative safeguard
- Error proofing (Poka-Yoke)– strong if validated and hard to bypass
- Automation– very strong when risks are controlled
- Design change– can eliminate the failure mechanism entirely
Link cause and action
Map every action visibly to a cause – for example in a table: cause, action, owner, due date, status.
Check whether it can be bypassed
Can the action be switched off or worked around? Does it introduce new failure modes?
Training only as a supplement
Training usefully supports technical actions but does not replace them.
Prove effectiveness with data
“Completed” is not evidence. Customers want to see that the action is implemented and the defect no longer occurs.
Document implementation
Photos, approved changes, updated work instructions or software versions prove the action reached the process.
Choose a meaningful period
The monitoring period must match the defect frequency. One good part or a short trial run is not enough.
Define criteria up front
Set sample size, period and acceptance criterion before you measure. Before-and-after data are most convincing.
End containment only afterwards
Sorting from D3 ends only once the permanent action is proven effective.
Prevent recurrence across the system
D7 carries the lessons beyond the single case to products, processes and sites.
Update the FMEA and control plan
Failure mode, causes, actions and the revised risk rating go into the process FMEA, the new checks into the control plan.
Transfer to similar products and sites
Review similar parts, lines, equipment and other plants. Record what was reviewed – even when no action was needed.
Capture lessons learned
Document and share what you learned and update audit checklists and change management.
Close only when everything is proven
An 8D is closed when all disciplines are complete and consistent and effectiveness is proven – not when the deadline expires.
Ask the closure questions
Can the same defect recur under the same conditions? Could it still escape the revised inspection?
Be transparent about open points
Name delayed actions, residual risks or deviations openly instead of quietly moving them outside the 8D.
Document the sign-off
Approval, clean point and first conforming delivery belong in the closure – along with thanks to the team.
Quick check before you send
Ten questions you should answer with “yes” before the report goes to your customer:
- 1Are process and inspection owners on the team, and can the team approve changes?
- 2Is the problem described in measurable terms and the suspect quantity bounded?
- 3Were all stock locations including transit and customer checked, and is a clean point stated?
- 4Are occurrence, detection and systemic root causes listed separately?
- 5Does every root cause go beyond “human error” or “training”?
- 6Does every root cause have its own action with an owner and a due date?
- 7Was at least one technical safeguard such as Poka-Yoke considered?
- 8Is effectiveness proven with data over a suitable period?
- 9Are the FMEA and control plan updated and similar products reviewed?
- 10Is closure based on evidence, and are open points named?
How good is your 8D report?
8D Scan Pro evaluates your finished report against exactly these criteria and shows in seconds where it would fail with your customer.
Your first 3 reviews are free. 8D Scan Pro evaluates reports – your team still writes them.
Frequently asked questions
What is an 8D report?
An 8D report is a structured report for solving a quality problem, usually after a customer complaint. It runs through eight disciplines (D1–D8) from the team via root cause analysis to closure and is standard in the automotive and supplier industry.
Which discipline matters most?
Root cause analysis (D4) and corrective actions (D5). If the root cause is wrong or incomplete, even good actions won't work – which is why customers review these parts most strictly.
Is retraining a good corrective action?
Usually not on its own, because it depends on sustained attention. Customers expect technical safeguards such as Poka-Yoke, automation or design changes. Training is a useful supplement.
How long must effectiveness be demonstrated?
There is no fixed period. It must match how often the defect occurs: rare defects need a longer monitoring period or targeted challenge tests. Many customers set their own requirements.
Does 8D Scan Pro write my 8D report?
No. 8D Scan Pro evaluates finished 8D and complaint reports and shows what is missing for approval. Your team writes the report.
These tips are general guidance and do not replace customer-specific requirements or internal procedures.