Medical Device Complaint vs. Service Request: Where Is the Line?

A customer calls because a medical device is not working as expected. The service team opens a ticket, schedules a technician, replaces a part, and gets the customer running again.

Service request closed.

But was it also a medical device complaint?

That question creates confusion in a lot of growing medical device companies. Customer Support may think of the event as a service issue. Field Service may see it as a repair. Engineering may see a component failure. Quality may see information that needs to enter the complaint-handling system.

All of those perspectives can be correct at the same time.

The important distinction is that “service request” and “complaint” describe different things. A service request describes work the company may need to perform. Complaint classification addresses what the customer or other source is alleging about the device, its performance, safety, quality, or related service.

A single customer event can therefore be both a service request and a complaint.

Start with what the customer is telling you

Under the current FDA Quality Management System Regulation, complaint handling is tied to the ISO 13485:2016 quality-management framework. In practical terms, a complaint involves communication alleging a deficiency associated with a medical device that has been released from the organization’s control, or with a related service that affects device performance.

The key word is deficiency.

If a customer is alleging that the device failed, malfunctioned, produced an unexpected result, did not perform as intended, arrived damaged, was mislabeled, created a safety concern, or otherwise did not meet an expected requirement, the event should generally enter the company’s complaint-evaluation process.

That does not automatically mean the device is defective. It does not mean the complaint is valid. It does not mean the event is reportable to FDA.

It means the information deserves the appropriate evaluation.

That distinction matters because companies sometimes make complaint decisions too early. A support representative may decide that something was “user error.” A service engineer may conclude that replacing a part fixed the problem. A commercial team may call an issue “customer dissatisfaction.”

Those may eventually be reasonable conclusions, but they should come after appropriate evaluation, not instead of it.

A service request is not automatically a complaint

Many legitimate service interactions do not allege any deficiency with the device.

Examples might include:

• Scheduling routine preventive maintenance
• Requesting installation or relocation assistance
• Ordering consumable or replacement items with no reported failure
• Asking how to use a feature
• Requesting additional user training
• Scheduling a planned software upgrade
• Requesting configuration assistance
• Asking when the next maintenance visit is due

These activities can normally remain within the service or support process unless additional information suggests a device, process, labeling, software, or service deficiency.

The problem arises when companies assume that anything entered into the service system is therefore not a complaint.

The system used to receive the information does not determine its regulatory significance.

A service event can also be a complaint

Consider a few examples.

Example 1: A customer asks for annual preventive maintenance.
There is no allegation that the device failed or performed incorrectly. This may simply be a service request.

Example 2: A customer reports that the device repeatedly shuts down during use and asks for a technician.
The company may need to dispatch Field Service, but the customer has also alleged a performance deficiency. The event should be evaluated through the complaint process.

Example 3: A customer reports an error message and Support resolves it by changing a configuration setting.
The fact that Support resolved the issue remotely does not by itself determine whether the original report was a complaint. The company still needs to consider what the customer alleged and whether the device failed to meet an expected requirement.

Example 4: A customer asks for additional training because a new employee does not understand how to operate the system.
That may simply be a training request. But if the customer says the instructions are unclear or the interface repeatedly leads users to make the same error, the issue may also raise questions about usability, labeling, or design.

Example 5: A service technician replaces the same component for the third time at the same customer site.
Even if each visit restores operation, repeated failures may contain important complaint and trending information that should not remain isolated inside service records.

This is why a simple rule such as “If Field Service fixed it, it is a service request” does not work.

Do not make frontline employees become regulatory experts

Customer Support, Technical Support, and Field Service play an essential role in complaint handling because they are often the first people to hear about a potential product problem.

That does not mean every frontline employee should be expected to perform a detailed regulatory assessment.

A better system teaches customer-facing employees to recognize information that needs further evaluation.

They should know how to:

• Capture what the customer reported accurately
• Record the device and customer information available to them
• Document relevant symptoms or error messages
• Identify whether anyone was injured or potentially placed at risk
• Preserve returned parts or evidence when required
• Escalate potential complaints promptly
• Avoid rewriting the customer’s report into a conclusion

The complaint process can then determine what additional investigation, regulatory assessment, technical review, or follow-up is needed.

This supports one of Groundwork’s core operating principles: Quality owns the framework. The business owns the work.

Quality does not need to perform every technical investigation or customer interaction. Technical Support, Field Service, Engineering, Operations, Manufacturing, and other subject-matter experts may perform much of the actual investigative work.

But the organization needs a defined complaint framework that makes responsibilities, escalation, review, investigation, documentation, and closure clear.

Complaint oversight and technical investigation are not the same thing

This distinction becomes especially important as companies grow.

Quality may oversee the complaint-management system, but Quality may not be the best group to determine why a scanner failed, why a software deployment was unsuccessful, or why a particular component stopped functioning.

The technical investigation should involve the people who understand the product and failure mode.

Quality’s role may include ensuring that:

• The event was appropriately classified
• Required information was captured
• The investigation addressed the reported issue
• Regulatory-reportability evaluation occurred when applicable
• Investigation conclusions are supported by evidence
• Complaint records are complete
• Potential trends are identified
• Systemic issues are escalated into CAPA or other processes when appropriate
• The complaint is formally reviewed and closed

This model prevents two common extremes: Quality attempting to perform investigations it is not technically equipped to perform, or technical teams effectively controlling the complaint system without sufficient quality oversight.

The service system and complaint system should talk to each other

One of the biggest risks in a growing medical device company is creating two separate versions of product performance.

The service organization knows which parts are being replaced. Technical Support knows which errors customers are reporting. Engineering knows which failures are being investigated. Quality maintains the complaint records.

If those systems are disconnected, important trends become difficult to see.

Imagine that Field Service replaces forty of the same component over six months, but only three formal complaints reach Quality because most of the events were classified as routine service calls.

The company may conclude from the complaint database that there is little evidence of a problem while the service organization is seeing the opposite.

That is not just a documentation problem. It is a visibility problem.

A mature process should establish a reliable connection between customer-support records, service activity, returned parts, complaint records, investigations, and trending.

Be careful with the phrase “user error”

“User error” can become an easy way to close an investigation too quickly.

Sometimes a user genuinely did not follow the instructions. But that does not automatically end the quality-system analysis.

The next questions may include:

• Were the instructions clear?
• Was the user appropriately trained?
• Is the same mistake occurring with multiple customers?
• Could the interface or device design contribute to the error?
• Could the foreseeable misuse create a safety risk?
• Is labeling or training material contributing to confusion?

A technically accurate conclusion may still reveal an opportunity for product, labeling, training, or usability improvement.

Complaint investigation should help the organization understand what happened, not simply identify a category that allows the record to be closed.

Complaint does not automatically mean MDR reportable

This is another important distinction.

A complaint and an FDA Medical Device Report are not the same thing.

Companies may receive many complaints that do not meet the criteria for Medical Device Reporting. At the same time, complaint intake needs to capture enough information to identify events that may require further regulatory evaluation.

For manufacturers marketing devices in the United States, events involving deaths, serious injuries, and certain malfunctions can trigger MDR requirements depending on the circumstances.

The reportability decision should therefore be a defined part of the complaint process rather than something left to informal judgment by the person who happened to receive the original phone call.

FDA provides additional guidance on Medical Device Reporting for Manufacturers, and companies should ensure their procedures reflect the requirements applicable to their products and markets.

Use triage questions instead of department labels

A practical intake process can help employees recognize when a customer interaction requires complaint evaluation.

Instead of asking only “Is this a service call?”, consider questions such as:

• Did the customer allege that the device failed or malfunctioned?
• Did the device perform differently from what the customer expected or from its intended performance?
• Was there an allegation involving safety, quality, reliability, labeling, usability, or performance?
• Was a patient, user, or other person injured or potentially placed at risk?
• Did the customer report an incorrect, delayed, missing, or unexpected result?
• Was a part replaced because it failed rather than because of routine maintenance?
• Does the issue appear to have occurred before?
• Could the reported problem require further technical investigation?

These questions do not replace the formal complaint procedure. They help frontline teams recognize when information should move into that procedure.

A simple operating model

For a growing medical device company, the workflow does not need to be unnecessarily complicated.

A practical model might look like this:

1. Receive the customer issue. Support, Service, Sales, Clinical, or another employee captures the original information.
2. Perform initial triage. Determine whether the information potentially alleges a device or related-service deficiency.
3. Open or link the complaint record when appropriate. The service ticket can remain open for operational work while the complaint record provides quality-system oversight.
4. Perform technical investigation. The appropriate subject-matter experts evaluate the failure, product history, service information, returned parts, logs, or other evidence.
5. Evaluate regulatory significance. Perform MDR or other market-specific reportability assessments when applicable.
6. Review for trends and systemic issues. Determine whether the event connects to similar complaints, service records, supplier issues, nonconformances, or CAPAs.
7. Review and close the complaint. Ensure the investigation and required records are complete and conclusions are supported.

The details will vary by organization, but the underlying principle is straightforward: customer service activity and complaint oversight should be connected without forcing them to become the same process.

Test your current process

Take five recent service tickets and ask:

• Could any of these also meet our complaint criteria?
• Who made that determination?
• Is the decision documented?
• Can Quality see recurring service failures?
• Can complaint investigators access relevant service information?
• Are replaced parts linked to the complaint or investigation?
• Can we trend failures across both systems?
• Would we recognize a potentially reportable event quickly?

If the answer depends on which employee happens to receive the call, the process probably needs more structure.

The line is based on the information, not the department

The difference between a medical device complaint and a service request is not determined by whether the customer called Technical Support, whether a technician was dispatched, or whether the problem was fixed.

The question is what information the company received and whether it alleges a deficiency that requires complaint evaluation.

A well-designed system allows Service to focus on restoring the customer while ensuring Quality has visibility into the information needed to oversee complaints, investigations, regulatory assessments, and trends.

Those goals do not compete with each other. Done well, the same process can support both.

If your company is building or strengthening this process, the Medical Device Complaint Management & Investigation Starter Kit includes an editable complaint procedure, intake and triage tools, investigation worksheets, reportability assessment guidance, trending tools, roles and responsibilities, sample completed records, and a 30-day implementation plan.

Still building the broader quality system?

If complaint management is only one of several processes you are trying to prioritize, start with the free Medical Device Startup SOP Checklist. It can help you identify which procedures, records, and quality-system controls your organization may need as it grows.

For additional information on the current U.S. quality-system framework, see the FDA’s Quality Management System Regulation (QMSR) resources.