Complaints arrive by web form, by phone, by letter, through a regulator's portal, and occasionally as a public review that somebody in marketing forwards on. Recording them is not usually where the process fails. The failure is narrower and more expensive: a specific complaint, received on a specific date, where nobody can now say who owns it, what the complainant was told, or whether the deadline for a final response has already passed.
That is the problem complaint management software is bought to solve, and it is why feature lists are a poor way to compare products in this category. Every product will record a complaint. The question is whether it can prove three timestamps, name one owner, and produce a report that somebody would be willing to hand to a regulator or a board.
The category contains three different products
Searching for complaint management software returns three kinds of tool, sold to three kinds of buyer, at prices that differ by more than an order of magnitude.
The first is the regulatory complaint module, usually part of a wider governance, risk and compliance suite. These are built for banks, credit unions, insurers and manufacturers, and their organising idea is the regulatory clock and the report that goes to a risk committee. Root cause coding, trend analysis across products, and evidence for an examination are the point. Most vendors in this tier sell by quote. Quantivate's complaint management page, for instance, lists no price and points visitors to a demo request.
The second is the help desk or service platform with a complaints workflow laid over it. Zendesk, Freshdesk and similar tools bring queues, assignment, response targets and reporting that were designed for support volume. They are strong on the mechanics of answering and weaker on the compliance artefacts, which usually have to be built out of custom fields.
The third is the general form tool with response management: a form for the intake, an owner and a status on every submission, replies sent from the record, and an export. This tier does not attempt regulatory reporting. It solves the ownership and visibility problem, which for many organisations is the whole of the problem.
Choosing between them is mostly a question of whether a regulator is watching, and what it has told the organisation to do.
The deadline is the requirement
Two published regimes show what "on time" means in practice, and both are worth reading before writing a requirements list.
In the United Kingdom, the Financial Conduct Authority's complaints time limit rules require a respondent to send a prompt written acknowledgement on receipt of a complaint, telling the complainant that the complaint has been received and is being dealt with. For most complaints, a written response is due by the end of eight weeks after receipt. For payment services and electronic money complaints the clock is much tighter: a final response within 15 business days, or, in exceptional circumstances, a holding response within 15 business days and a final response within 35 business days. That section of the handbook was last updated on 1 June 2026.
In the United States, the Consumer Financial Protection Bureau states that companies generally respond in 15 days to complaints routed through its portal, and that in some cases a company will report that a response is in progress and provide a final response in 60 days.
The shape of both regimes is identical even though the numbers differ. There is a received date, an acknowledgement, and a final response, and each of the three has to be evidenced with a date. Any tool under consideration should be able to produce those three dates for any complaint from the last three years without somebody reconstructing them from a mailbox.
That leads to a concrete test for a demo. Ask the vendor to show the list of complaints where the acknowledgement was sent but the final response has not been, sorted by how long they have been open. If that list takes more than one click to produce, the deadline is not really being tracked.
Somebody has to decide it is a complaint
The clock starts when a complaint is received, which means the moment of classification is the moment the obligation attaches. It is also the step most implementations skip.
Complaints do not arrive labelled. They arrive as an email that begins with a question and ends with an accusation, as a support ticket that has been reopened four times, or as a survey response with one line of prose that matters more than the score. Somebody has to look at each of those and decide. Leaving that decision to whoever happens to open the message produces two failures at once: genuine complaints handled as queries, with no clock and no record, and ordinary queries escalated into the complaints process, which inflates the numbers and buries the real cases.
Three things make classification reliable. The first is a written definition that fits the organisation's regime, usually one sentence about an expression of dissatisfaction where a response is expected. The second is a single named role that applies it, rather than a shared responsibility. The third is a one-way door: anything classified as a complaint stays a complaint, and reclassification requires a note explaining why, because the ability to quietly declassify is the ability to make the numbers say anything.
The mechanics are easy once the decision is explicit. A dedicated complaints form for people who already know they are complaining, a way to convert an incoming message into a complaint record while keeping the original text, and a status list short enough that the conversion does not require training. What cannot be automated is the judgement, and no software should be bought on the promise that it will make that judgement instead.
The records a complaint file has to carry
Six fields do most of the work, and their absence is what makes a complaint log useless six months later.
The received date and the channel. The date starts the clock, and the channel is what reveals that the phone queue is generating three times the complaints of the web form.
One named owner. Not a team, not a queue. Shared ownership of a deadline is the most reliable way to miss it.
A copy of what was sent to the complainant, kept on the record. Not a note saying a letter went out. The text, with its timestamp. This is the single field most often missing, because replies get sent from a personal mailbox and never come back.
The outcome and the reason for it, chosen from a fixed list. Free-text outcomes cannot be counted, and counting is what turns a log into a report.
A root cause, also from a fixed list. The distinction between outcome and root cause matters: "complaint upheld, goodwill payment made" is an outcome, and "billing statement wording unclear" is a root cause. Only the second one tells anyone what to fix.
Whether redress was offered, and what it was. This is the field that finance and audit will ask for first.
Where the categories genuinely differ
| Requirement | Regulatory module | Help desk platform | Form tool with response management |
|---|---|---|---|
| Deadline tracking with breach alerting | Built in | Available as response targets on paid tiers | Not built in |
| Root cause coding and trend reporting | Built in | Custom fields plus a reporting build | Export and analyse elsewhere |
| Intake from several channels into one list | Usually | Usually | Form plus manual entry for calls and letters |
| One owner and one status per complaint | Yes | Yes | Yes |
| Reply sent from the record, copy retained | Varies | Yes | Yes |
| Audit history of every change | Yes | Yes | On higher tiers |
| Published price | Rarely | Usually | Usually |
| Working within a week of signing | Rarely | Sometimes | Usually |
The last two rows are the ones buyers underweight. A tool that is perfect in a specification and six months from going live does nothing about the complaint received yesterday.
Response targets are the row worth checking against a specific plan rather than a brochure. In Freshdesk, multiple response policies begin on the Pro plan, listed at $55 per agent per month billed annually, with Growth at $19 and Enterprise at $89 on the same basis. In Zendesk, response policies require Suite Growth or above, or Support Professional or above, and choosing between business hours and calendar hours per priority is an Enterprise-only setting. Since most complaint deadlines are expressed in calendar days or business days set by a regulator rather than by the team's shift pattern, that setting is not a detail.
What pricing hides
Per-agent pricing was designed for support teams where a fixed group of people work the queue all day. Complaints rarely work that way. A complaint is often handled by a branch manager who sees two a month, reviewed by a compliance officer, and signed off by somebody senior. Counted as agents, that is an expensive way to handle twenty complaints a quarter.
Three questions expose the real cost. How many people need to write, as opposed to read? Is there a view-only role, and is it free or discounted? And does the price change when complaint volume rises, or only when headcount does?
Volume-based pricing deserves particular care in this category, because it creates an incentive to keep complaints out of the system. Any pricing model that makes recording a complaint cost money works against the purpose of buying the software at all. Published, seat-based pricing with unlimited records avoids that problem, which is worth verifying on the pricing page of any candidate rather than in a sales call.
What goes wrong after the purchase
The second channel never arrives. The web form feeds the system and the phone does not, so the log shows a flattering number and the aged cases are invisible. The fix is a rule that whoever takes the call fills in the same form on the caller's behalf, and the intake form needs a short internal version to make that realistic.
The acknowledgement is automated and the final response is not. Automatic acknowledgement is easy and satisfies the first obligation, which is exactly why it creates false comfort. The second deadline is the one that needs a visible list.
Categories are invented per complaint. Six months of free-text reasons cannot be reported on. Fix the list before go-live, keep it under fifteen entries, and add to it deliberately.
Nobody owns the aged list. The single most useful habit in complaint handling is one person, on a named day each week, reading the list of complaints sorted oldest first. Software makes that list easy to produce. It cannot make somebody read it. Which use cases a tool was designed for is a fair guide to how easily that list falls out of it.
What to change first
Produce one list this week: every open complaint, oldest first, with an owner's name and the date the last message went out. If that list cannot be produced in a minute, the gap is ownership and visibility rather than compliance software, and a form with stages, owners and a message history will close it, which is what the Halict sample shows. If the list exists and the problem is root cause reporting to a committee, the regulatory module is the right purchase.
Q1. Is a help desk enough for handling complaints, or is dedicated compliance software needed?
A help desk covers intake, ownership, replies and response targets, which is most of the day-to-day work. Dedicated compliance software is worth it when a regulator or a board requires root cause coding, trend analysis across products and evidence for an examination. Organisations without that reporting duty usually find the compliance tier is paying for outputs nobody reads.
Q2. What deadlines apply to complaints?
That depends on the sector and the country. Financial firms regulated in the United Kingdom must send a prompt written acknowledgement and, for most complaints, a written response within eight weeks, with 15 business days for payment services and e-money complaints. Complaints routed through the CFPB portal in the United States generally expect a response in 15 days. Check the regime that applies rather than adopting a general target.
Q3. Should complaints be kept separate from ordinary support tickets?
Keeping them in one system but separating them by form or type is usually better than two systems. One system means one aged list and no complaint hiding in the wrong queue. Separation by type is what allows the deadline rules, the reason codes and the reporting to apply only to complaints.
Q4. What is the difference between an outcome and a root cause?
The outcome is what happened to the complainant, such as upheld with a refund, or not upheld with an explanation. The root cause is what in the organisation produced the complaint, such as unclear wording on a statement or a delivery partner missing a window. Reports built on outcomes measure the complaints team. Reports built on root causes tell the business what to fix.
Q5. How many reason codes should a complaint log have?
Few enough that everybody uses them consistently, which in practice means somewhere between eight and fifteen. A longer list produces inconsistent coding, and inconsistent coding produces a report nobody trusts. Review the list once a year and add a code only when a genuine pattern does not fit anywhere.