Yes, for the evidence work. An AI agent can read every complaint, group them by the failure behind them, trace each group back to a process, system change or policy, and test which explanation the data supports. Naming the root cause, deciding who else was harmed and choosing the fix stay with a person.
What does root cause analysis need that complaint handling does not?
Handling a complaint resolves one customer's problem. Root cause analysis asks why the same problem keeps arriving and whether customers who never complained were hit by it too. That second question is where the regulatory weight sits, because it can turn a handful of complaints into a remediation exercise across a whole product.
The work is mostly reading and linking. Someone has to read hundreds of free-text complaints, notice that "charged twice", "payment taken early" and "overdraft fee I didn't expect" may be one fault, and then find the change that caused it. Agents are good at that reading. They are not entitled to the conclusion, because the conclusion commits the firm to redress, reporting and change. For the stages of the end-to-end process, see what complaint handling is.
What may the agent prepare, and what stays with a person?
| Task | The agent | A person |
|---|---|---|
| Classification | Codes each complaint against your complaint classification matrix and flags ones that fit no code | Changes to the matrix itself |
| Clustering | Groups complaints by underlying failure, not by the words used | Agrees which clusters are real |
| Tracing | Lines up clusters against release notes, incidents, policy changes and staff rota | Decides which explanation holds |
| Testing | Checks whether the same pattern appears in accounts with no complaint | Decides the scope of affected customers |
| Drafting | Writes the root cause summary with evidence and gaps | Signs the finding |
| Follow-up | Tracks remediation actions and reopens the cluster if complaints continue | Owns the fix and any redress |
The tracing step is where most of the value is. An agent can hold a change log, an incident register and a complaints spreadsheet in view at once and point to the date the pattern started. A person then judges whether the timing is cause or coincidence, much as an analyst does when an agent prepares a variance analysis and someone still has to explain the number.
What does this look like on a real cluster?
Take a mid-sized building society. Over six weeks, complaints about direct debits rise from a few a month to around forty. The handlers resolve each one: a refund here, an apology there.
The agent reads all forty, plus the eighty from the previous quarter. It finds that thirty-one share a pattern: a payment collected one working day early after a bank holiday. It checks the release log and finds a change to the collection calendar deployed two days before the first complaint. It then queries the collection records and finds roughly 2,000 accounts collected early in the same window, most of whom never complained.
The draft finding states all of this, lists the nine complaints that do not fit, and notes that tone alone is a poor signal here: several of the angriest complaints were about something else. That is why sentiment analysis is an input to clustering, not a method for it.
The head of customer outcomes reads the draft, agrees the cause, and decides to refund charges for all 2,000 accounts, not just the complainants. That decision is hers. The agent drafts the customer letters and tracks the refunds.
What controls keep the analysis honest?
- Evidence linked to every claim. Each statement in the draft points to the complaints, records or log entries behind it. A cluster with no traceable evidence is not reported as a finding.
- The misfits are recorded. Complaints that do not fit any cluster are listed, not dropped. A root cause that explains most complaints can hide a second, smaller one.
- No contact with customers about the cause. The agent does not tell a complainant that a fault has been found until a person has agreed the finding.
- Deadlines are separate. Root cause work must not slow individual responses. Keep the agent that tracks complaint deadlines on its own clock.
- A sample is re-read by a person. Someone checks a sample of the agent's clustering each cycle, including complaints it placed in no cluster.
The wider principle, that a compliance agent prepares and a person decides, is set out in AI compliance agents: second line, never the last word.
Where Pryme fits
In Pryme, reading complaints, querying records and drafting findings are separate capabilities, each certified on your own past complaints before the agent uses it. Every fact in a draft arrives stamped with where it came from, so a reviewer can tell a ledger record from a customer's account of events. Agreeing the root cause is outside the agent's role scope.
Questions people ask
Can the agent decide that a cluster is too small to matter?
No. It can report the size and the pattern. Whether a small cluster signals a wider problem is a judgement about risk, and it belongs to the person who owns the finding.
How far back should the agent look?
Far enough to see the pattern start. In practice that means at least the quarter before the rise, and any period covering a related system or policy change.
Can the same agent handle complaints and analyse them?
It can, but separating the roles helps. An agent that drafted the responses has an interest in the existing explanation, and a separate analysis brief makes it easier to see when that explanation is wrong.