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

[Marc]

Out of curiosity, do you write "off-the-shelf" software that many companies/people use, or is most of your software coded for specific companies/people?

 

[Ninja]

but you could also use the complaint 'label' for identifying and fixing more serious issues, using a special process, perhaps involving account managent etc. In that case maybe calling everything a complaint is not the best option?

You can respond to each complaint according to whatever metric or judgement or assessment process you like.

Some may be "unreasonable - do nothing", some may be "OFI...lessons learned", some may be treated severely with much customer interaction and improvement, Some may be grounds for recall and rework.
None-the-less...they are all complaints.

It is up to your company to judge severity and recourse (if any)...trying to redefine the word "complaint" just confuses things.
As I mentioned above, if a customer contacts you expressing displeasure at your company, actions or product...it's a complaint IMO.

Rather than coming up with another word to use instead of "complaint"...bucket out your complaint process to separate frivolous vs. significant complaints...then handle them all in the one system.
Side benefit...now you only have one log to look at when trying to judge customer interaction...are they tolerant, or do they complain about everything? Good to know next time you try to sell them something...

 

[Jim Wynne]

but you could also use the complaint 'label' for identifying and fixing more serious issues, using a special process, perhaps involving account managent etc. In that case maybe calling everything a complaint is not the best option?

Changing the name of a thing doesn't change the essence of it. You have a "notification" that there is (possibly) an undesirable flaw in your product. How you characterize the notification doesn't (or shouldn't) change your reaction to it. Without investigation it wouldn't be appropriate to classify the phenomenon as a nonconformity.

 

[Ninja]

Without investigation it wouldn't be appropriate to classify the phenomenon as a nonconformity.

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...

 

[dsheaffe]

Working in a software development company, we don't classify a bug as a customer complaint. You are correct that unlike most industries, bugs/defects in the product are more or less accepted - or even expected - which was quite a culture shock when I first started in this industry coming from an engineering background where no "bugs/defects" were expected/accepted. From my perspective, including bugs as a complaint is overkill. Having said that, we still report on the numbers of bugs reported and try to analysis the root cause of the bug, but this is done separately from our 'complaints' process.

We will escalate a bug as a complaint however if the customers expectations are not met in resolving the bug (ie, we deliver a fix that does not work or breaks something else or a fix is not delivered in the agreed time frame, etc)

 

[qualprod]

Working in a software development company, we don't classify a bug as a customer complaint. You are correct that unlike most industries, bugs/defects in the product are more or less accepted - or even expected - which was quite a culture shock when I first started in this industry coming from an engineering background where no "bugs/defects" were expected/accepted. From my perspective, including bugs as a complaint is overkill. Having said that, we still report on the numbers of bugs reported and try to analysis the root cause of the bug, but this is done separately from our 'complaints' process.

We will escalate a bug as a complaint however if the customers expectations are not met in resolving the bug (ie, we deliver a fix that does not work or breaks something else or a fix is not delivered in the agreed time frame, etc)

Completely in agreement with dsheaffe, that is a good practice.

 

[somashekar]

The reason I asked is that we are going for ISO9001 certification, but apart from that it is an interesting question i think.
Bugs ore more ore less accepted in the business therefore I think not every bug should be treated like a complaint.

The way i feel it is that complaints are about expectations not being met and it is all about communication.
If we treat all bugs as complaints we have lots of complaints which are now handled just fine within our operation processes

Perhaps it would be a good idea if you can 'promote' certain bugs to complaints so they are treated as such
Maybe when bugs are very serious and/or the customer feels expectations are not met at all

The fact that you have a complete department to deal with bugs says that you have recognized this as a process in your product post delivery activity. If I was you, I will set up a way that the head of this department has all the competency and authority to decide what he would log as a complaint. That I would count as customer complaint.....

 

[John Broomfield]

Yes, and we should be thankful that some customers take the time and effort to give actionable feedback.

All complaints about bugs are potentially useful but they are not of equal importance and will be carefully analyzed before patching (correcting) and before invoking analysis and removal of root causes from the software itself.

Apart from interactions with changes in the operating system and other programs we may need to bundle bugs for a complete redesign and recoding of a future version of the software.

Our terms and conditions will be careful not to imply any guarantee of bug-free functionality.

 

[remco]

If I was you, I will set up a way that the head of this department has all the competency and authority to decide what he would log as a complaint.

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?

 

[Jean_B]

Think about the interaction you'd be causing.
Customer wants to report bug, doesn't know what complaint checkmark does => will check because he thinks it gets resolved quicker.
Customer has checked bug as complaint, has expectation that complaint is addressed as such leaving you no initiative.

Looking at it from the standards side, I like ISO 13485's approach which considers a communication to be an alleged deficiency (with some specific characteristics to check). Then there is the determination whether it actually is (customer's claim might be disproven using company or complaint information), e.g. it's not a non-conformity as it doesn't relate to a claimed or implied specification towards customer nor an internal specification. Thus in my mind complaint handling was always the transformation from alleged (complaint) to true (non-conformity; now to decide what to do towards customer and towards the (design) problem) or false (disproven allegation;might still be opportunity for improvement/development) based on complaint investigation.
The ISO 9000 approach uses "expression of" and "explicit or implicit expectation", which makes it a bit too vague. I do appreciate that it covers the interaction process itself as worthy of being targeted by complaints.

Source definitions (from ISO OBP).

complaint (General)
<customer satisfaction> expression of dissatisfaction made to an organization (3.2.1), related to its product (3.7.6) or service (3.7.7), or the complaints-handling process (3.4.1) itself, where a response or resolution is explicitly or implicitly expected
ISO 9000:2015(en), 3.9.3

complaint (Medical Device Industry)
written, electronic or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, usability, safety or performance of a medical device that has been released from the organization’s control or related to a service that affects the performance of such medical devices
ISO 13485:2016(en), 3.4