Call analytics for collections and support

The leak

A lender's collections and customer-service teams make and take thousands of calls a month. The quality team listens to a sample of one or two percent, scores them against a checklist by hand, and feeds back weeks after the call happened. Coaching is built on anecdote. Nobody knows, across the whole volume, whether calls are being opened and closed properly, how often a script is followed, which objections agents handle well and which they lose, or what customers actually say when they explain why they have not paid.

Three kinds of evidence were sitting unused in the recordings. Performance evidence: how each agent and each team is doing, week on week. Customer evidence: the real reasons behind non-payment, job loss, a hospitalisation, a dispute, a complaint about being called too often. And risk evidence: the rare call where an agent crosses a line, or a customer reports harassment, which under the old process might surface weeks later, if at all, when it had already become a bigger problem.

The leak is not a single number. It is every coaching conversation, allocation decision and escalation made without evidence that had already been recorded.

The constraint

The calls are regulated, personal, and in several languages. The audio and the transcripts could not leave infrastructure the company controls, so transcription and analysis had to run on open-weight models, with a fallback engine for when the primary one is unavailable, and at a cost per minute that made reviewing every call affordable rather than aspirational.

Transcripts are also untrusted input. A system that feeds a customer's words into a language model has to be hardened against text that tries to steer the model, so the analysis pipeline was built with prompt-injection defences and tested against a red-team set before it saw a real call.

And it had to be useful to a team lead on a Monday morning. The audience is not a data scientist. It is a person with thirty agents and a target.

The system

Every recording is transcribed, with a second engine as fallback, diarised into speakers, scored against the company's own quality framework and classified by topic, outcome and risk. The same pipeline serves customer support, collections and sales, each with its own framework, and separate tenants so each business line sees only its own calls. From the scored calls, the system serves four views.

The vertical view is the team's week. For customer support: the distribution of good, average and poor calls, fatal calls, risk-severity flags, performance against each quality parameter, whether calls are opened and closed correctly, whether the customer's query was understood, sentiment, call concurrency, the hours when calls peak, and the categories customers raise most. For collections: the breakout by bucket, fatal and non-fatal calls, an hourly score trend, the top risk categories, day-on-day and week-on-week movement, and the frustration drivers behind non-payment, from job loss and hospitalisation to accidents and complaints about repeated calls.

The agent view is one person against the team: performance trend, handle time, quality of calls, the sentiment they achieve, their quality parameters, opening discipline, script adherence, their risk signals and frustration keywords, the promises to pay they secure, and, set against the rest of the team, where they are strong and what they need to be trained on next. Coaching becomes specific and defensible.

The loan view turns the calls inside out. For any loan: how many calls have been made, when the customer actually answers, who usually picks up, what has been promised, and a risk rating built from all of it. From there, the highest-risk loans in the book and a recommendation of which agent should hold which loan.

Running through all of it, an early-warning system. Calls that meet conduct-risk criteria, abuse by an agent, a harassment claim by a customer, are flagged and routed to the responsible team the same day, so action happens while the call is still fresh instead of after a complaint has escalated.

The whole thing runs on a queue with priorities and a dead-letter lane for failures, pushes live progress to the screen as calls are processed, signs users in with the company's identity provider, encrypts payloads at rest, and carries a threat model and a security review like every other system on this stack.

The number

Every call reviewed, where a sample was reviewed before. Conduct flags raised the same day instead of weeks later. Live for collections first, with customer service and sales following, and a daily review built into the team leads' routine so the views are looked at, not just available.

What I would do differently

Start with the team lead's Monday, not with the dashboards. The system was built view by view, and the adoption came when the daily review became a rule rather than an option. Next time the rule comes first and the views are built to serve it. I would also instrument outcomes from the start, so that the link between coaching, promises to pay and actual recovery is measured in the system rather than argued about outside it.