If you write 8Ds for automotive or industrial customers, you know the email: "Thank you for your report. Please revise and resubmit." Each revision loop costs days and keeps the complaint open.
Most rejected 8Ds don't fail because the engineering is hard. They fail because the report doesn't show the work. A customer quality engineer reading your 8D has only the document in front of them. If the evidence isn't in the text, as far as they can tell it doesn't exist.
Below are the eight gaps that most often send an 8D back, roughly in D1–D8 order. Use them as a checklist before you send. If you'd like a second, skeptical reader on your draft, there's a free tool for that, 8D Gate. More on it at the end.
1. The problem statement is vague (D2)
"Customer complaint, quality issue on part X" is not a problem statement. Your reviewer wants the basics: what, where, when, how many, and how it was detected. Give the part and lot, the shipment or date window, the quantity affected, the detection point, and the requirement that wasn't met, with the spec value.
A common mistake is putting the suspected cause into D2. D2 should describe the deviation, not explain it.
Check: Could someone who has never seen the part restate the problem, with numbers, from D2 alone?
2. Containment has no numbers or no boundary (D3)
"Stock blocked and sorted" doesn't tell the customer much. They want to know which stock, at which locations (your finished goods, WIP, in transit, at the customer, at other sites), how many pieces were checked, by what method, and how many were found nonconforming. They also want a break point: the last known good shipment and the first shipment verified good after containment.
An unfinished sort is fine if you say so. A containment section that sounds finished but has no quantities is not.
Check: Does D3 give counts for checked and rejected parts at every location, the inspection method, and a clear break point?
3. The root cause stops at the symptom or at a person (D4)
"Operator error," "operator carelessness," and "lack of attention" are the most common reasons an 8D gets rejected. Customers read them as "we haven't found the cause yet." People make mistakes when the process allows those mistakes and doesn't detect them. The real root cause usually sits in that gap: setup without a verified standard, a missing poka-yoke, tool wear with no monitoring, or an unclear work instruction.
The other version of this failure is a root cause with no evidence behind it. "Team discussion concluded…" or "see attached fishbone" is not proof. Show the analysis method (5-Why, Ishikawa, is/is-not), the data that confirms the cause, and ideally that you can switch the defect on and off.
Check: Does D4 explain why the process allowed the defect, and is there data in the report itself that confirms it?
More detail: How to write the D4 root cause in an 8D.
4. There is no escape point analysis (D4)
When the customer found the defect, there are two questions: why it was made, and why it wasn't caught. Many 8Ds answer only the first. Others answer the second with "final inspection didn't notice," which is the person-blame problem again in a different discipline.
Name the control point that should have detected the defect. Then explain why it couldn't: the characteristic wasn't on the control plan, the gauge couldn't discriminate, the sampling frequency was too low, or the inspection depended on someone's visual check.
Check: Does the 8D have separate occurrence and non-detection (escape) root causes, each with its own evidence?
More detail: Escape point in 8D: what it is and how to write it.
5. Corrective actions treat the symptom (D5)
"Retrain operators," "remind inspectors," "100% inspection," and "quality alert on the line board" are reasonable interim actions. They are not permanent corrective actions. They don't change the conditions that produced the defect.
A permanent corrective action should map directly to a root cause you've proven. If D4 names two root causes (occurrence and escape), D5 needs actions for both, each with an owner and a date.
Check: For every root cause in D4, is there an action in D5 that changes the process, tooling, method, or detection, beyond people's attention?
6. "Effective" is claimed with no verification data (D6)
"No further complaints since the training, so the actions are effective" is one of the weakest sentences you can put in an 8D. A quiet few weeks may only reflect low volume.
Verification means evidence: before-and-after measurements, capability data after the change, a trial run with results, or a validated error-proofing check. If the data isn't available yet, say so and give the date when it will be.
Check: Does D6 include actual results (numbers, charts, or test outcomes) in the report, not just a statement that the actions worked?
7. Nothing systemic changes (D7)
Customers look at D7 to see whether the organization learned anything or only fixed one part. "Add 'be careful' to the work instruction" and "share in the monthly meeting" don't count. Reviewers expect to see the system documents updated: PFMEA (occurrence and detection reconsidered), control plan, work instructions, and lessons learned. They also expect a read-across to similar parts, processes, or lines, with a list rather than "will be reviewed."
Check: Does D7 name the specific documents updated (with revision status) and the similar products or processes the fix was extended to?
8. The report contradicts itself or closes too early (D8 and overall)
Reviewers notice inconsistencies: a quantity in D2 that differs from D3, a corrective action marked "done" before its root cause was confirmed, a D8 that proposes closure while the same section lists the sort, the work instruction, and the read-across as still open. There's also the attachment problem. Anything you write as "see attachment" or "available on request" is evidence the reader can't see if it isn't in the document.
Check: Read the 8D from start to finish as a skeptic. Do the numbers, dates, and statuses agree, and is the key evidence actually in the document?
How to pre-check before you send
The best pre-check is a colleague who reads like a demanding customer. That person isn't always free when the deadline is tomorrow, so we built 8D Gate as a free pre-send readiness check for exactly this moment.
You paste your English 8D (D1–D8) or upload it as PDF, DOCX, or Excel. You get back an advisory decision:
- Accept: looks complete enough to send
- Conditional: usable once the named gaps are closed
- Reject: not ready; fix these before you send
With the decision you also get a score, ratings for each section, the missing evidence, and questions to close the gaps. The review follows a public rubric covering problem definition, containment, root cause, evidence quality, corrective action, verification, prevention, and consistency. It has hard gates for issues like an unsupported root cause or symptom-only corrective actions. Polished wording doesn't raise the score. When the 8D doesn't contain the evidence, the review says so instead of filling the gap. You can review the result on screen and download it as a PDF. A review usually takes under a minute.
Be clear about what it is. It's an advisory pre-send readiness check for your team. It doesn't replace your customer's decision, and an Accept from 8D Gate is not a customer Accept. Follow your own company's and your customer's rules on sharing documents. If a report contains sensitive customer details, consider redacting them before you paste it.
Run the free 8D readiness check
8D Gate is a free pre-send readiness advisory. It doesn't replace the customer's decision. We don't store your 8D body in our database; you can delete anytime. Anthropic processes the text for the review.
The tool is in an early version (V0.1, English only). If you try it, I'd like to hear what was useful, what was too lenient, and what it missed.
Top comments (0)