Start with the definition, not the channel. The agent reads every customer contact and proposes whether it meets your regulator's definition of a complaint, which reportable category it falls into, its product and cause, and any vulnerability indicators, each with the words that support it. A complaint handler confirms the classification, and the agent never downgrades one on its own.
What is the process, and who owns it?
Most regulators that supervise retail financial services define what counts as a complaint, usually broadly: an expression of dissatisfaction, however made, about the service or product, whether or not the customer uses the word. They also set categories for reporting, and often treat complaints resolved quickly differently from those that need a formal final response. The classification decides which clock starts, which letter is owed and what appears in regulatory returns.
The complaints function owns classification, with a complaints manager accountable for the policy and handlers making the day-to-day calls. The hardest cases are the ones that do not look like complaints: a service request with a sharp sentence in it, a cancellation that mentions mis-selling, a chat message that ends "this is ridiculous".
How does the agent prepare each classification?
- Agent, depth 1: reads every inbound contact. Calls (from transcripts), emails, chats, letters and social messages, not only those already tagged as complaints.
- Agent, depth 1: tests against the definition. It quotes the words that indicate dissatisfaction and the definition clause they meet, or states that none were found.
- Agent, depth 2: proposes the labels. Complaint or not; product; reportable category; root cause; whether it can be resolved quickly or needs a formal response; vulnerability indicators; any mention of legal action or the ombudsman.
- Person, complaint handler: confirms or changes each label. Every change is recorded with a reason from a fixed list.
- Agent, depth 3, within bounds: starts the clock and opens the case once the handler confirms, applying the timelines in your procedure.
- Person, complaints manager: reviews a sample of contacts the agent judged not to be complaints, every week.
- Agent, depth 1: prepares the reporting extract for the period, reconciled to case records. A person signs off the return.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Intake | Reads all contacts | 1 | None |
| Definition test | Quotes the triggering words | 1 | Borderline calls |
| Labels | Proposes category, cause, flags | 2 | Confirming every label |
| Case opening | Opens case and starts the clock | 3 | Handler confirmation first |
| Negative sample | Lists non-complaints | 1 | Weekly sample review |
| Reporting | Builds the extract | 1 | Signing off the return |
Which controls apply, and what evidence does each leave?
Asymmetric authority. The agent may propose that a contact is a complaint, and a handler may agree. A proposal that something is not a complaint is always checked by sampling. Under-classification is the failure supervisors look for, because it hides harm. Evidence: the sample, with results.
Quoted reasons. Each label carries the customer's words that support it. Evidence: a reviewer can see why a case was classified as it was without reading the whole transcript.
Fixed change reasons. Handlers changing a label choose from a short list. Evidence: data on where the agent and handlers disagree, which feeds back into its brief.
Versioned definitions. The definitions and category lists the agent uses come from the current procedure, with a version. If the regulator changes its categories, the change goes through the same process as any other rule change.
Clock rules applied, not invented. At depth 3 the agent opens the case and sets due dates, but only from the timelines written in your procedure, and only after a handler has confirmed the classification. If the classification later changes, the dates are recalculated and both versions kept. Evidence: each case shows when its clock started, on whose confirmation, and under which procedure version.
What should you measure?
- Agreement between agent and handler, by label. Root cause and vulnerability usually disagree most.
- Complaints found in the negative sample, the measure that matters most.
- Time from contact to confirmed classification, which drives whether deadlines are met.
- Reclassifications after case opening, especially from quick resolution to formal response.
- Differences between the reporting extract and case records found at sign-off.
Where does it usually go wrong?
Classifying by channel. Only contacts sent to the complaints inbox get assessed. The agent's main value is reading everything else.
One complaint, several issues. A customer complains about a fee and about how they were treated on the phone. These may need separate categories and causes. The agent should list every issue it finds rather than picking the loudest.
Vulnerability treated as a label, not a trigger. Flagging vulnerability is pointless unless it changes how the case is handled. Connect the flag to your vulnerable customer procedure.
Ombudsman mentions missed. A customer who says they will go to the ombudsman needs to know their rights and the timing. See handling complaints referred to an ombudsman.
Agent behaviour hidden in categories. If an agent caused the complaint, record that. A category for agent-involved complaints lets you see patterns that a generic "service" label would bury, and gives an inspector a clear answer; preparing that answer is covered in whether an agent can help prepare for a regulatory inspection.
Classification is easier when the definitions themselves are kept current; the argument in agents for regulatory change applies here too. The overall stance on compliance agents is set out in AI compliance agents.
Questions people ask
Can the agent decide that a contact is not a complaint?
It can propose that, but only sampling makes it safe. Set the sample size by volume and risk, and increase it whenever the sample finds a missed complaint.
Is classifying complaints a high-risk use of AI?
The classification itself rarely decides a customer's rights, but it determines how they are treated and what the firm reports. Rate it as you would any agent capability, using the approach in how to classify AI agents by risk.
Does the agent need the whole customer history?
It needs the contact and enough history to spot repeat issues. Access to full account data is rarely needed for classification and should not be granted by default.