
Voice of Customer
Part of Complaint journey design
Identifying repeated failures behind individual complaints
Cluster complaints by failure mechanism and check whether one process is causing multiple customer problems.
A customer complaint can be the first sign of a failure affecting many people. A life insurer identified an issue after a complaint, then found more breaches in a review.
Set a 30-day baseline for complaint volume and repeats within a window. Test any apparent pattern against process evidence.
Code the problem, not the customer
Tag the observable failed step—wrong stock information, missed handover, unclear policy or failed refund—not the customer. Record the requested remedy separately from the actual outcome. Check full records: a broad “delivery issue” label may hide different causes.
Frame the signal as a specific, observable problem, such as customers receiving a duplicate charge on the first bill after a plan change. Take a stratified sample that includes resolved and unresolved cases.
Compare case records and call notes with event logs and policy, then map the process the complaint travels through. This shows where separate cases share a step or handover.
Use an Ishikawa diagram to organise cause hypotheses under People, Process, Policy, Platform and Data, then test the causal chain with Five Whys. Support each “why” with evidence, not opinion, and stop at a cause the business can change.
If repeated “where is my parcel?” contacts coincide with a supplier creating labels days before handover, treat dispatch visibility as a hypothesis to verify—not a conclusion from complaint volume. Check unaffected orders too, so one vocal group does not define the process.
During a legacy-product migration, a life insurer reported 10,105 breaches of the Life Insurance Code of Practice; 4,686 involved delays by a third party distributing annual notices. A customer complaint first surfaced an issue, and a review found additional breaches. The Life Insurance Code Compliance Committee cited weaknesses in systems, compliance oversight and assurance, and issued a formal warning.
The committee required the insurer to show that its governance, controls and assurance could prevent repeats. Correcting individual notices alone did not address the underlying weaknesses.
Give the underlying issue an owner outside the support queue, a proposed change and a control to prevent recurrence. Set a way to verify that the change worked, and keep the individual case status separate from the systemic issue status.
Track recurrence after the change and review whether it creates a new failure mode. Compare repeats with the baseline rather than relying on an arbitrary threshold.
business.gov.au advises businesses to keep complaint records and use them to improve processes and prevent problems affecting more customers. Know obligations under the Australian Consumer Law and the relevant state or territory consumer protection agency; examples include NSW Fair Trading and Consumer Affairs Victoria. ISO 10002 sets a baseline for complaint handling and continual improvement.
Key Statistics on Customer Complaints and Systemic Failures
- 10,105Total breaches identified in insurer review
- 4,686Breaches linked to third-party delays in annual notices
Steps to Identify Repeated Failures Behind Individual Complaints
- Tag the observable failure (e.g., duplicate charge, missed handover)
- Compare case records with policy data, event logs and call notes
- Map the customer journey to identify shared process steps
- Use Ishikawa diagram to categorise root causesPeople, Process, Policy, Platform, Data
- Apply Five Whys method with evidence-based answers
- Assign ownership and control to prevent recurrence
Customer Complaint Handling: Individual vs. Systemic Approach
- Focus
- Problem (observable failure) vs. Customer (blame or behaviour)
- Data Use
- Full records and stratified sampling vs. isolated cases
- Outcome
- Systemic fixes and prevention vs. individual resolution



