Customer complaint

Customer complaint handling is the regulated, documented QMS process that receives any communication alleging deficiencies in a marketed product, decides whether it is reportable to a regulator, investigates the underlying cause, responds to the complainant, links the complaint to its production record, and feeds the data into risk-management review, CAPA and trending. It is one of the most-inspected QMS subsystems — FDA QSIT lists it alongside CAPA, design controls and management review as a primary subsystem reviewed in every comprehensive inspection — because it is where the manufactured reality of the product meets the field reality, and most quality failures surface here first.

The regulatory definition of 'complaint' is broad. 21 CFR 820.3(b) defines it as 'any written, electronic, or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, usability, safety or performance of a device that has been released for distribution'. ISO 13485 §3.4 mirrors this. EU MDR Article 2(60) is broader still, covering any 'serious incident' regardless of complaint format. The key point: complaints are not just customer service tickets. A field engineer noting an issue is a complaint. A sales rep's email mentioning a customer was unhappy is a complaint. A distributor returning product with a quality concern is a complaint. Failing to capture any of those triggers the most-common 820.198 citation: 'failure to maintain complaint files'.

Complaint handling is the regulator's window into post-market reality. The audit pattern is consistent across FDA, Notified Body, MHRA and PMDA: open the complaint log first, pick three to ten complaints across the recent period (often selecting some with the highest severity and some with the longest closure time), and trace each one end-to-end. Was it captured promptly? Was reportability decided within the regulatory clock? Was the investigation thorough? Was the response to the complainant documented? Was the underlying batch / DHR / MMR linked? Did it feed risk-management review and CAPA where appropriate? Are there other open complaints with the same root cause? Was there a trend that should have triggered earlier action?

Failures in this chain are some of the most-cited Form 483 observations year over year. The recurring wordings: 'failure to maintain complaint files' (820.198(a)), 'complaints not evaluated to determine whether the complaint represents an event required to be reported' (820.198(d)), 'failure to investigate complaints in a timely manner' (820.198(c)), 'complaints not trended' (820.198(b)), 'failure to report under 21 CFR 803' (the MDR link). For drugs, 21 CFR 211.198 generates analogous findings, and for food, 21 CFR 117.150(a)(3) does the same.

Beyond the inspection risk, complaints are the cheapest source of post-market quality intelligence available. A complaint that triggers a CAPA at month 6 is dramatically less expensive than the same defect surfacing in a recall at month 18. The systems that handle complaints well close the loop fast and treat trending as a forward-looking signal, not a backwards-looking report.

Complaint handling is required by every major regulated-manufacturing regime. The wording differs; the substance is identical: capture, evaluate, investigate, report where reportable, respond, trend.

1. Receipt — log within 1-3 working days of any channel (phone, email, web form, sales/field engineer report, distributor return, social media monitoring, regulator forwarding). Capture: complainant identity, contact, product, lot/serial, date of event, description in complainant's own words, channel of receipt, internal receiver.
2. Acknowledgement — written acknowledgement to the complainant within the SOP-defined window (typically ≤5 working days). For severe events, the acknowledgement may include a request for the device back, photographic evidence, or a copy of the patient record.
3. Triage and severity classification — apply controlled severity vocabulary (e.g. critical / major / minor / cosmetic / use-error / inquiry-only). Severity drives investigation depth and timeline.
4. Regulatory reportability decision — apply the regulator-specific decision tree. For devices, evaluate against 21 CFR 803 (US MDR) and MDR Article 87 (EU vigilance) and equivalent for every jurisdiction the product is sold in. Decision is documented with rationale and timestamp; the regulatory clock starts at the date of complaint receipt by ANY company employee.
5. Investigation — root-cause investigation proportional to severity. Pull the DHR / MMR / batch record for the implicated lot, review production conditions, operator, equipment, in-process and release-test results, supplier inputs, post-receipt handling. Apply RCA techniques (5-whys, fishbone, FTA) appropriate to complexity.
6. Trend evaluation — compare against history. Is this an isolated event or a recurrence of a known issue? Does it match an existing hazard in the risk file? Does it cluster with other recent complaints?
7. Disposition decision — close as no action, no further investigation possible, customer education, complaint-only record, NCR raised against lot, CAPA raised, recall / FSCA evaluated, design-change considered.
8. Response to complainant — formal written response within the SOP-defined window (typically ≤30 calendar days, faster for severe events). Response includes investigation outcome to the extent legally and commercially appropriate.
9. Closure — documented closure with signature, with all linked records (regulatory submission ID if any, NCR ID, CAPA ID, RMF review ID, recall ID) attached.
10. Trend analysis (periodic) — aggregate review at SOP-defined cadence (typically monthly operational, quarterly executive, annually for PSUR/PSR/PMS report) to detect signals not visible at single-complaint level.

The reporting clock is the most-cited individual failure within the complaint subsystem. Missing the clock is itself a regulatory violation, regardless of whether the underlying complaint was eventually investigated and resolved well. The major device clocks:

21 CFR 820.198(c) requires investigation 'when necessary' and ISO 13485 §8.2.2 requires 'investigation… as appropriate'. Both phrases create a defensible space for not investigating purely cosmetic or duplicate complaints — but the decision not to investigate must itself be documented with rationale and signed. Routine 'no investigation required' notes without rationale are a frequent observation.

Where investigation is required, the depth should match severity and signal strength. Working defaults:

Investigation evidence is itself a controlled record. Each complaint file should ultimately contain: the original complaint as received, all subsequent correspondence, the severity classification with rationale, the reportability decision with rationale and timestamp, the investigation plan, the investigation evidence (lab results, DHR review notes, supplier responses, device-return analysis), the RCA output, the disposition decision, the response to complainant, the trend evaluation, the linked records (NCR, CAPA, RMF, regulatory submission), and the closure signature. Anything less risks 'investigation not documented' on the next inspection.

The single biggest leverage point in complaint handling is the linkage from the complaint file back to the actual manufactured record — the DHR (devices), the BMR (drugs), the batch production record (food / supplements / cosmetics). Without that linkage, investigation is guesswork. With it, the investigator opens one record and sees: the lot, the operators, the equipment, the in-process control results, the release tests, the materials used, the supplier lots involved, the environment, the deviation log for that lot, the QC release decision. Most root causes become evident in the first hour of review.

This is one of the structural advantages of an integrated MES + QMS over a standalone complaint-handling tool — the linkage exists by construction, with no manual lookup. Manufacturers running a complaint tool detached from their batch records typically spend days reconstructing the chain for each complaint, and miss subtle clustering (e.g. complaints concentrated on lots produced by the same operator team or with the same supplier sub-lot) entirely.

The linkage requirement also applies forward — when a complaint becomes a CAPA, the CAPA file must reference the complaint(s) that triggered it; when an RMF review is triggered, the review record must reference the complaint(s); when a regulatory report is filed, the report ID must be reflected back in the complaint file. The chain must be walkable in either direction at inspection.

21 CFR 820.198(b) requires complaint-trend analysis — the regulator's expectation is that aggregated complaint data drives proactive action ahead of individual-complaint escalation. ISO 13485 §8.4 and EU MDR Annex III (PMS report) reinforce this. The trend report is itself an inspectable record and a mandatory management-review input.

A workable trend programme covers, at minimum:

• Volume — total complaints by month, with rolling 13-month chart; volume normalised against units sold to detect rate changes rather than absolute volume.
• Severity mix — % of complaints by severity classification, with shift in mix as a signal (rising critical share is a red flag even if volume is flat).
• Time to closure — average and median, by severity; ageing-bucket distribution.
• Regulatory-reportable rate — % of complaints meeting MDR / vigilance / MedWatch criteria; rising rate triggers RMF review.
• Product-family / SKU clustering — complaints per million units shipped by SKU; identify outliers.
• Hazard-code clustering — complaints by tagged hazard from the risk file; rising frequency on a known hazard triggers RMF re-evaluation.
• Lot / batch clustering — complaints by manufacturing lot; high concentration on a single lot triggers lot-specific NCR and possible recall evaluation.
• Equipment / operator clustering — high concentration on a single line or shift triggers process re-evaluation.
• Supplier-input clustering — complaints traceable to a particular supplier sub-lot or component trigger supplier-quality action and scorecard impact.
• Geographic / customer clustering — concentration in a region or customer suggests handling / installation / training issue rather than manufacturing.
• Repeat-after-CAPA — complaints with a root cause that had a closed-effective CAPA in the trailing 12 months; the canonical CAPA-effectiveness-failure signal.

Trends are most useful when reviewed at the right cadence by the right people. Operational complaint-handling team monthly; cross-functional quality council quarterly; executive management review quarterly (with the trend pack pre-baked); periodic regulatory reports (PSUR for drugs, PMS report / PSR for devices) at the regulator-defined cadence.

• 'Failure to maintain complaint files' — informal customer-service tickets never captured as complaints. Easiest fix: every customer-facing channel feeds a single intake form with a controlled 'is this a complaint?' question.
• 'Complaints not evaluated to determine reportability under 21 CFR 803' — the reportability decision is missing, undocumented, or made by an unqualified reviewer.
• 'Failure to investigate complaints in a timely manner' — investigations open past the SOP-defined window with no documented justification.
• 'Complaint investigation did not include review of the device history record' — the linkage to DHR / BMR / batch record is missing.
• 'Failure to report under 21 CFR 803' — reportable event identified but report not filed, or filed past the 30/5 day clock.
• 'Failure to evaluate complaints for trends' — trend report not produced, or produced but not reviewed, or produced and reviewed but with no documented action.
• 'Complaint records do not contain all required elements per 820.198(e)' — missing fields (date of event, device identifier, complainant identity, dates of investigation).
• 'Use of generic complaint codes that obscure trending' — controlled vocabulary too coarse to support meaningful clustering; rising trend is invisible inside aggregated 'other' bucket.
• 'Complaints reclassified as inquiries without rationale' — re-categorisation used to suppress the complaint count is an integrity finding.
• 'Response to complainant not documented' — investigation closed but outbound communication not retained.
• 'Reportability decision made by individuals not trained or qualified' — the reviewer must have documented training on the regulator-specific decision criteria.
• 'Repeat complaints not triggering CAPA escalation' — second occurrence of the same root cause must trip the escalation defined in the SOP.
• 'Vigilance / FSCA decision-making logic not documented' — for EU MDR, the decision NOT to issue an FSCA or PSR must be documented with rationale.
• 'Complaint trending not feeding management review' — trends produced but not surfaced at the executive level.

• Complaint volume per million units shipped (rate, not absolute) — by product family, with 13-month sparkline.
• Severity mix — % critical / major / minor, with shift detection.
• Time from event to capture — date awareness to complaint-file open. Target ≤3 working days; longer threatens regulatory clocks.
• Time from receipt to reportability decision — target ≤5 working days for non-urgent, immediate for potential 2-day or 5-day reportables.
• Regulatory report on-time rate — % of reportable events submitted within the regulator-defined clock. Target 100%; non-100% is a 483-prone metric.
• Time to closure — average + median by severity; ageing buckets (≤30 / 31-60 / 61-90 / 91+ days).
• % of complaints linked to a DHR / batch record — target 100% for product-quality complaints.
• % of complaints feeding RMF review — when above zero noise floor, indicates active loop closure.
• Repeat-after-CAPA rate — % of complaints whose root cause had a closed-effective CAPA in the trailing 12 months. Target ≤5%.
• CAPA-from-complaint rate — % of complaints triggering CAPA; movement in either direction is a signal.
• FSCA / recall rate — major events per period; ideally zero, but rare-but-handled-well is better than zero-via-suppression.
• Trend-report-to-action latency — from trend identification to first documented action; target ≤30 days.

Complaint handling in V5 is structured around the linkage to the manufactured record — every complaint resolves back to the lot, the DHR / BMR / batch record, the operator, the equipment, the supplier inputs and the release-test results, without a manual lookup. The capabilities, end to end:

• Unified intake — every customer-facing channel (web, email, phone log, distributor portal, sales note, field engineer report) feeds a single intake form with a controlled 'is this a complaint?' decision, eliminating the off-system gap that drives 820.198(a) findings.
• Severity and hazard tagging at intake — controlled vocabulary linked directly to the risk-file hazard taxonomy, so post-production-information-to-RMF clustering happens by construction.
• Date-of-awareness capture — the receiver flags when the originating channel became aware, not when QA opened the file; the regulatory clock is computed from awareness, not handoff.
• Reportability decision tree — per-regulator decision logic (21 CFR 803, MDR Article 87, IVDR, MoCRA, MHRA MORE, Health Canada, PMDA, MedWatch 3500A) with documented decision, rationale, reviewer signature and timestamp. System surfaces the active clocks per jurisdiction the product is registered in.
• Live link to the manufactured record — opening a complaint surfaces the lot, the DHR (or industry-appropriate batch / device record), the operator team, the equipment used, the supplier sub-lots consumed, the in-process control trail and the release-test results. No manual lookup.
• Investigation workflow — RCA template proportional to severity (5-whys / fishbone / FTA), evidence-attachment, return-device tracking, two-person sign-off on closure.
• Auto-trend detection — hazard-code, lot, equipment, operator and supplier clustering computed continuously; threshold breaches open a draft trend signal for QA review, not a monthly batch job.
• Repeat-after-CAPA detection — when a new complaint matches a root-cause code with a closed-effective CAPA in the trailing 12 months, the complaint is auto-flagged 'CAPA-effectiveness recurrence' and routed into the CAPA-effectiveness queue.
• Vigilance / FSCA workflow — for MDR / IVDR, the system holds the MIR (Manufacturer Incident Report) and FSCA decision records with explicit-decision-not-to-file justifications, all submitted via EUDAMED-ready exports.
• Management-review integration — complaint volume, severity mix, time-to-closure, regulatory-report on-time rate, repeat-after-CAPA rate and trend signals pre-built on the management-review dashboard; no end-of-quarter scramble.
• All of the above operates under Part 11 / Annex 11 controls — audit trail on every complaint edit, two-person e-signature on reportability decisions and closures, locked-after-closure state, retention aligned to product-specific tail rules.