8d Report Writing

8D Customer Report Writing

When to use

Use when an 8D investigation is complete and a formal report must be submitted to the customer. This skill covers the writing quality and format — the methodology is in 8d-problem-solving.

The 8D report is a legal and commercial document. It is used by the customer to:

• Verify their claim was addressed
• Confirm containment protected their production
• Audit your corrective action quality
• Assess your supplier quality level for BIQS scoring, PPAP status, and future business decisions

A poorly written report — even with good corrective actions — signals low quality maturity.

OEM format references

Always download the current customer template from the portal before writing. Templates change. Always align with the specific customer format and mandatory fields — do not modify OEM templates.

---

Required 8D Report Checklist

☐ Correct OEM template used (latest version — downloaded before writing) ☐ D2 fully quantified and matches the customer claim and NCR exactly ☐ D3 containment implemented with evidence — past tense only ☐ D3 containment active until D6 verification is complete ☐ D4 includes both occurrence and escape root causes, each validated with objective evidence ☐ D5 actions directly address each root cause (RCO and RCE referenced) ☐ D6 includes objective verification data with justified sample size ☐ D7 includes PFMEA, CP, WI updates with revision numbers, plus horizontal deployment ☐ D8 includes champion sign-off and customer notification of closure ☐ All dates are chronological and consistent across D0–D8 ☐ All statements are supported by attached or referenced evidence ☐ No speculative, apologetic, or subjective language used ☐ Consistent tense: past for completed actions, present for current state

---

Writing rules — discipline by discipline

D0 — Emergency Response

Write a brief statement of whether a safety/regulatory issue was identified and what emergency action was taken.

Always state explicitly whether safety/regulatory risk is present or not — "No safety risk identified" or "Safety risk identified — [action]."

Good: "No safety risk identified. Customer notified by email (attached) on 2026-05-14. Ship-hold placed on supplier lot 2026-05-12-A, covering 1,700 units across 2 delivery notes."

Bad: "We were notified of the issue and responded quickly."

Evidence required: customer notification email, ship-hold record.

---

D1 — Team

List names and functions. The customer wants to see cross-functional involvement.

Good: Include at least quality engineer, production supervisor, and process/design engineer. Identify the team leader and customer contact point (if applicable) clearly.

Bad: "The quality team investigated." (no names, no functions, no evidence of cross-functional approach)

---

D2 — Problem Description

This is the most read section — if D2 is vague, the customer will reject the report.

D2 must match exactly the NCR and the customer claim description. Any inconsistency between D2, the NCR, and customer claim data is treated as a credibility failure.

Required content:

• Exact non-conformance with measured values and specification
• Part number + revision
• Customer's claim reference number
• Quantity: rejected / inspected / population at risk
• Detection point (customer incoming, field, production)
• First detection date

Good: "Connector housing flange thickness measured at 1.8 mm (specification: 2.2 ± 0.1 mm, DWG-12345 rev B). Defect detected at customer incoming inspection 2026-05-13. 47 non-conforming units of 200 inspected (23.5%). Customer claim ref: CL-2026-4471."

---

D3 — Interim Containment Actions

The customer needs to know their production is protected. This is the first thing many SQEs read.

Containment must remain active until D6 verification is complete and effectiveness is confirmed.

Required content:

• What was done (sort, 100% inspection, ship-hold)
• When it was implemented (date — must be before D4, D5, D6)
• Who did it
• How effectiveness was verified (zero escapes since ICA, sort results)

Good: "100% inspection of all suspect stock at customer (200 units, all checked by 2026-05-14, 47 units rejected, 153 units accepted and released after re-inspection). Ship-hold on remaining 1,500 units in our warehouse, confirmed by logistics on 2026-05-14. Zero additional escapes since ICA implementation."

Bad: "We will perform 100% inspection going forward." (future tense is not containment — it's a promise)

---

D4 — Root Cause Analysis

The most technically evaluated section. Customer SQEs specifically look for:

1. Is there a root cause of occurrence AND a root cause of escape?
2. Is the root cause specific enough (not generic "human error" or "supplier issue")?
3. Is it validated with objective evidence — not just logical reasoning?

Root cause must be supported by evidence (test, data, or experiment), not logical reasoning alone.

Required content:

• Root cause of occurrence (why did the defect happen?) — with the 5-Why chain
• Root cause of escape (why was it not detected?) — with the 5-Why chain
• Validation method (how was the root cause confirmed — test, data, reproduction experiment?)

Good — root cause of occurrence:

D4 Why chain (occurrence):

1. Why flange thickness OOS? → Insufficient material removed at milling step
2. Why insufficient material removed? → Feed rate was 0.05 mm/rev instead of 0.03 mm/rev
3. Why wrong feed rate? → CNC programme parameter changed during tool changeover on 2026-05-10
4. Why was change not detected? → No parameter verification step after tool changeover Root cause: CNC programme parameter verification is not required by the work instruction after tool changeover. Validated by: Reproduction test confirmed defect at 0.05 mm/rev; zero defects at 0.03 mm/rev.

Bad: "Root cause: operator error. The operator changed the wrong setting."

---