What Call Monitoring Should Actually Look For

A typical collections quality form asks whether the collector identified themselves, gave the required disclosure, verified the party, and used approved language. Every box can be ticked on a call that went badly — pressure applied to someone who correctly said they couldn't pay, an arrangement agreed that was never going to hold, a disclosed hardship nobody acted on. The checklist measures whether the words were said. It has no view on whether the call should have gone the way it did, and that's where both the recovery and the risk actually live.

Two different questions

	Compliance check	Quality assessment
Asks	Was the required thing said?	Was this handled well?
Nature	Largely binary	Judgment
Automatable	Largely yes	Largely no
Coverage achievable	All calls	A sample
Finds	Omissions and prohibited language	Judgment failures

Conflating them produces the common outcome: a program that measures the automatable thing with human effort and never measures the thing humans are needed for.

The separation is worth making structural. Compliance checking should run across every call automatically; human review should be spent entirely on judgment — and an operation still using reviewers to confirm that disclosures were read is spending its scarcest resource on its most automatable task.

What to detect

Define the target behaviours before designing any form, because a scoring form built without a list will measure whatever is easy to observe.

What a program should be finding:

• Pressure applied after a clear statement of inability to pay. The failure our promise analysis identifies — collectors measured on commitments will obtain them from people who can't deliver, producing a promise and a broken one.
• Arrangements agreed that don't fit the stated circumstances, which per our plan design guide fail and cost the time they ran.
• Disclosed hardship that wasn't acted on — a mentioned job loss, illness, or bereavement that didn't change the call's direction.
• A dispute raised and not recorded as one, which converts a data quality signal into nothing, per our dispute analysis.
• A bankruptcy or attorney mention not escalated, which per our bankruptcy guide should stop the call immediately.
• Options not offered that the account was eligible for.
• Vulnerability indicators not recognized.
• Tone that was technically permissible and clearly wrong.

What these have in common: none is detectable from a script checklist, and each is a decision the collector made. That's the definition of what human review should be looking at.

Sampling toward risk

The change with the largest effect per unit of effort.

Problems are concentrated; random sampling isn't. Reviewing a random 2% of calls spends nearly all of that effort confirming that ordinary calls were ordinary.

Indicators already in your data:

• Unusually long calls, which frequently mean difficulty.
• Calls that ended abruptly.
• Accounts that complained or disputed afterward — the most direct signal available, and per our complaint analysis most operations never listen to the call behind a complaint.
• Arrangements that broke on the first payment, which suggests they were never viable.
• Collectors whose numbers moved sharply in either direction.
• Repeated contact with the same person in a short period.
• Calls on accounts with vulnerability or hardship flags.
• New collectors, in their first weeks.

Keep a random component — a purely targeted sample can't tell you the base rate, and you need to know whether problems exist outside the flagged population. A reasonable split is most of the effort on risk-weighted selection and a minority on random.

The complaint-linked review deserves separate emphasis: pulling the call behind every complaint is cheap, high-yield, and almost never done. The complaint has already identified the call for you.

Scoring decisions

What a quality form should ask, phrased as judgments rather than as presence checks:

1. Did the collector establish the person's actual situation? The diagnosis that determines everything, and it requires asking rather than proceeding.
2. Was the response appropriate to that situation? Someone temporarily short and someone structurally unable to pay need different calls.
3. Were the eligible options offered?
4. Was the outcome realistic? An arrangement the person plainly couldn't meet is a failure regardless of it being agreed.
5. Was anything disclosed that should have changed the handling?
6. Was it recorded correctly? Disputes, hardship, and contact preferences all have to reach the system.
7. Would you defend this call?

Question seven is the most useful single item on any form. It captures what checklists can't, it's answerable consistently, and a call that fails it while passing everything else is exactly what the program exists to find.

And question four connects monitoring to recovery rather than only to risk: an arrangement that fails costs the operation the weeks it ran, so scoring realism is a performance measure as much as a conduct one. That framing is what gets a quality program taken seriously by people whose metric is recovery.

What automation can and can't do

Speech analytics changes what's achievable, in one direction more than the other.

What it does well:

• Detecting required language across every call rather than a sample — a genuine step change from 2% coverage to complete coverage.
• Detecting prohibited language.
• Flagging keywords — bankruptcy, attorney, dispute, hardship — for escalation and for review selection.
• Surfacing patterns across collectors and time.
• Building the risk-weighted sample automatically.

What it doesn't do well:

• Judging whether the call should have gone that way, which requires understanding a situation rather than detecting a phrase.
• Assessing whether an arrangement was realistic.
• Distinguishing appropriate firmness from inappropriate pressure, where the same words differ entirely by context.

The useful arrangement: automation for coverage, humans for judgment. That's more than an efficiency point — it changes what human review is capable of finding, because reviewers freed from checklist work can be pointed at the calls automation flagged as unusual.

One caution. An automated system detecting only what it was configured to detect will report improving compliance while judgment failures continue undetected — which is the monotonic metric problem from our measurement analysis. Coverage of the measurable is not coverage.

Routing findings to causes

The step that determines whether monitoring changes anything.

Findings should be categorized by cause and routed to whatever can change it, which is frequently not the collector:

Pattern	Likely cause	Route to
One collector, repeated	Individual	Coaching
Many collectors, same issue	Training or script	Training design
New collectors specifically	Onboarding gap	Onboarding
Options not offered	System makes it hard	Systems
Concentrated on one plan	Incentives	Compensation design
Rose after a change	The change	Whoever made it

The fourth row is underappreciated. When a collector doesn't offer an option, the usual cause is that offering it takes eleven clicks and a supervisor approval — which is a systems finding, not a coaching one, and coaching it produces frustration and no change.

The general failure: routing every finding back as individual coaching treats systemic causes as personal failings, and the cause stays in place. An operation coaching the same issue across many collectors for months has misdiagnosed it, and the repetition is the evidence.

When the pattern is the plan

The finding a monitoring program should be capable of producing about its own organization.

Behaviour concentrated among collectors on a particular compensation arrangement is telling you about the arrangement. If pressure-after-inability appears disproportionately among collectors paid on promises obtained, the plan is the cause — and no amount of coaching changes what the plan pays for.

How to see it:

• Break findings down by compensation structure, not just by individual and team.
• Compare across teams on different arrangements.
• Look at timing within a period — behaviour clustering near targets is diagnostic.
• Cross-reference with complaint rate per contact, which per our complaint analysis is the counterweight metric.

This requires a monitoring function willing to report upward rather than only downward, which is an organizational condition rather than a technical one. A quality program that can only produce findings about collectors is a program that has been scoped to protect the decisions above them.

Building the program

1. Separate compliance checking from quality assessment as distinct workflows.
2. Automate compliance detection across all calls where feasible.
3. Define target behaviours before designing the quality form.
4. Build a risk-weighted sample with a random component retained.
5. Review every call behind a complaint or dispute.
6. Score judgments, including "would you defend this call".
7. Categorize by cause, mandatory before closing a finding.
8. Route to the function that can fix it.
9. Break findings down by incentive structure.
10. Track whether the rate of each finding type falls, which is the only test of whether the program works.
11. Apply the same program to agencies, per our agency analysis, since their conduct is attributed to you.
12. Calibrate reviewers periodically on the same calls, since a judgment-based form is only useful if reviewers agree.

Item twelve is the one that makes judgment scoring defensible. Without calibration, a quality score measures which reviewer heard the call — and item ten is the only measure that distinguishes a program that reduces problems from one that documents them.

Frequently asked questions

---

This guide is educational and does not constitute legal or compliance advice. Call recording and monitoring are subject to consent and notification requirements that vary by state and by the parties' locations, and required disclosures in collections vary by jurisdiction and account type. Consult qualified counsel about your recording practices and your program design.