8D Problem Solving: The Eight Disciplines, with an Example

Most problems do not need eight steps. A typo on an invoice gets fixed and forgotten. But some problems keep coming back, hurt many customers at once, or come with a customer who wants proof that you have fixed them for good. For those, a quick fix is not enough, and a single brainstorming session is not either. 8D gives the work a structure: who owns it, what you do in the first 24 hours, how you prove the cause, and when you are allowed to call it closed.

This guide explains what 8D is, when to use it, each discipline from D0 to D8, two ideas that confuse most first-time teams (is/is-not and the escape point), a worked example built on a spike in customer complaints, and what goes in an 8D report.

What is 8D problem solving?

8D is a structured, team-based approach to problem solving. The name comes from its eight disciplines, D1 to D8. Most teams today also use a D0 step for planning and the emergency response, so in practice there are nine.

The method was first written down in a Ford Motor Company team problem-solving manual in 1987. Ford and its suppliers spread it across the automotive industry, and it is now used in manufacturing, aerospace, electronics, logistics and, increasingly, in service businesses that handle customer complaints. Many companies ask their suppliers for an 8D report when something goes wrong.

What makes 8D different from a simple fix is that it separates three kinds of action:

• Containment: what you do now to protect customers while you investigate.
• Permanent corrective action: what removes the root cause.
• Prevention: what stops the same kind of problem appearing on another product, line, region or team.

It also asks two questions, not one. Why did the problem happen? And why did nobody catch it before the customer did?

When to use 8D (and when not to)

8D is not a replacement for 5 Whys or fishbone. It is the frame they sit inside. In D4 you still need a tool to find the cause, and 5 Whys and fishbone are the usual choices. What 8D adds around them is the team, the containment, the verification and the closure.

Signs you need a full 8D rather than a quick fix:

• The problem has happened before, or is getting worse.
• Several customers, orders or sites are affected.
• There is a cost, safety, legal or reputational impact.
• The cause is not obvious, or more than one team is involved.
• A customer, regulator or manager has asked for a documented root cause and corrective action.

The 8 disciplines, step by step

D0: Plan and emergency response

Goal: protect customers right away and decide whether the problem deserves a full 8D.

Typical output: an emergency response action (for example, holding shipments, calling affected customers, switching to a manual check), a short record of what you know so far, and a decision to start an 8D or not.

Common mistake: treating the emergency response as the fix. Calling back angry customers is necessary, but it does nothing to stop tomorrow's customers having the same problem.

D1: Form the team

Goal: put together a small, cross-functional team with the knowledge and authority to solve the problem.

Typical output: a team leader who runs the 8D, a champion (a manager who can unblock resources and approve changes), and four to six members from the areas involved: the people who run the process, someone who knows the data and systems, and someone close to the customer.

Common mistake: a team made only of managers, or only of the quality department. The people who do the work every day usually know where the process bends. Leaving them out slows D4 down.

D2: Describe the problem

Goal: describe the problem so precisely that everyone agrees what is being solved, before anyone guesses a cause.

Typical output: a problem statement that covers what, where, when and how much, measured against a baseline, plus an is/is-not table (explained below).

Common mistake: writing a cause or a solution into the problem statement. "Complaints rose because the new contractor is unreliable" is a guess. "Complaints about missed appointments rose from about 40 to about 180 a week in two regions since 3 April" is a problem statement.

D3: Contain the problem

Goal: stop the problem reaching more customers while the team looks for the root cause.

Typical output: interim containment actions, an owner for each, and a check that they actually work. Containment is often expensive or manual (extra inspection, a temporary rule, a manual callback), which is fine as long as it is temporary.

Common mistake: leaving containment in place forever. Containment that becomes "the way we work" hides the problem, costs money every day and removes the pressure to find the real cause.

D4: Find the root cause and the escape point

Goal: find and verify two causes: why the problem happened (the root cause of occurrence) and why your own checks did not catch it (the escape point).

Typical output: a short list of candidate causes (often from a fishbone diagram), a chain of causes for the most likely ones (often 5 Whys), and evidence that confirms or rules out each one. A good test: the root cause should explain the whole is/is-not table, including where and when the problem did not happen.

Common mistake: stopping at "human error" or "training". People make mistakes in every process. The useful question is what in the process made the mistake possible, and why nothing caught it.

For the tools themselves, see our guides to 5 Whys and fishbone analysis, or the root cause analysis template, which takes you from evidence to a verified cause.

D5: Choose permanent corrective actions

Goal: choose actions that remove the root cause and close the escape point, and prove they work before you roll them out.

Typical output: one or more corrective actions for occurrence and for escape, each with an owner and a due date, plus evidence from a trial, a pilot or a test that they solve the problem without creating a new one.

Common mistake: choosing actions that are easy rather than effective. "Remind staff to be careful" and "add a line to the procedure" rarely remove a cause. Look for actions that change the process, the system or the design so the mistake cannot happen or is caught at once.

D6: Implement and validate

Goal: put the permanent actions in place, show with data that the problem is gone, and only then remove the containment.

Typical output: an implementation plan, the date each action went live, results against the target you set in D5, and the date containment was removed.

Common mistake: declaring victory too early. One quiet week is not proof. Decide in advance which metric you will watch, what result counts as success and for how long.

D7: Prevent recurrence

Goal: make sure the same kind of problem cannot happen on similar products, processes, sites, regions or customers.

Typical output: updated procedures, work instructions and checklists; the fix rolled out to similar places; and the failure mode added to your risk analysis. Many teams record it in a failure mode and effects analysis, and our FMEA template is a good place to start.

Common mistake: fixing only the place where the problem showed up. If the same weakness exists in three other regions, you have only fixed a quarter of the problem.

D8: Recognise the team and close

Goal: close the 8D formally, capture what you learned and thank the people who did the work.

Typical output: a signed-off 8D report, a short lessons-learned note shared with other teams, and recognition for the team, in whatever form fits your culture.

Common mistake: skipping it. D8 feels optional, but closing formally is what tells everyone the containment can stop, and recognition is what makes people willing to join the next 8D team.

Is/is-not analysis, explained simply

Is/is-not is a table you fill in during D2. For each question (what, where, when, how many), you write where the problem is and, just as important, where it could be but is not. Then you ask what is different between the two.

The "is not" column is the clever part. If complaints come from two regions but not from the other three, the cause is probably something those two regions have and the others do not. If the problem started on a specific date, look at what changed just before it. The differences narrow the search before anyone argues about causes.

A simple version looks like this:

The escape point, explained simply

The escape point is the earliest place in your process where the problem could and should have been detected, but was not. Every process has checks: an inspection, a confirmation step, a dashboard, a review. When a problem reaches the customer, at least one of those checks failed or did not exist.

8D asks you to fix both:

• Occurrence: why did the problem happen at all?
• Escape: why did it get past us and reach the customer?

Fixing only the occurrence leaves you exposed to the next, different problem that slips through the same gap. Fixing only the escape means you catch the problem every time, but you keep paying to catch it.

Worked example: a spike in missed-appointment complaints

Illustrative example, not customer data. The company, numbers and dates are made up to show how the steps fit together.

A home internet provider schedules technician visits for new installations. Customers book a two-hour slot online or through the contact centre and get a confirmation text.

D0: Plan and emergency response

The contact centre lead notices more customers complaining that "the technician never came". Same day: every customer with an open missed-appointment complaint gets a call, a priority slot within 48 hours and a service credit. The volume, the repeat pattern and the fact that nobody knows the cause justify a full 8D.

D1: Team

Champion: head of field operations. Leader: service quality manager. Members: the dispatch lead for the affected regions, a scheduling system analyst, a contact centre team lead and a customer insights analyst.

D2: Problem description

Since 3 April, customers in the North and East regions have reported that a confirmed installation appointment was missed with no notice. Missed-appointment complaints rose from an average of 38 a week to 176 a week over the four weeks after 3 April (704 in total).

D3: Containment

Same-day afternoon booking is switched off in North and East. Each morning, a dispatcher checks that every booked installation appears in the subcontractor's job list and calls the subcontractor about any that are missing. Customers with afternoon slots get a call the day before. Within a week, missed-appointment complaints in the two regions drop back towards the old level.

D4: Root cause and escape point

Occurrence. The subcontractor receives its job list through a file export that runs once a day at 06:00. The same-day booking feature launched on 3 April let customers book afternoon slots after the export had already run, so those jobs never reached a technician. The release process had no step to check partner integrations.

Verified: 655 of the 704 complaints (93%) were same-day afternoon bookings in North and East made after 06:00. A test booking made at 09:00 never appeared in the subcontractor's list.

Escape point. Two checks failed. The confirmation text was sent when the booking was saved, not when a technician accepted the job, so customers were told "confirmed" for jobs nobody had. And there was no alert for jobs still unassigned shortly before their slot.

Detection. In the contact centre, missed appointments were tagged with the same category as late arrivals, so for the first three weeks the rise looked like a small increase in "technician late". It became visible only when an analyst read the comments themselves.

D5: Permanent corrective actions

• Occurrence: replace the daily file export with a live sync of new and changed jobs to the subcontractor's system. Trial: 300 test bookings across the day, all received within minutes.
• Escape: send the confirmation text only after a technician has been assigned, and alert dispatch when a job is still unassigned two hours before its slot. Test: 20 deliberately unassigned jobs, all flagged.

D6: Implement and validate

The live sync and the new confirmation rule go live on 15 May, with the dispatch alert one week later. Success is defined in advance: missed-appointment complaints in North and East at or below the old baseline for four weeks in a row. Four weeks after go-live they average 31 a week, and the dispatch alert has caught a handful of unassigned jobs before customers noticed. Containment is removed and same-day afternoon booking is switched back on.

D7: Prevent recurrence

• "Partner integrations checked" is added to the release checklist for every booking and scheduling change.
• The live sync is extended to the two other subcontractors the company uses for repairs.
• The complaint category "technician late" is split into "late" and "did not arrive", so the two trends are tracked separately.
• The failure mode "booking does not reach the technician" is added to the service FMEA, with the new controls.

D8: Recognise the team and close

The champion signs off the report. The team presents the case at the monthly operations review, and the contact centre lead whose comment started it all is thanked by name.

Notice what the example shows. Containment was quick and imperfect. The root cause was a change (a new feature) meeting an old weakness (a once-a-day export). The escape was as important as the cause. And the first signal was in customers' own words, not in a dashboard.

What goes in an 8D report?

An 8D report is the written record of the steps above. Whatever format your company or customer uses, a complete report usually includes:

1. Header: report number, customer or source, product or service, dates opened and closed, team leader and champion.
2. D0: what triggered the 8D and the emergency response actions.
3. D1: team members and roles.
4. D2: problem statement with numbers and a baseline, and the is/is-not table.
5. D3: containment actions, owners, dates and how you checked they worked.
6. D4: root cause of occurrence and escape point, with the evidence that verifies each.
7. D5: chosen permanent corrective actions, with the proof that they work.
8. D6: implementation dates, results against the target, date containment was removed.
9. D7: changes to procedures, similar places fixed, risk analysis or FMEA updated.
10. D8: sign-off, lessons learned and recognition.

Keep it factual and short. A reader should be able to follow the logic from problem to cause to fix in a few minutes, and every claim in D4 to D6 should point to evidence.

Next step: start from a filled-in example with our free 8D report template (Excel, Word and PDF, D0 to D8 with an is/is-not sheet and an action tracker). If you need to track actions from any investigation to closure, the corrective action plan template adds a 30/60/90-day effectiveness check.

Common 8D mistakes

• Starting at D4. Jumping to causes before the problem is described and contained leads to guesses and arguments.
• A vague problem statement. Without numbers and a baseline you cannot tell later whether the fix worked.
• Containment that never ends. Temporary checks become permanent costs.
• "Human error" as the root cause. Ask what in the process allowed the error and why it was not caught.
• Ignoring the escape point. The next problem will use the same gap.
• No validation. Closing on the day the fix goes live, before the data shows it worked.
• Fixing one place only. D7 exists because similar processes usually share the same weakness.
• Working from a sample. If the evidence is twenty hand-picked complaints, the root cause may be the loudest one, not the biggest.

Where customer feedback fits in an 8D

Many 8Ds start with a customer complaint, and in service businesses the evidence for D2 and D4 is often in the customers' own words: support tickets, survey comments, reviews and chat transcripts. The difficulty is volume. In the example above, the signal was hidden for three weeks because missed visits were filed under the wrong category, and only reading the comments revealed it.

This is the part Pivony helps with. Pivony brings tickets, NPS surveys, call centre transcripts, app reviews and other feedback into one place, groups what customers say by meaning, and overlays your segment and operational data, so you see not just "installation complaints are up" but which region, which channel and since when. That gives D2 a precise problem statement and gives D4 evidence from all of your feedback, not a workshop sample. The 8D itself, with its team, containment and validation, is still yours to run.

Related reading

• Root cause analysis in customer feedback: the complete guide
• 5 Whys root cause analysis: how it works, with CX examples
• Fishbone analysis: complete guide for CX teams
• Free 5 Whys template
• Free fishbone diagram template
• Free root cause analysis template
• Free FMEA template

Next step

Download the free 8D report template and write your first report from the filled-in example. If your complaints arrive by the hundreds or thousands, request a free root cause audit on a sample of your tickets, reviews or survey comments, or book a demo.