AI for Customer Support Operations in Banking: Complaints, Evidence and the Response Clock

A complaint rarely arrives labelled as one. It arrives as the fourth line of a call note, after the balance question has been answered: the customer mentioned they had raised this in branch months ago and nobody rang back. The adviser fixed the thing in front of them and moved on. Nothing in any system knows a clock should now be running.

The hard part of complaints work in a bank is not writing the reply. It is recognising that a work item exists at all, getting it on a proper footing before the deadline you are held to has half gone, and showing, case by case, that customers in the same position were treated alike.

The complaint nobody logged as one

Customers almost never use the word. They say they are disappointed, that they were told something different, that this is the third time they have called. Dissatisfaction about a product, a fee, a delay or the handling of a previous contact counts whether or not they ask for anything, and most of it lands in records built for something else.

The places worth reading are the adviser wrap note, the secure message thread, the branch appointment note, the servicing mailbox and the free text of cases closed as general queries. A model reading that text for markers can propose a record with the source passage attached. The strongest marker is not linguistic: the repeat contact about an issue a previous contact was supposed to have resolved, which you can find structurally.

Under-recording is the finding that hurts in a review: the file plainly shows a complaint and no record exists. Set the threshold to propose generously and let a person dismiss with a reason. Keep the dismissals, both as evidence the judgement was made and as the material you tune on.

Acknowledgement and the clock that starts without asking

The clock runs from when you received the complaint, not from when somebody created the record. If detection surfaces a case well after the call that contained it, the received date is the call, and the case opens already partly spent. Compute that date from the earliest supporting evidence and show the working.

Acknowledgement drafting is straightforward automation: case reference, named handler, what happens next, how to reach them. The queue matters more. Sort by time remaining against expected effort rather than age, flag cases with nothing substantive recorded since opening, and surface those waiting on evidence nobody chased. Breaching the response deadline you are held to is almost never a decision. It is a case nobody looked at.

What changes when the customer is in difficulty

Bereavement, serious illness, a recent loss of income, caring responsibilities, a sight or hearing impairment, someone who cannot follow the process: these change what a correct response is, not just its tone.

The channel changes, because a long letter is the wrong instrument for some customers. The pace changes, and whether someone phones before writing. Who handles it changes, since these cases belong with experienced people. So does whether servicing activity running in parallel should pause while the complaint is open, and whether the final response needs to be shorter, in larger type, or repeated by phone.

A model reading the file and the transcript can propose the flag and cite what prompted it, but it should never remove one. And the flag has to reach the systems where handling happens, not sit in a record nobody opens.

Building the file across systems that do not talk

The evidence for one complaint about a fee can sit in core banking transaction history, the pricing terms in force at the time, servicing notes in a separate platform, scanned correspondence, call recordings keyed by extension and timestamp rather than by customer, and a branch diary entry. Mortgage and loan servicing cases add a file that arrived from a prior servicer in their format, not yours.

This retrieval eats handler hours and suits automation. Pull everything touching that customer and product in the window, assemble a dated chronology, and mark what could not be found. Transcription makes recordings searchable, and finding the moment the customer was told the thing they say they were told is worth more than the transcript. Where a recording no longer exists because retention has passed, that belongs in the file as a stated fact, not a silence the letter writes around.

Root cause coding that is honest rather than convenient

Root cause is chosen at closure, by a tired handler, from a list somebody else designed, and it drifts to whatever sits near the top and offends nobody: customer misunderstanding, general administrative error. Those codes become the management information that decides what gets fixed, which is how a product defect survives while the complaints it generates are coded as service.

A model reading the narrative and the evidence can propose a code without the closing pressure, and allow more than one cause where there was more than one. The useful output is disagreement: the handler coded process error and the evidence reads as a pricing design problem. The disagreement rate by team tells you where coding discipline has gone. Ground it in a reviewed sample rather than the raw back catalogue, or you teach it the existing bias perfectly.

Redress and interest calculated the same way twice

The consistency problem is easy to state and uncomfortable to look at. Two customers, the same charge in the same circumstances, two handlers, two outcomes, and the only variable is who picked up the case.

Split redress into its parts. The refund, any consequential loss, and interest for the period the customer was out of pocket are arithmetic against a dated transaction list, and should be computed by tooling that shows its working rather than typed into a spreadsheet. The payment for distress and inconvenience is judgement and stays with the handler, but the system can show what comparable closed cases awarded and flag quietly when a figure sits well outside that range. The handler can be right and the range wrong; the point is that they noticed.

When a case is upheld, ask whether the same defect touched customers who never complained. That query is the difference between settling a case and fixing a problem.

The final response written so it can be followed

The letter has to say what the customer complained about, what was examined, what was found, what the decision is, what will be paid and when, and what they can do if they remain unhappy, including the external dispute scheme in your market and the time limit for going to it. Drafting that from a structured case record is well within reach, provided every factual assertion points to the file item behind it.

The failure mode to design against is the letter that explains your internal process instead of answering the question asked. Close behind are the apology that contradicts a decision not to uphold, and the partial uphold that never says which part. Plain language is not a style preference here. A customer who cannot tell whether they won escalates.

The decision stays with a named person. Whether to uphold, and what is fair, are not model outputs, and no draft goes out unread.

When the case goes outside

Referral packs get assembled badly because they get assembled late. Build the pack at closure instead: chronology, evidence items, the reasoning, the final response, the contact log. The scheme's questions are usually about what the customer was told and when, so treat correspondence and contact history as first class, not an appendix. A person still reads the pack before it leaves.

Thematic reporting and sampling what you closed

Clustering the free text of closed cases finds themes the code list cannot express: a fee triggered by a statement change, a letter template that frightens people, an account closure process that gives no reason and earns a second complaint every time. Route each theme to the product owner who owns the cause, with the cases attached, not as a slide in a quarterly pack.

Quality assurance is the other use. Today a small sample gets reviewed against a checklist, chosen by convenience. A model can pre-screen every closed case for the checkable things: acknowledgement sent, deadline met, a flag where the file shows markers, root cause consistent with the narrative, redress reproducible, every issue raised addressed in the letter. Reviewers then spend their time on flagged cases plus a random control. Keep the control. A sample chosen only by the machine tells you about the machine's blind spots.

Where AI fails here

Fairness is not a classification task. Whether to uphold is a judgement about what should have happened, and a model trained on your closed cases learns what you did, which is not the same thing.

Detection cuts both ways. Too generous and you bury the team in records that are not complaints. Too conservative and under-recording is back, now with a machine to blame. That threshold is a business decision needing regular review, not a setting you choose once.

Call audio is the weakest link in the file. Poor lines, background noise, hold music and dropped channels produce transcripts that are confidently wrong, and a wrong transcript in an evidence file is worse than a gap.

Historic cases resist the approach. Correspondence exists only as images, servicing files arrived with another firm's conventions, and migrated records often carry the migration date rather than the real one. A chronology built on those dates is wrong in the way nobody checks for.

Distress cannot be computed, and neither can the read that this customer, on this call, needs someone to ring them today. Difficulty is often undisclosed too. Absence of a marker is not evidence of absence, and a design that treats it that way fails the customers it most needed to catch.

The first complaint queue worth automating

Start with detection on one channel, running in shadow, measured against a re-read of the same period by your quality team. You will learn your true under-recording rate, which is worth having on its own. In parallel, fix two things that are not AI problems: retrieval of dated transactions with the terms in force at the time, and a contact log that spans channels. Without those, every later step is guesswork in a confident voice.

If complaint capture, evidence assembly or the final response letter is where your operation loses its time, describe it to Adopt AI Partners and we will tell you plainly which parts a system should carry and which stay with your people.