Complaints Are Signals, Not Tickets

A complaint comes in. Someone reviews it. It gets investigated. It gets closed. For most organizations, that’s the whole story.

That is exactly the problem.

A complaint is not a task

Under modern regulatory expectations, complaints aren’t work items to be cleared. They are signals – the only continuous, unfiltered channel through which the real world reports back on how your device actually behaves once it leaves your control.

Each one carries information about:

• Real-world system performance – not as designed, as encountered
• Emerging risk, before it is visible in any formal metric
• Drift that hasn’t yet tripped a control, and by definition won’t

The catch is that this information only exists if complaints are evaluated in context – against trends, against risk controls, against lifecycle data from the same device family.

Handle them in isolation and you are closing tickets.

Handle them as part of a system and you are reading the room before regulators do.

Complex systems don’t fail all at once. They drift.

This is the part that makes isolated signal handling genuinely dangerous rather than merely inefficient.

Catastrophic failure in a complex system is almost never a single event with a single cause. It is the accumulation of small deviations, each one individually below the threshold of any alert, each one individually defensible. Every complaint, handled on its own terms and resolved on its own terms, looks like a closed case – and each closure is correct, judged in isolation.

But the system is registering something the case file isn’t: a pattern, a pressure point, a slow shift in how real-world conditions are interacting with your controls.

When signals are siloed, three specific things break.

Three Things That Break

1. You lose weak signal detection

The earliest indicators of systemic failure are almost always soft. A slightly elevated complaint rate in one product line. A subtle shift in the language customers use to describe a malfunction. A cluster of issues that don’t share a category but share a cause.

That last one deserves emphasis, because it is where most systems fail silently. A cluster only becomes visible if the underlying events are coded consistently enough to be compared – and human coding at volume is not consistent. On ambiguous IMDRF Annex terms, independent reviewers agree with one another only 56–71% of the time. When the same underlying failure enters your system under three different codes, it isn’t a cluster. It’s three unrelated complaints, correctly closed.

Isolated handling doesn’t just fail to surface weak signals. It manufactures the conditions under which they can’t exist.

2. Feedback loops break down

Resilient systems self-correct because information flows back through them. That is the entire mechanism – sensing, integrating, adapting.

When complaints are processed as one-off tasks, the loop is severed at the first step. The information reaches a reviewer, a resolution and a file, and stops. It never reaches the risk file it should be updating. It never reaches design. It never reaches the next production run.

The system can’t learn. It can’t adapt. It keeps producing the exact conditions that generated the complaint in the first place – and then it produces the complaint again, and someone closes that one too.

This is why complaint volume is such a poor health metric. A rising volume with a severed feedback loop and a rising volume with an intact one describe completely different organizations, and no throughput dashboard can tell them apart.

3. You normalize drift

This is the most dangerous outcome, and the hardest to see from inside.

Over time, teams calibrate to a baseline that has already moved. What would once have been flagged becomes routine – not through negligence, but through the ordinary human process of updating expectations to match observed experience. Every individual recalibration is reasonable. The cumulative effect is that the threshold for concern tracks the drift instead of catching it.

By the time a pattern is undeniable, it is no longer early. It is an event. And by then, regulators are frequently already looking at the same data you are – because MAUDE, EUDAMED and the vigilance systems aggregate across manufacturers whether or not you aggregate internally.

The pattern can be visible in public data before it is visible in yours.

The question resilient organizations are learning to ask

Not: Is this complaint resolved?

But: What is the system telling us?

That is not a rhetorical upgrade. It is a different architecture. The first question can be answered by a workflow – routing, investigation, closure, done. The second cannot be answered by any component that only sees one complaint at a time. It requires the complaint stream, the risk file, the hazard matrix and the post market data to be one connected, continuously evaluated object.

The regulatory frame has already moved this way. QMSR’s alignment with ISO 13485 and ISO 14971 makes the complaint-to-risk linkage an expectation rather than an aspiration; EU MDR Articles 83–88 build the same loop into the PMS plan, the PMS report and the PSUR. The requirement is no longer that you handled each complaint. It is that your risk posture reflects what your complaints collectively mean.

What this looks like when it works

This is the shift empowerreg was built around: moving complaint management out of a closed workflow and into a living feedback loop that informs risk posture in real time.

Concretely, that means complaints, adverse events, service data, MAUDE and EUDAMED signals pinned to a common device identity and a common coding frame – so that clustering is structurally possible rather than dependent on whether one reviewer happens to remember a similar case from eight months ago. It means the linkage from complaint to risk file is automatic and live, not a quarterly reconciliation exercise. And it means humans stay on every consequential call, with the machine doing the aggregation that humans demonstrably cannot do at volume.

Pilot Results

In pilot, on deliberately degraded production-grade complaint data, that architecture delivered end-to-end evaluation in 3.8 minutes per complaint, with 95–100% agreement with expert reviewers on the determinations that carry regulatory weight – and consistency where human reviewers diverge.

The speed is the headline. The aggregation is the point.

Final Reflection

One question worth sitting with:

What is your complaint data currently surfacing – and is anything in your organization structurally capable of hearing it?