Which customer complaints should go to R&D, and in what order?

This answer covers technical complaints about industrial and specialty chemical products, such as lubricants, coatings, adhesives and process fluids, that a manufacturer or distributor receives from business customers. It does not cover consumer product incident reporting, drug or medical device complaint files, or recall decisions, which follow their own regulators' rules and timelines.

Which conditions decide whether a customer complaint goes back to R&D?

A customer complaint goes back to R&D when three conditions hold together: the failure repeats across a group of complaints, the evidence points to the product rather than to how it was applied, and the fix would need a change to the formulation, the specification or the process. If any one is missing, the complaint stays with technical service or quality, which can resolve application, documentation and single-lot issues without a development project.

Safety overrides those three conditions. A complaint that reports injury, fire, a hazard missing from the safety data sheet or a regulatory nonconformity goes to the product safety or regulatory owner first, whether or not it repeats. In the EU, suppliers must update a safety data sheet "without delay" when new information on hazards becomes available (European Union REACH, Article 31, 2026). In the US, new significant hazard information must be added to the safety data sheet within three months (OSHA 29 CFR 1910.1200(g)(5), 2024), and under section 8(e) of the Toxic Substances Control Act (TSCA) a manufacturer, processor or distributor must "immediately inform" EPA of information that reasonably supports a conclusion of substantial risk (15 U.S.C. 2607(e), 2026).

ISO 10002:2018 lists "analysing and evaluating complaints in order to improve the quality of products and services" among the aspects of complaints handling it addresses (ISO, 2018). R&D is the right place for that improvement only when the product itself has to change.

How do you group repeat failures from customer complaints before deciding what goes to R&D?

Group repeat failures from customer complaints by failure mode first, then by product grade and lot, and only then by customer, because R&D acts on a failure mechanism, not on an account. Two complaints worded as "poor adhesion" and "coating lifting at the edge" may be one failure mode; two complaints of "foaming" from different plants may be two. Code each complaint with a short failure mode term, the product and grade, the lot number, the application, the date of use and the customer site, so different customers' wording lands in the same group.

Then fix a time window and count distinct sites and lots, not complaint tickets. A customer who calls five times about one tank is one site with one event; three sites reporting the same failure mode on different lots is a pattern. Keep complaints that were closed with a workaround in the count, because a workaround that keeps returning is a repeat failure the product may be causing.

A complaint group is ready for a routing decision when it has a clear failure mode, the lots involved, the application conditions at each site and any retained-sample results. Groups that never reach that point usually stall between people, which is the subject of finding where technical support cases get stuck, so check that before blaming the product.

How do you tell a product cause from application or use conditions in a customer complaint?

A customer complaint has a product cause when the failure follows the lot or the formulation across sites, and a use-condition cause when it follows one site, one application or one change at the customer. Compare what is affected with what is not: the same lot at other customers, other lots at the same customer, and the retained sample of the complaint lot tested against its certificate of analysis and specification.

The table below decides which way the evidence points for each check.

The second row carries the most weight. A retained sample that meets its specification but still fails under normal use shows that the specification no longer covers the customer's need, and that is an R&D question even though no lot is out of specification. When the checks split, for example a clean retained sample but the same failure at two sites, record the group as unresolved and collect the missing application data before routing it.

How do you rank customer complaint groups by impact and frequency?

Rank customer complaint groups by the severity of their worst effect first, then by how often they occur across sites, and use the raw number of complaints only to break ties. That order borrows from the AIAG and VDA FMEA handbook, which replaced the risk priority number with an action priority table in 2019 (Durivage, 2020). The action priority method was "created to give more emphasis on Severity first, then Occurrence, then Detection" (Anackovski et al., 2021).

A risk priority number multiplies the three ratings into a score from 1 to 1,000, and because it gives them equal weight, very different combinations of severity, occurrence and detection can score alike (Anackovski et al., 2021). A complaint list sorted by volume has the same flaw. Ten complaints about a slight color shift can outrank one report of a seized bearing, an illustrative case, although the seized bearing may stop a customer's production line.

IEC 60812:2018 describes criticality ranking in failure analysis as one that "involves at least the severity of consequences" (IEC, 2018). For complaint groups, a practical severity scale runs from safety or regulatory effects, through customer line stops, lost batches and equipment damage, then performance below technical data sheet claims, down to appearance, handling and packaging issues; this scale is illustrative, not taken from a standard. Within each severity class, a group seen at more sites or on more lots ranks higher.

Customer complaint routing to R&D by pattern

Customer complaint routing to R&D depends on the pattern a complaint group shows, and five patterns cover the usual cases. The table below decides the route and the priority for each pattern; the priority numbers are an illustrative order that follows the severity-first ranking, not values from a standard.

The second row is the core R&D case: when the same failure appears at several customers who used the product within its technical data sheet range, the cause is likely in the product or its specification, and R&D should own the investigation. The fourth and fifth rows still feed R&D as data. A single unexplained complaint that is logged and coded can join a repeat group later, while one that is closed without a code cannot. The third row needs sales in the room, because a customer whose process has moved outside what the grade was designed for may need a different grade rather than a reformulated one, and only the account owner knows how many other customers are moving the same way.

Who should own each customer complaint group sent back to R&D?

Each customer complaint group sent back to R&D needs one named person in R&D who owns the investigation and one in technical service or sales who owns the affected customers, with a date for the next update. Splitting the roles keeps the investigation technical and the customer messages consistent: R&D reports findings and options, and the customer-facing owner decides what each customer hears and when.

Write the owner, the complaint group, the evidence collected, the next action and its due date on one record both sides can see. The record should also state the exit condition agreed at the start, such as "the failure no longer reproduces on lots made after the change" (illustrative), so closing the group is a check and not a judgment made months later.

Quality should own the list as a whole and review it on a fixed cycle, because owners change and groups stall. In PJR's summary of the ISO 9001:2026 revision, a note to clause 10.2.1 clarifies that customer complaints remain a potential, not mandatory, input to corrective action (PJR, 2026). The decision to escalate is therefore the organization's own and needs a written rule. Lubinpla's technical support performance analysis finds repeat failures and bottlenecks, builds improvement priorities by owner and keeps them as a PDF.

Common mistakes when sending customer complaints to R&D

The most common mistake when sending customer complaints to R&D is sending them one at a time, so R&D sees single events without the lot, application and site data that would show a pattern. Five other mistakes recur:

1. Ranking by complaint count, which buries a rare failure with a severe effect under frequent minor ones.

2. Sending application problems to R&D, which spends development time on dosage, contamination or storage issues that technical service can correct at the site.

3. Closing complaints with a workaround and dropping them from the count, which hides a repeat failure.

4. Holding a safety-related complaint in the R&D queue, when duties to update the safety data sheet or inform an authority may already apply under REACH, OSHA or TSCA.

5. Assigning a complaint group to a department rather than a person, so no one reports when it stalls.

These mistakes share one fix: route by a written rule, record the evidence with each complaint, and keep each group open until its exit condition is met. A supplier that records the lot, the application conditions and the retained-sample result for every complaint can apply the routing table above without a meeting for each case.