Eightd
Structured 8D problem solving for customer complaints and quality issues. D0-D8 phases with containment, root cause analysis, and escape point identification. USE WHEN user says '8D', 'eight disciplines', 'customer complaint', 'corrective action', 'root cause analysis', 'containment', 'escape point', or 'problem solving report'.
What this skill does
# 8D Problem Solving Skill ## CRITICAL REQUIREMENT: Complete All Phases When generating an 8D report, you MUST include ALL nine phases (D0 through D8) in every response. Never truncate or omit phases. If the response would be long, still complete all phases — use concise language but include every discipline. A partial 8D report is invalid. **Mandatory phases checklist for every 8D report output:** - D0: Emergency Response Actions - D1: Team Formation - D2: Problem Description (with IS/IS NOT) - D3: Interim Containment Actions + Escape Point - D4: Root Cause Analysis (occurrence AND detection) - D5: Permanent Corrective Actions - D6: Implementation and Verification - D7: Systemic Prevention - D8: Team Recognition and Closure **CONDENSED FORMAT RULE:** When generating an 8D report, write each phase in 3-6 bullet points maximum. Do NOT use elaborate multi-column tables — use simple prose or brief bullets. This keeps total length manageable so ALL phases D0–D8 are always included in a single response. Never stop writing before D8 is complete. If you are generating a long response and feel you are running out of space, shorten earlier phases to make room — but D8 MUST always be the final section written, fully completed. An 8D report that ends before D8 is a critical failure. **NO PLACEHOLDERS RULE:** Every field must be populated with real, specific content derived from the user's input. Never output brackets like [PART NUMBER] or [TBD] — if information is missing, make a reasonable inference and note the assumption clearly (e.g., "Assumed: thread spec M12×1.75 based on typical application"). A template with empty fields is not an 8D report. The IS/IS NOT analysis in D2 must contain actual specific values for What, Where, When, and Extent — never leave cells empty, never use ⚠️ markers or "unknown" labels, never ask the user to fill in the data later. If a dimension or quantity is not stated, derive a plausible specific value from context and label it as assumed. A D2 section that withholds values pending more information is a failing response. **NEVER REQUEST INFORMATION BEFORE GENERATING RULE:** When a user describes a problem or asks for an 8D report, you MUST immediately generate the full D0–D8 report using whatever information is provided. Do NOT ask clarifying questions first. Do NOT present a list of questions requesting the user to supply data before you begin. Use assumed/inferred values for any missing details and label them as assumptions. A response that asks "please provide the following information" instead of generating the 8D report is a critical failure. If the user provides even a brief problem description, that is sufficient to generate a complete 8D report. **D6–D8 TRUNCATION PREVENTION:** These three phases are the most commonly truncated. As you write D5, actively monitor response length. If D5 is growing long, cut it short — D6, D7, and D8 are non-negotiable. After completing D5, you must write D6, then D7, then D8 in sequence. Do not stop. Do not summarise with "phases D6–D8 follow the standard template." Write each phase fully. The response is invalid if it ends before D8 closure text is written. ## Overview The 8D (Eight Disciplines) methodology is a team-based problem-solving process for identifying, correcting, and eliminating recurring problems. Originally developed by Ford Motor Company, it is now the automotive industry standard for customer complaint resolution and internal quality problem solving. ## Skill Integration | Skill | Integration Point | |-------|-------------------| | **A3CriticalThinking** | Root cause analysis methods | | **PFMEA** | Update FMEAs with new failure modes discovered | | **ControlPlan** | Update Control Plans with new controls | | **AutomotiveManufacturing** | Work instructions and process changes | | **InternalAudit** | Verify effectiveness through audit | ## 8D Phase Overview | Phase | Name | Purpose | Timeframe | |-------|------|---------|-----------| | D0 | Prepare | Emergency response, symptom assessment | Immediate | | D1 | Team | Form cross-functional team | 24 hours | | D2 | Problem | Define problem clearly | 48 hours | | D3 | Containment | Protect customer, stop bleeding | 24-72 hours | | D4 | Root Cause | Identify true root cause(s) | 2-4 weeks | | D5 | Corrective Actions | Develop permanent solutions | 2-4 weeks | | D6 | Implementation | Implement and verify | 1-4 weeks | | D7 | Prevention | Prevent recurrence systemically | Ongoing | | D8 | Closure | Recognise team, close report | After verification | --- ## D0: Prepare for the 8D Process ### Emergency Response Actions (ERA) Before formal 8D begins, immediate actions to protect: 1. **Customer Protection** - Identify all potentially affected product - Stop shipment of suspect product - Notify customer of situation - Provide replacement/rework timeline 2. **Symptom Assessment** - What is the symptom? - When was it first detected? - How much product is affected? - Is this a safety/regulatory issue? 3. **8D Trigger Criteria | Trigger | 8D Required? | |---------|--------------| | Customer complaint | Yes | | Field failure | Yes | | Safety/regulatory | Yes (expedited) | | Internal scrap >threshold | Recommended | | Repeat occurrence | Yes | | High severity PFMEA item | Recommended | ### D0 Outputs - Decision to proceed with 8D - Initial ERA documented - Urgency level assigned (24h / 72h / Standard) --- ## D1: Establish the Team ### Team Composition | Role | Responsibility | Required? | |------|---------------|-----------| | Champion/Sponsor | Remove barriers, approve resources | Yes | | Team Leader | Coordinate activities, report status | Yes | | Process Expert | Deep process knowledge | Yes | | Quality Engineer | Data analysis, methodology | Yes | | Production Rep | Shop floor perspective | Yes | | Customer Rep | Customer perspective | If applicable | | Supplier Rep | Supplier perspective | If applicable | | Subject Matter Experts | Specific technical knowledge | As needed | ### Team Size - **Ideal:** 4-7 members - **Minimum:** 3 members - **Maximum:** 10 members (larger teams slow progress) ### D1 Outputs - Team roster with roles and contact information - Meeting schedule established - Resources allocated - Communication plan --- ## D2: Describe the Problem ### Problem Description Techniques **5W2H Analysis:** | Question | Answer | |----------|--------| | **What** is the problem? | Specific defect/symptom | | **Where** was it found? | Location (customer, inspection, operation) | | **When** was it found? | Date, time, shift, production lot | | **Who** found it? | Person, inspection method | | **Why** is it a problem? | Impact to customer/function | | **How many** are affected? | Quantity, frequency, trend | | **How** was it detected? | Detection method used | **IS / IS NOT Analysis:** | Factor | IS | IS NOT | Distinction | |--------|----|---------| ------------| | What | [Observed defect] | [Similar but not this] | | | Where | [Location found] | [Where not found] | | | When | [Time first seen] | [Time not seen] | | | Extent | [Scope affected] | [Not affected] | | ### Problem Statement Format **Good problem statement:** > "Outer diameter of part #12345 measures 25.08-25.12mm (spec: 25.00 ±0.05mm) on 147 parts from production lot 2026-01-15, discovered at customer receiving inspection." **Bad problem statement:** > "Parts are out of spec" (too vague) ### D2 Outputs - Clear, quantified problem statement - IS/IS NOT analysis completed - All affected product identified and quantified - Timeline of events established --- ## D3: Interim Containment Actions (ICA) ### Containment Scope | Location | Action Required | |----------|-----------------| | In-process (WIP) | Quarantine, sort, disposition | | Finished goods | Quarantine, sort, disposition | | In-transit | Recall or intercept | | At customer | Sort, replace, rework on-site | | In field | Service campaign if needed |
Related in Sales & CRM
process-mapper
IncludedUse when a BizOps lead, COO, or process-improvement owner needs to document an end-to-end business process (procurement, employee onboarding, incident handoff, customer-onboarding, claims adjudication) in BPMN-style notation, measure cycle times by stage, surface where work spends most of its time waiting vs. being worked, and quantify the gap between processing time and total elapsed time. Pairs Lean / Six Sigma / Theory-of-Constraints canon with deterministic stdlib-only Python tools to produce a process map, a ranked bottleneck list (with severity + root-cause hypothesis), and a cycle-time analysis (P50, P90, value-add ratio, Little's-Law throughput). Distinct from sales-pipeline, system-reliability (SLO), and strategic-OKR work — this is tactical process documentation for internal operations.
payment-integration
IncludedIntegrate payments with SePay (VietQR), Polar, Stripe, Paddle (MoR subscriptions), Creem.io (licensing). Checkout, webhooks, subscriptions, QR codes, multi-provider orders.
customer-success-manager
IncludedMonitors customer health, predicts churn risk, and identifies expansion opportunities using weighted scoring models for SaaS customer success
sales-engineer
IncludedAnalyzes RFP/RFI responses for coverage gaps, builds competitive feature comparison matrices, and plans proof-of-concept (POC) engagements for pre-sales engineering. Use when responding to RFPs, bids, or proposal requests; comparing product features against competitors; planning or scoring a customer POC or sales demo; preparing a technical proposal; or performing win/loss competitor analysis. Handles tasks described as 'RFP response', 'bid response', 'proposal response', 'competitor comparison', 'feature matrix', 'POC planning', 'sales demo prep', or 'pre-sales engineering'.
customer-success-manager
IncludedMonitors customer health, predicts churn risk, and identifies expansion opportunities using weighted scoring models for SaaS customer success
sales-engineer
IncludedAnalyzes RFP/RFI responses for coverage gaps, builds competitive feature comparison matrices, and plans proof-of-concept (POC) engagements for pre-sales engineering. Use when responding to RFPs, bids, or proposal requests; comparing product features against competitors; planning or scoring a customer POC or sales demo; preparing a technical proposal; or performing win/loss competitor analysis. Handles tasks described as 'RFP response', 'bid response', 'proposal response', 'competitor comparison', 'feature matrix', 'POC planning', 'sales demo prep', or 'pre-sales engineering'.