Aharna Haque

Posted on Oct 9

How to use AI voice agents for debt collection: A practical guide

#ai #automation #agents

An AI voice agent for debt collection is software that calls borrowers about overdue balances, holds a real conversation using speech recognition and generative AI, and records what happened, instead of playing a fixed message or waiting for a human to dial. This guide covers where voice agents fit in collections, what they need to get right on compliance, how to set one up, and how to tell whether the calls are working.

Why collections is moving to voice AI

Collections is a volume problem with a people problem inside it. A team dials hundreds of accounts, most go to voicemail, and the few that connect are often tense. It's repetitive, hard to staff, and expensive to scale.

That makes it a natural fit for an outbound voice agent. The work is structured, the goal of each call is narrow, and the cost of an inconsistent call is high.

The important part is what the agent is for. It isn't there to replace your collectors. It handles the early-stage, high-volume and after-hours calls, so your human team spends its time on the accounts that need judgment.

The example: An early-stage payment reminder

Here's the scenario used throughout this guide. A borrower is seven days past due on an instalment. Nothing has gone to a formal recovery stage yet. An outbound agent calls and has one job: find out whether the borrower knows about the payment, and get a commitment or a reason.

This is a good first use case because it's low-stakes and structured. The agent doesn't need to settle a dispute or restructure a loan. It needs one of four outcomes: paid, promise to pay, dispute, or escalate to a human.

That's easy to script, easy to test, and easy to measure.

Compliance comes first

In collections, compliance isn't a feature you add later. It decides whether the program can run at all.

A voice agent can be more consistent than a human team here, because it doesn't have a bad day. It calls inside the allowed window, delivers the required disclosure every time, and logs every word. But it only does that if you set it up to.

Things to confirm before a single call goes out:

Calling hours. In the US, the FDCPA restricts calls outside roughly 8 AM to 9 PM in the borrower's local time. In India, RBI's recovery guidelines are tighter, so check the current rules for your lender type.
Required disclosures. Who is calling, on whose behalf, and that the call is about a debt. Put this in the first message, not buried in the middle of the call.
Consent for automated calls. In the US, the FCC treats AI-generated voices as artificial voices under the TCPA, which raises the bar on prior consent. Get legal sign-off on this one.
Call frequency. Set a cap on attempts per account per week and enforce it in the campaign, not in someone's head.
Recording and retention. Know where recordings and transcripts live and who can access them.
Dispute handling. If a borrower says they don't owe the debt, the agent should log it and stop pressing.

This isn't legal advice. Run the script and the call flow past your compliance or legal team before launch.

Before you start: What you need

Two things need to be ready before you configure anything:

A phone number the agent will call from, connected through your platform or a SIP trunk
Agent instructions: the opening line with the disclosure, the goal of the call, and exactly what the agent does when the borrower disputes, gets upset, or asks for a person

Everything else builds on these two.

Step-by-step setup guide

The steps are platform-agnostic. The specifics use DronaHQ's voice agent as the working example.

Step 1: Connect a number and create the agent

Connect telephony through a SIP trunk. A Twilio Elastic SIP Trunk works if you already run call infrastructure on Twilio. Once connected, route the number to your agent under Call Configuration → Outbound Settings, then create the agent from the admin console.

One constraint to plan around: each number is tied to one agent and one live call at a time. If you're working through a large portfolio in a short window, you'll need more than one number, or the campaign simply takes longer.

Step 2: Write the instructions branch by branch

Set the voice, transcriber and LLM models, then write the first message. Use placeholders. A generic opener sounds like a robocall within two seconds, and in collections that costs you the call.

Something like:

"Hi {{borrower_name}}, this is {{company_name}} calling about your {{loan_type}} payment of {{amount_due}}, which was due on {{due_date}}. This call may be recorded. Is this a good time to talk?"

It names the borrower and the exact payment, and it carries the disclosure up front.

For the instructions, don't write "handle the borrower's response." Spell out every branch:

Says they'll pay today: confirm the amount, confirm the method, end the call
Asks for more time: ask for a specific date, log it as a promise to pay
Says they can't pay in full: offer only the options you've approved, nothing improvised
Disputes the debt: acknowledge it, log it, stop the collection conversation
Gets angry or asks for a human: transfer or schedule a callback immediately

An agent that only knows the goal, not the branches, tends to over-explain or loop when the conversation goes off script. In collections, an improvised offer is also a compliance risk.

Step 3: Connect your tools before you launch

The agent needs somewhere to send what happened. In DronaHQ that's the Tool Builder and Connector Library, with integrations like Google Sheets, Slack, Notion and Gmail, plus MCP and Composio for anything not natively supported.

Connect at least one destination before the first campaign. For collections that could be a sheet that logs every promise to pay, or an alert to your collections team when a borrower disputes or asks for a human. If you wire this up later, you spend that gap pulling outcomes out of call logs by hand.

If you want to send a payment link after the call, do it through a connected tool or webhook, and keep the payment itself in your existing payment system.

Step 4: Run a campaign

With the agent built and tools connected, set up the campaign:

Name it, pick the number to call from, and select the agent
Upload a CSV of accounts and map the columns to the variables the agent expects, like borrower_name, amount_due and due_date
Turn on auto-retry for unanswered calls, with a retry count and wait time
Set the timezone and calling window

The calling window matters more here than in most outbound use cases. Set it inside your legal hours, in the borrower's timezone, and treat it as a hard limit rather than a preference. Let auto-retry handle the people who miss the first call.

Also check that the agent is published before you launch. Campaigns only pull published agents and published changes, so a script edit you forgot to publish means the campaign runs on the old version without telling you.

Step 5: Watch the first batch

Open the Campaign Overview early and watch the pick-up rate on the first batch. If it's low, the calling window is usually off or a chunk of numbers in the CSV are bad. It's cheaper to catch that after twenty calls than after two thousand.

Then listen to a few transcripts. Check the calls marked completed, not just the failed ones, and read specifically for the disclosure, the tone when a borrower pushes back, and whether the agent stayed inside the offers you approved.

Post-call analysis: How to measure whether it's working

A transcript alone doesn't tell you whether a collections program is working. You need structured data from every call, in a place your team already looks.

The setup has four parts:

Structured output on the agent. Define a schema for the fields that drive a decision: disposition, promise-to-pay date, promised amount, dispute flag, sentiment. It runs as part of the call, so the data is ready when the call ends.
A post-call webhook. The agent fires it once the structured output is ready, so nobody opens a call log to check.
An automation that catches it. Write the fields into a database. A Google Sheet is fine to start, and a proper database makes sense once volume makes the sheet painful to query.
A dashboard on top. Once outcomes land in one place consistently, connect a dashboard so trends show up without exports.

For the payment reminder example, a completed call produces a record like this: disposition: promise_to_pay, promised_date: Friday, dispute: false, sentiment: neutral. That record can log a row in a tracking sheet and, if the borrower asked for a human, alert your team immediately.

Build this against a hundred calls a day, not after you're running several campaigns.

Metrics worth tracking from day one:

Connect rate: picked-up calls against total dialed
Disposition mix: paid, promise to pay, dispute, no answer, wrong number
Promise-kept rate: how many promises to pay turn into actual payments. This is the number that tells you whether the calls changed behavior.
Dispute and complaint rate: the early warning for compliance problems
Escalation rate: how often the agent hands off to a human
Cost per call: split across speech-to-text, the model, text-to-speech and structured extraction

Promise-kept rate is the one most teams skip. A call that ends in a promise looks like a win until nobody pays.

Voice agent vs. human team vs. autodialer

	Human collections team	Autodialer / prerecorded IVR	AI voice agent
Reach	Limited by headcount and shifts	Every account, one-way message	Whole portfolio, two-way conversation
Handling pushback	Strong, varies by person	None, dead-ends	Handles scripted branches, escalates the rest
Disclosure consistency	Varies by agent and day	Scripted, can't adapt	Same on every call
After-hours coverage	Needs extra staffing	Yes	Yes, inside legal hours
Data capture	Free-text notes	Keypress only	Structured, per call
Best for	Complex and sensitive accounts	Simple notices	Early-stage, high-volume, after-hours calls

The practical difference is that a voice agent gives you coverage and consistency on the volume work, and your humans keep the judgment work.

Failure modes to watch for

Calling outside the legal window: a timezone mismatch in the CSV is enough to cause it
No escalation path: a borrower who wants a human and can't reach one is worse than no call at all
Improvised offers: if the agent isn't told what it can offer, it may offer something you can't honor
Pressing after a dispute: a dispute should end the collection conversation and route to a person
Silent nulls treated as answers: a null field means "not mentioned," not "no"
Over-nested extraction schemas: start with three or four fields that drive a decision
Wrong person on the line: the agent shouldn't discuss the debt until it's confirmed who it's speaking to
No human spot-check loop: sample a small percentage of calls on a recurring basis, even once automation is live

Where humans still matter

Voice AI handles the repetitive first contact well. It handles hardship, grief, anger and complicated disputes less well, and those are the calls where a bad interaction does the most damage.

So design the handoff on purpose. Decide which signals trigger a transfer, whether that's a dispute, a hardship mention or a request for a person, and make sure a human gets the full context when they pick up. A borrower shouldn't have to repeat themselves.

Pre-launch checklist

Number connected and eligible for outbound use in its region
Calling hours, disclosures and consent reviewed by compliance or legal
Agent created, with voice, transcriber and LLM models selected
Instructions written branch by branch, first message tested with all placeholders
Escalation and dispute rules configured
Tools connected, with at least one wired to a real destination
Contact CSV prepared, columns mapped, and timezones verified
Auto-retry, attempt cap and calling window configured
Agent published before the campaign launches
Structured output schema defined (three to four fields to start)
Test call reviewed before the full campaign

Closing

Voice AI in collections works when the boring parts are in order: compliance settled first, instructions written branch by branch, and outcomes captured in a form your team can act on. The model's voice quality is rarely what decides it.

Start narrow. Pick one early-stage use case, like the seven-day payment reminder, check the first batch closely, and expand only once promise-kept rate and complaint rate both look healthy.

DEV Community