Essentials Of Effective Product Support Part 2: Systematic Product Complaint review

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 systematic product complaint review 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 utilizing 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 the problem and implementing the corrective action depends on the diligent method of how you conduct the Product complaint review procedure.

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 procedure, 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 analyzed, 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.

For a systematic product complaint review, the manufacturer’s ultimate aim should be to successfully find its root cause to develop and implement corrective as well as Preventive action (CAPA) right upon receiving an intimation of Product Complaint from the client. 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 into 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 workplace (Gemba in Japanese). This philosophy is about going to the real source to have the right perception of the 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 have exceeded those for which it has been designed for. This can happen if the customers’ expectations haven’t been captured correctly during the 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 willful 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 categorized as manufacturing defects or design defects. In principle, it is expected that during the 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 the 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 mindset is a basic requirement for product quality assurance and to investigate the root cause of failure. There are a few standard methods to align ourselves to this requirement. One easy method that can be practiced 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 analyzed 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 product quality assurance 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 procedure 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. This is an essential part of the product improvement cycle.

Hope this summary on the importance of conducting a meticulous product complaint review procedure 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 systematic product complaint review and support.