An internal product safety complaints register that a small team can actually keep

A complaints register is often mistaken for a filing cabinet: a place where complaints are stored after they are handled, to be produced if an authority asks. Its real purpose is different: it is a pattern finding tool that lets a seller see, across weeks and channels, whether reports share a product, a batch, a part or a failure description. A register that is only filed, and never grouped or reviewed, fulfils the filing purpose while failing the safety purpose, since a pattern hidden in ungrouped entries will never be noticed until it becomes an incident or a recall. Design the register for grouping and review from the start, and filing will follow naturally.

Useful register fields include the date, the product and variant, the batch or model marking where known, the source channel, the failure description in customer words, the customer action or remedy, the safety decision, and the follow up date. Avoid fields that handlers cannot complete reliably, such as technical cause at intake, since forcing a cause guess at logging time creates false precision that later reviewers may mistake for a finding. Cause should be added later, after investigation, in a separate column, so intake data and investigation findings remain distinct and the register shows both what was reported and what was concluded.

Also include a field for product preservation: was the product kept, photographed, returned or discarded, and where is it now. That field matters because a pattern that needs testing cannot be tested if the products were all refunded and discarded. Handlers who know that preservation is a register field will ask for it, while handlers who see no such field will not think to ask. A register teaches its users what matters, through its columns, as much as through any training.

Review the register weekly for new entries, grouping by product, batch and failure words, and record decisions for each group, including watch, investigate, contact supplier, pause sales or no action with reasons. Maintain the register by entering reports promptly, ideally the same day, and by closing entries only when follow up is complete, not when a refund is issued. A register with many open entries and no decisions is a warning that review is not happening; a register with decisions recorded and follow up dates met is evidence that monitoring is working, even when its entries are few.

Illustration: a shop selling heaters kept a register in a shared spreadsheet, with a weekly review every Monday, and discovered in its second month that three heater returns mentioning a smell shared a batch and a heating element supplier. The shop contacted the supplier, paused that batch, and recorded the decision in the register. The shop story is illustrative, and the lesson is that a simple register, reviewed weekly, finds patterns that a sophisticated system, reviewed rarely, would miss, because review frequency matters more than software sophistication.

A register survives staff changes when it is documented, accessible and simple: a short page explaining its columns, its review rhythm and its escalation rule, stored with the register itself, lets a new handler start without training from a predecessor who has left. It survives growth when its product organisation scales: as new products are added, they gain their own register sections, rather than being mixed into a single long list where patterns hide. Growth should add structure, not length, and the register owner should review its structure periodically as the range expands.

Access control matters too: the register should be accessible to handlers, reviewers and decision makers, but personal customer details should be limited to what is needed for follow up, and the register should not become a general customer database. Keeping the register focused on safety, with minimal personal data, makes it easier to share with a supplier, a retailer or an authority when a pattern needs joint investigation, since sharing does not then expose unrelated customer information.

This month, check your register against four questions: are entries grouped by product and batch, are failure words recorded exactly, are decisions recorded with follow up dates, and is the register reviewed weekly. Fix the weakest answer first, whether it is a missing column, a review rhythm or a decision habit, and record the fix. A register checked this way, month by month, becomes a reliable pattern tool, and a team that trusts its register will use it, which is the ultimate test of any register design.

This week, start a register from scratch if you do not have one: create a spreadsheet with product, batch, date, source, failure words, action and decision columns, enter every safety report you can remember from the past month, and set a weekly review time. Do not wait for perfect software or a perfect template, since a simple register started this week and reviewed weekly will outperform a sophisticated system planned for months and never launched. After a month, review the register itself and adjust its columns to match the reports you actually receive, rather than the reports you imagined.