In a software development company: Is every bug reported by the customer a complaint?

[Kronos147]

That would be a good approach, but I was thinking: most of the bugs come in by an online registration system. Should we give the customer an option here to classify the bug as complaint?

It's your system. Classify it how you want. I would rather have the data than not.

However you classify it, you must consider what requirements apply (i.e. 8.7, 9.1, 10.2), and how to meet them.

If you have a good CAPA process, it is easier to add a new class then develop a new system.

 

[somashekar]

That would be a good approach, but I was thinking: most of the bugs come in by an online registration system. Should we give the customer an option here to classify the bug as complaint?

If my new shoe bites, is it a complaint..... It is and it is not.
Into your QMS please don't give free access to the customer., but listen to him nevertheless., and you are doing it fine.

 

[Silex7]

Great point. One of the steps in our complaint handling was "Is there a nonconformance?"...a simple Y/N checkbox that helped steer resolution.
Most complaints were "No", though we may have chosen to do something about it anyway...

Ninja, if So do you handle phone customer notification the same?, I mean you would be having huge complaints data , unless you do internal classification to the type of notifications you receive.

 

[Silex7]

That would be a good approach, but I was thinking: most of the bugs come in by an online registration system. Should we give the customer an option here to classify the bug as complaint?

Remco, We have an Online registration system for the complaint , but I would prefer to have my own classification for the notifications I receive from customers, otherwise you will have a huge data, and you can not be certain which is a real complaint and which is not. the point with registration data systems , is that it's an entry data system, it could be good as a customer feedback register, but it can't be rational nonconformities.

What I meant , is that it's impossible ( let's say very difficult, not practically impossible) to follow the customer's notifications without a consequence organized analysis to solution, corrective actions..(QMS requirements) , once you decided to it, yo must be ready to follow up with it because definitely you will be asked about it.

 

[Ninja]

Ninja, if So do you handle phone customer notification the same?, I mean you would be having huge complaints data , unless you do internal classification to the type of notifications you receive.

Absolutely. Most complaints I ever received were by phone ("Dude, the stuff you sent me didn't work!")...with email a close second.

As I see the thread here evolve, I realize that what is being described seems more like a late stage development process (both we and the customer know that there will be bugs to fix kind of thing). If this conclusion is correct, I'd have to retract some of my earlier statements...

When running a product development project (materials, not computers), we would sample a "best efforts" material to a customer to see if it met their need...being R&D, it often didn't and we learned from it and made a better batch to send for testing. This was NOT handled as a complaint, even though it was customer feedback that the product didn't work...it was handled under design control under "validation". (Failed validation trial to be specific).

So I guess if your process includes shipping the software knowing it may (will) have bugs that you will fix later based on customer feedback...and your customer knows this as well...you may actually avoid the word "complaint" and handle it under design control instead...
In my mind, you would have to define (maybe formalize) the removal/finishing of a system from design control into "production"...and any negative feedback after DC is complete would then be a complaint.

 

[Ninja]

Into your QMS please don't give free access to the customer., but listen to him nevertheless., and you are doing it fine.

Totally agreed.
Any internal classification or 'bucketing' is internal only...your customer doesn't decide if there is a NC...only you do, as part of your complaint handling, totally separate from the customer.

 

[tony s]

When running a product development project (materials, not computers), we would sample a "best efforts" material to a customer to see if it met their need...being R&D, it often didn't and we learned from it and made a better batch to send for testing. This was NOT handled as a complaint, even though it was customer feedback that the product didn't work...it was handled under design control under "validation". (Failed validation trial to be specific).

This is a good point, particularly on software developers. Clause 8.3.4e can be applied here as it specifies:

"any necessary actions are taken on problems determined during the reviews, or verification and validation activities"​

 

[zeussaxis]

This thread has gone quiet for a while, but it's a great discussion and I felt there were a couple other important notes to include for those of you regulated by the FDA. How you approach Complaints can have a lot of unintended consequences:
- Be careful not to overtly design your quality processes around what limited resources you have, as a) the requirements do not change based on economic factors, and b) you may end up with findings for both inadequacies in that process as well as 820.20(b)(2) for provision of resources (frying pan to fire!). You always must be able to say your process is designed in a way that meets the requirements, and that you have the appropriate resources to maintain control.
- No matter where you draw the line on calling something a complaint, you are required to assess all sources of quality data to identify existing or potential problems (820.100(a)(1)). Whether you're trying to eliminate noise so you can focus on "real" complaints or limit the effort needed to manage the workload, you must have sufficient evaluation and trending of the "other" data sources to support that you're not ignoring or hiding problems. Additionally, it's possible that by trying to segregate complaint data from "other" data you may not be able to see a growing trend across the two data sets, which can result in a much bigger workload when you find out it's broken.

Lastly, to echo many others: any allegation that your product or service isn't working as advertised is a complaint and must be handled per the requirements of 820.198 regardless whether you call it a "complaint" or any other term. How you process and bucket it is entirely up to you, but you must investigate and justify the actions you take. We log every call/email/interaction where the customer needs support, and if there's an allegation that the product didn't work correctly, it's a complaint. If there's an allegation that there's an unmitigated hazard or harm, it's likely also an MDR and must be reported to the FDA. Be sure you can readily pull both these labels out of any buckets you create to avoid being forced into a more burdensome approach by the FDA.