Audits, checklists and mistakes: the desk work that keeps product safety honest

A product safety audit is a structured check of whether the business's safety work matches its safety claims. It examines a sample of product files, traces a product from supplier to buyer, tests whether complaints were reviewed, and asks whether the records prove the work or merely assert it.

An audit differs from a routine check in its independence and its scope. Routine checks confirm a single task was done, such as a label printed correctly. An audit asks whether the system that produces labels, tests, and complaint reviews works as a whole, and whether its failures would be caught. That wider question is what makes an audit valuable, and what makes it uncomfortable, because it can reveal that several correct looking tasks hide a broken connection between them.

Checklists help by externalising memory, standardising routine work, and making omissions visible. A pre launch checklist that requires a risk assessment, a test record, a label proof, and a batch code before dispatch will prevent launches that skip one of those steps, provided the checklist is enforced.

The balance lies in design. A good checklist is short, specific, and tied to evidence: each box names the document or result that proves it, not merely the intention. A bad checklist is long, vague, and tied to nothing, so ticking it feels like work while proving nothing. Illustration: a seller replaces a forty item generic checklist with a twelve item product specific one, each item naming its evidence, and finds launches both faster and better documented.

Recurring mistakes form a familiar set. Files that describe a model rather than a batch. Test reports filed without reading their scope. Labels approved from artwork rather than from production samples. Complaints logged as feedback rather than reviewed for safety. Supplier assurances filed as if they were test evidence. Traceability that stops at the warehouse door. Each mistake is understandable in isolation, and each becomes dangerous when repeated across a range, because a repeated mistake is a system fault, not a slip.

The audit's job is to find patterns, not just instances. One file with a missing test report is a gap to fill. Five files with missing test reports from the same supplier is a supplier control failure. Ten files with complaints never reviewed is a complaint system failure. Pattern finding turns an audit from a tidy up exercise into a management tool, because patterns point at the system change that fixes many files at once.

Audit rhythm should match risk and change. A business launching new products frequently, changing suppliers, or selling in high risk categories needs more frequent audits than a stable business with a narrow range. A sensible rhythm for many small sellers is a full file audit for a sample of products periodically, plus a focused audit whenever something changes, such as a new supplier, a new channel, or a complaint pattern. The rhythm should be written into a calendar, not left to good intentions.

Audits should also follow incidents. A complaint that reveals a fault, a returned product, or an authority contact should trigger a focused audit of similar products, because the incident may reveal a pattern the routine audit missed. An audit programme that never responds to incidents is a programme that learns slowly, while one that audits only after incidents never learns in advance.

Findings change things when they become actions with owners and dates. A finding that reads test reports not filed should become a named person filing the reports by a date, plus a routine change that files future reports at receipt. A finding without an owner and a date will be rediscovered at the next audit, unchanged, and repeated findings erode faith in auditing itself. The team will stop reporting gaps honestly if gaps are never acted on.

Findings should also be graded by risk, so the team fixes the highest risk gaps first. A missing warning on a childrens product outranks a misfiled document on a low risk product, and a graded list lets a small team work in the right order. Grading is not an excuse to ignore low risk findings; it is a sequence that ensures the serious ones are fixed before the next product ships.

Audits work where findings are treated as system information rather than personal criticism. A team that fears blame will hide gaps, tidy files before an audit, and report only good news, which defeats the audit's purpose. A team that is thanked for surfacing gaps, and that sees gaps fixed rather than punished, will report honestly, and honest reporting is the raw material of safety improvement.

Leadership sets that culture by its response to the first uncomfortable finding. An owner who reacts to a serious gap by fixing the system and thanking the finder teaches the team that audits are safe. An owner who reacts by blaming the finder teaches the opposite lesson, and the lesson will last longer than any checklist. Culture, in auditing as elsewhere, is what leaders do when findings are bad, not what policies say when findings are good.