Essentials Of Effective Product Support Part 2: Systematic Product Complaint review
Updated: Mar 27
In the earlier part of this article, you would have read about the importance of Traceability on
your manufactured products as one of the key elements for providing effective Product
Support. Now let’s review another factor that is also essential in how effective support for
product is carried out.
A progressive manufacturer sees an opportunity for improvement, if and when a Product
Complaint has been raised by their client. That’s because a capable MSME organization tends to proactively deal with Product and Customer Complaints by utilising robust systems, as they consider it critical for their growth. So irrespective of whether you are using a manual system or software driven system, the key to successful identification of problem and implementing the corrective action depends on the diligent method of how you conduct the Product Complaint review.
In the earlier section, we have already dwelt upon the importance of data capture and record
keeping during Product’s manufacturing process for Traceability function to be effective.
Similarly, now to ensure a systematic Product Complaint Review, the Customer’s intimation of Product Failure should be followed up with a structured Complaint Escalation process along with Technical review. The outcomes of these processes should be duly recorded for the data to be analysed, and followed through to close the loop using robust complaint remedial process. These actions should also be complemented with effective communication of the results to all the appropriate stakeholders. As expressed before, all these can either be managed through Manual process or by using a Software solution, depending upon the volume of business.
Upon receiving an intimation of Product Complaint from the client, the manufacturer’s ultimate aim should be to successfully find its root cause to develop and implement Corrective as well as Preventive action (CAPA). This starts by documenting the Nature of Complaint, the Type of Failure and the observed consequential effects as expressed by the client in the Customers own words. This recorded input of Customers Complaint has greater significance when the issue is having adverse outcome on area such as safety, health or environmental effects. Such documented records are also important to evaluate the magnitude of the customer complaints to decide applicability of activating a product recall. Using the Voice of the Customer as an input, an onsite investigation has to be conducted by the Field Service or Product support or Technical person to compile a detailed Product Complaint Report. This will give insight in understanding the nature of failure. Conducting an onsite analysis or field report also satisfies one of the effective philosophies for continuous improvement or problem solving – Go and see the work place (Gemba in Japanese). This philosophy is about going to the real source to have the right perception of problem to solve, instead of trying to solve it sitting in the office chair.
Generally a manufactured product’s failure can be broadly classified as either Failure due to
defects or Failure due to abuse. Failures termed as abuse would be on cases where the
operating conditional limits for the product has exceeded those for which it has been designed for. This can happen if the customers’ expectations haven’t been captured correctly during design stage or else due to operational ignorance from the customer’s side or an actual case of abuse during product utilization. If the issue is due to misreading customer’s primary expectation, then naturally a product redesign is required for continued acceptance of the product.
If it’s however a case of wilful abuse, then the liabilities of such failures are not borne by the
manufacturer. Nevertheless in such a case it is vital that the customer is enlightened suitably on the correct mode of product utilization. This will ensure that there is no loss of product, time and costs to all related parties.
Product failures attributed to defects can be either categorised as manufacturing defects or
design defects. In principle, it is expected that during design stage itself the product should
have undergone FMEA (Failure Mode Effect Analysis) wherein all potential failures would have been anticipated through a systematic analysis of the product. The objective of FMEA in Design stage is to identify and take action to eliminate failures in various stages such as Manufacturing, Assembly, Operation or Service.
Despite this when a failure is reported from the field, the FMEA process can still be triggered as a result of Quality directive. FMEA process is usually conducted by a cross functional team from varied departments such as Design, Manufacturing, Quality, Service etc. They identify the various possibilities of failure for every function of the product. For each failure the potential effect and its Severity is rated. And for each failure mode, its root cause is determined along with rating its probability of occurrence and its process of control. The outcome of this detailed analysis would guide in recommended action to be taken.
Irrespective of whether FMEA process is used or not, every reported product failure has to be evaluated to identify Root Cause of Failure. While it is possible that a root cause was opined during the field analysis on the product complaint report, however in certain cases a more detailed engineering analysis might be required to conclude on the root cause of product failure.
Having an inquisitive mind set is a basic requirement to investigate root cause of failure. There are a few standard methods to align ourselves to this requirement. One easy method that can be practised is the “5 Why” technique. This is based on the principle of asking “Why?” consecutively at least 5 times, with each answer forming the base for the next “Why?” question. This interrogative approach will direct the answer to the root cause of the problem.
An extension of this technique is the “5W 1H” method. This involves asking questions such as Why, When, Where, What, Who and How to find answers to the problem. This method will give perspective of consequences or connection of the causes while identifying the root cause.
Another method is to trace the cause and effect by using a common problem analysis tool
known as Fishbone Diagram. This is an effective tool for identifying root cause of problem
through brainstorming sessions. The name of this process is derived from the layout of the
diagram, wherein the various categories of causes are denoted as branches around a main
arrow pointing towards the problem, which looks similar to a fishbone. If in case the categories of causes are difficult to ascertain at first, then generic categories can be used such as Person, Material, Machine, Process, Measurement and Environment. Against each category, the possible causes can be noted as a branch. The listed out causes, can be analysed for solving as per priority.
Irrespective of the method used to identify the root cause, once it is identified, the
manufacturer would have to implement both corrective actions to address the present
problems and preventive action, so that it doesn’t occur in the future again. This would entail
that all the associated stakeholders are effectively communicated on their respective actions to be taken. For example an ECN (Engineering Change Notice) would have to be documented and circulated by the design department to the respective affected departments or supplier, if there has been any impact on the design front. Likewise the Production or Quality departments would have to suitably amend and release their updated Work Instruction or process to the respective sections or vendor. They will have to maintain a change and revision document control in their Quality Management System. The product changes should be effectively documented through the traceability feature and a suitable bulletin should be released to the associated support departments. In certain cases, obligatory changes to the documentation of the products user manual would need to be introduced. Sometime it might also require training internal teams appropriately or else educating the User or customer in the correct product usage methods.
So in conclusion we can state that the Product Complaint Review starts with effective problem identification, followed up with analyzing the root cause, developing the CAPA solution, Implementing and managing the Change and ends with communicating required actions taken to the relevant stakeholders. Throughout all these steps, detailed documentation and record keeping is mandatory for review and knowledge sharing.
Hope this summary on the importance of conducting a meticulous Product Complaint Review was helpful. We will be happy to hear your views on this. This article would conclude in the next part with an explanation of another essential function for effective Product Support