Part of our guide hub: Business software by industry
Most organisations that install a complaint system end up with a ticket graveyard: thousands of records, a closure rate that looks acceptable, and no idea what is actually going wrong. The system captured complaints and changed nothing.
The difference between a graveyard and a useful system is not the software. It is four decisions made at setup.
Why complaints are worth capturing properly
A complaint is the cheapest research a business can obtain. Someone has taken the trouble to tell you what is broken, for free, and for every person who complains there are many who simply left.
Handled individually, a complaint is a cost to resolve. Handled as data, a hundred complaints tell you which product, which branch, which process and which supplier is generating the problem. That second use is where the return is, and it is the one most systems never deliver.
The four decisions that make the data useful
1. A category list you can act on
The most common failure. Categories like “service issue”, “product issue” and “other” produce reports where forty percent is “other” and nothing is actionable.
Useful categories name a cause: wrong item shipped, delivery late, item damaged in transit, billing amount incorrect, staff behaviour, product defect within warranty. Each one points at a specific process with a specific owner.
Keep the list short, around twelve to twenty entries, and review it quarterly. If one category dominates, split it. If one is never used, remove it.
2. A required root cause field at closure
Categorisation at intake records what the customer said. A root cause recorded at closure records what was actually wrong, and they are frequently different.
Making this mandatory to close a ticket is the single highest value configuration decision in the whole system. Without it, the reporting describes symptoms.
3. One owner per complaint
Not a team, a person. Complaints assigned to a queue that everybody can see and nobody owns are the ones that age. Reassignment is fine; ambiguity is not.
4. Time targets with automatic escalation
First response within a defined time, resolution within another. When a target is breached, the ticket escalates to a named manager automatically rather than waiting to be noticed.
Escalation that depends on someone reviewing a list does not happen on busy days, which are exactly the days it is needed.
Intake: meet people where they are
In Pakistan the realistic channels are WhatsApp, phone, walk in, email and a web form, roughly in that order of volume for most consumer businesses.
A system that only accepts complaints through a portal will capture a small and unrepresentative fraction. Every channel needs to create a ticket, and for phone and walk in that means staff entering it, which means the entry form has to be quick enough that they will.
WhatsApp is usually the largest channel and the one most often left outside the system. Our note on WhatsApp automation covers connecting it properly, including the important rule that an angry customer should reach a person immediately rather than a menu.
What to measure
Five numbers, reviewed monthly:
- Volume by root cause. The report that drives fixes.
- Repeat complaints from the same customer. A strong churn signal and usually a sign the first resolution was cosmetic.
- Time to first response, which correlates with satisfaction more strongly than time to resolution.
- Reopened tickets. A closure rate with a high reopen rate is a closure rate that means nothing.
- Complaints by branch, product or supplier, normalised by volume so a large branch is not unfairly compared to a small one.
What not to measure as a target: tickets closed per agent. It reliably produces agents who close tickets rather than solve problems.
The organisational part
A complaint system only produces value if someone owns the loop back into operations. A monthly meeting where the top three root causes are assigned to owners with dates is what converts data into fewer complaints.
Without that meeting, the system is an efficient way to handle a constant volume of the same problems forever.
Regulatory and service contexts
For utilities, telecoms, financial services and public sector bodies, complaint handling is often a regulatory requirement with defined response times and audit obligations. In those cases the system also needs an immutable audit trail of who did what and when, and reporting in the format the regulator expects.
If that applies to you, confirm the audit trail cannot be edited before evaluating anything else.
Build or buy
Buy a helpdesk product for standard customer service. Custom becomes justified when complaints must flow into your own operational systems, when regulatory reporting has a specific format, or when the process spans several departments with different workflows.
See custom software versus off the shelf for the general threshold.
Frequently asked questions
What should a complaint management system include?
Multi channel intake, categorisation at intake, a mandatory root cause at closure, one named owner per ticket, time targets with automatic escalation, and reporting by root cause.
How do we stop it becoming a ticket graveyard?
Require a root cause to close, review the top causes monthly, and assign fixes to owners with dates. The reporting loop is what makes the system worth running.
Should complaints from WhatsApp go into the system?
Yes, and for most Pakistani consumer businesses it is the largest channel. Leaving it out means the data describes a minority of complaints.
What is a reasonable response time target?
Depends on the industry, but first response within a few working hours is a common commitment and it affects satisfaction more than resolution speed does.
Ezitech builds complaint, service and workflow management platforms, including for regulated environments. See our complaint management system or describe your process.