When complaints start: building structure for first-time teams

Your first complaint usually shows up as a support email, a note relayed by a sales rep, or a phone call about a device that behaved in a way the customer did not expect. For a team that just reached the market, the natural response is to fix the single issue and get back to the work of selling. A second complaint arrives a few weeks later. Then a third. By the time the volume is high enough to notice, the early records are scattered across inboxes and spreadsheets, and no one can say with confidence how many complaints there have been or whether any of them should have led to a CAPA.
BONUS RESOURCE: Click here to download your free complaint log and form template bundle!
Reaching the market is a phase change, not a finish line. Everything before clearance or CE marking points toward a single date. After that date the work becomes continuous, and complaints, customer questions, product changes, and regulatory updates arrive on a schedule the company does not control. Most first-time teams expected launch to bring clarity. Instead it brings a steady stream of operational work that no one fully owns.
The complaints themselves are manageable. What overwhelms early teams is the absence of a repeatable way to receive, evaluate, and close them. Building that structure while volume is still low is far easier than reconstructing it later under audit pressure or against a reporting deadline.
What actually counts as a complaint
The most common early mistake is under-capturing. A team that pictures complaints as formal, written grievances will miss most of what a regulator considers reportable. The definition is deliberately broad. A complaint is any written, electronic, or oral communication that alleges a deficiency in the identity, quality, durability, reliability, usability, safety, effectiveness, or performance of a device after it has been released for distribution.
Did you catch that? A verbal comment from a clinician that a device was harder to use than expected qualifies as a complaint. A support ticket about a reading that seemed off qualifies. A social media message questioning whether a result was accurate can qualify. None of these need the word "complaint" attached to them.
Complaints vs feedback
ISO 13485 draws a useful line between feedback and complaints. Feedback is the broad stream of information about a product once it is in use, gathered as a required input to the quality system. A complaint is the subset of that feedback alleging a deficiency.
First-time teams tend to filter too aggressively, logging only the issues that feel serious, when the safer practice is to capture broadly and evaluate afterward. A report that turns out to be user error still belongs in the record, because a pattern of user errors is itself post-market information that feeds product and labeling decisions.
Creating a single front door for every complaint
Complaints enter through whatever channels a company already has in place: sales, customer support, the general info inbox, a direct call to an engineer someone met at a trade show, etc. Early on, each of those channels handles its own issues in isolation, and the company never sees the whole picture.
The first structural move to improve the complaints process is to create a single intake path. Every complaint, regardless of how it arrives, should be recorded in one place with a consistent set of fields: what was reported, who reported it, the device with its lot or serial number, the date the company became aware, and the person who received the complaint. A shared spreadsheet can hold this at the very beginning, though spreadsheets will create problems with version control, access, and traceability as volume rises.
The bottom line is that one person should be able to look in one place and answer three questions: how many complaints are open, how old the oldest one is, and whether any of them touch on safety. A company that can't answer those quickly is already carrying risk it can't see.
Understanding the reportability decision
Out of all the steps in complaint handling, this is where first-time teams carry the most risk. Certain complaints are not internal quality matters alone. They trigger mandatory reports to regulators on fixed timelines, and those clocks start when the company becomes aware of the event, not when it finishes investigating.
Under U.S. Medical Device Reporting rules in 21 CFR Part 803, a manufacturer must report a death or serious injury associated with its device within 30 calendar days of becoming aware of it. Events that require remedial action to prevent an unreasonable risk of substantial harm carry a far shorter window of five working days. In the European Union, the Medical Device Regulation sets a general serious-incident deadline of 15 days, with shorter windows for deaths and serious public health threats.
To avoid missing one of these deadlines, companies need to add a triage step that is built directly into their intake process. When a complaint is logged, someone with the right training must be able to make an early call on reportability using a documented decision method rather than instinct. Complaint handling requirements under 21 CFR 820.198 and ISO 13485 clause 8.2.2 both expect that evaluation to be recorded, including the rationale when a team decides an event does not meet the reporting threshold. Recording the date of awareness in the same step is what makes a timeline defensible when an auditor asks the team to prove a report went out on time.
Where complaints connect to the rest of the system
A complaint is rarely a self-contained event. Handled well, it becomes a signal that flows into several other parts of the quality system, and those connections are what turn scattered incidents into an operating rhythm.
Investigation comes first. Not every complaint warrants a full investigation, so a first-time team needs criteria that decide how far to go: severity, frequency, and whether the issue points to a systemic cause. A single occurrence of a known, low-risk issue may close with a short note. A cluster of similar reports crosses a threshold and escalates into a corrective action and preventive action (CAPA) investigation, where the goal shifts from resolving one case to preventing the next.
Complaints also feed risk management. ISO 14971 treats post-market information as a required input to the risk file, which means real-world complaint data should either confirm or challenge the risk estimates a team made before launch. A hazard that appears more often than the pre-market analysis predicted is a reason to revisit the file, not a number to leave untouched.
Complaints drive change as well. A recurring usability issue may call for a labeling update or a design revision, and each of those runs through change control. The teams that stay steady after launch are the ones that can trace a clean line from a complaint, through investigation and risk review, to a controlled change, without losing the thread in a handoff between tools or people.
BONUS RESOURCE: Click here to download your free complaint log and form template bundle!
Get the structure and medtech-specific workflows your team needs for better complaint handling with Greenlight Guru
None of this requires a heavy system on day one. A first-time team does not need enterprise post-market operations built for a company 10 times its size. It needs just enough structure to hold control as volume rises, and it needs that structure to grow with the product rather than get torn out every time the company reaches a new stage.
The work done before launch is the foundation. The risk analysis, the design records, and the procedures written during development all carry forward into post-market operation. Complaint handling connects to that existing work instead of starting a separate track, which is the difference between building on a year of effort and duplicating it.
Greenlight Guru gives early post-market teams one place to receive complaints, make and document the reportability decision, link complaints to CAPA and risk, and manage the changes that follow, without the version-control problems and traceability gaps that come from stitching the process together across spreadsheets and shared drives.
If you're ready to see how a medtech-specific eQMS from Greenlight Guru can do for your business, get your free demo today!
Keep reading
If you are building out your complaint handling process, these related guides go deeper on the specific components:
Etienne Nichols is the Head of Industry Insights & Education at Greenlight Guru. As a Mechanical Engineer and Medical Device Guru, he specializes in simplifying complex ideas, teaching system integration, and connecting industry leaders. While hosting the Global Medical Device Podcast, Etienne has led over 200...
Related Posts
The first 90 days on the market: what medtech teams underestimate after clearance
FDA inspections under QMSR: a guide to Compliance Program 7382.850
How to Manage the Different CAPA Phases
Get your free download
Complaint Log + Form Template Bundle




