Supplier Quality Feedback Loop: A Defect Record That Changes the Next Run

The same fault turning up twice is a different problem from the same fault turning up once. A bail that sits crooked on a handful of pendants in one delivery is a bench slip. The identical crooked bail in the following delivery says the first conversation changed nothing, and that nothing about the way the piece is made has moved. A supplier quality feedback loop is what turns the first observation into a change before the second delivery is packed.

Below we set out how to record a fault so it can be counted, how to ask for a correction in terms a workshop can act on, and how to confirm at the next run that the correction actually happened.

A complaint is not a record

Most feedback reaches a supplier as a message about one delivery, written while somebody is annoyed, and it dies there. It cannot be counted, compared or searched. Six months later nobody can say whether a fault is new or the fourth appearance of an old one.

A record is different because it is structured, dated and kept in one place. Its purpose is not to document your displeasure. Its purpose is to let you look at two years of deliveries and see a pattern that no single delivery could show.

What a single entry contains

Keep every entry to the same fields, so entries can be sorted rather than read.

• Date received and batch reference.
• Model code and specification revision the run was built to.
• Fault code and a one-line description in plain language.
• Number of pieces affected and number inspected.
• Where on the piece the fault sits.
• The outcome chosen: accepted, reworked, returned.
• A link to the photographs of that fault.

The pair of counts — affected and inspected — is what makes entries comparable. Three faulty pieces out of a sample of ten and three out of a full check are entirely different events, and without both numbers the log flattens them into the same line.

Coding faults so they can be counted

Free text cannot be totalled. Build a short list of fault codes and use only those, adding a new code deliberately rather than inventing a description each time. Keep the list short enough that anyone on your side can hold it in their head.

Group the codes by where they come from: forming, joining, finishing, setting, marking, sizing, packing. That grouping is what lets you tell a plating problem from a polishing problem at a glance. Before a mark enters the log at all, decide whether it is a fault or an ordinary trace of hand work, a distinction set out in the guide to which marks are not defects.

Reading the log rather than filing it

Look at the log on a fixed rhythm, not when something goes wrong. Sort by fault code and count appearances across deliveries. Then sort by model code and do the same.

Three patterns matter. A fault code that appears across many models points at a process step. A fault that appears on one model regardless of who made it points at the design of that piece. A fault that appears only after a change — a new mould, a different chain source, a gap between orders — points at that change and usually explains itself.

Asking for a correction that can be acted on

A corrective action request is a short document, and it asks for three things rather than one. What caused this. What will be done to the pieces already made. What will be different in the next run so it does not recur.

Give the workshop the evidence with it: the counts, the photographs, the specification line, the batch references where the fault appeared. Then give a date for the reply and leave the technical solution to the bench. Prescribing the fix yourself removes the responsibility for whether it works, and a workshop that knows its own process will usually propose something better than you would.

Separating a bench slip from a design problem

Some faults are not the workshop’s to fix. A letter connection that keeps breaking, a prong that keeps catching, a wall so thin it distorts in finishing — these follow from the drawing, and a different supplier would produce them too. Where a personalised piece fails is largely a design question, mapped in the guide to the breaking points in personalised jewelry.

The log is what tells the two apart. A fault that persists after a genuine process change, across different runs and different periods, has stopped being a production issue. At that point the correct action is a revision to the specification, and the entry should say so rather than continuing to record a complaint against the bench.

Verifying the fix on the next run

A closed corrective action means nothing until the next batch is in your hands. Treat that batch as a re-inspection rather than a routine delivery.

• Ask for photographs of the first finished pieces before the rest of the run is completed.
• Check those pieces specifically against the fault code that was raised.
• Raise your sampling level on the affected model for this delivery.
• Record the result in the log against the original entry, whether it passed or not.

Closing the entry with a verified result is what makes the whole record trustworthy. A log full of open entries teaches everyone that raising something changes nothing. Our production process page shows the stages a correction has to land in to survive into the next run.

What the log says about the partnership

Over several orders the record answers a question no sales conversation can. Do faults raised once come back? Does the workshop explain causes or only apologise? Do new faults appear as old ones close, or does the overall picture settle?

That evidence is the most reliable basis for deciding whether to grow a relationship, and it feeds directly into how you assess a production partner after the first orders. It is built from entries nobody enjoyed writing.

Give every fault you raise a closing date on the next delivery rather than on the reply. Write the entry, send the request, then diary a check against that exact fault code when the following batch lands. A loop that ends with the supplier’s answer is correspondence; a loop that ends with a piece in your hand, checked against the fault that started it, is the only version that changes what the next run looks like.