How an AI voice agent handles outbound debt collection calls end to end

Overdue account lists land via FTP on a schedule. An automation parses the file and upserts records into a Supabase table, keyed so re-running the same file does not create duplicate leads. This detail matters more than it sounds: a collections list re-uploaded after a partial failure is a routine event, and without an upsert key it silently doubles every account on it.

A cron-based scheduler checks each lead's status flags (active today, do not contact, permitted time window) and batches outbound calls only within permitted calling hours, skipping weekends and public holidays automatically. This is the compliance layer, and it lives in the scheduler, not in the conversation script, so it cannot be bypassed by anything downstream.

The conversation is not one fixed script. It has distinct stages corresponding to where the account sits in the collections process: an early reminder tone for a first missed payment, a formal notice tone once it has aged further, and an active enforcement tone with different required disclosures for accounts furthest along. The voice agent picks the stage from the account record before the call connects.

Getting the tone and required disclosures right per stage is the actual engineering work here, more than the voice technology itself. A script that is too aggressive too early damages the relationship and the brand; one that stays too soft too long delays recovery. This is tuned with the client's collections team, not guessed at.

The system detects whether a human answered or the call went to voicemail and branches accordingly: a compliant, stage-appropriate voicemail message, versus continuing a live conversation. Getting this detection wrong in either direction is costly. A live person mistaken for voicemail gets read a monologue with no chance to respond. Voicemail mistaken for a live person wastes agent time on a system that has none to waste.

For unanswered calls, or as a supplement, an automated SMS goes out with a secure payment link. This alone recovers a meaningful share of accounts that would otherwise need a second or third call attempt, and it costs a fraction of a call.

When a customer wants to pay during the call, the agent hands off to a DTMF (keypad) payment flow integrated with a payment processor. The card number is entered by the caller directly on their keypad and never passes through the voice model, the transcript, or any log the automation writes. This is what keeps the flow PCI friendly by design rather than by policy someone has to remember to follow.

The same underlying system serves multiple brands from one platform, each with its own script, voice, and caller ID, routed by which brand the lead belongs to. This is what makes the economics work: the infrastructure cost is shared, only the configuration changes per brand.

After every call, a webhook receives the transcript and outcome and logs it against the lead record, updating status (contacted, promised to pay, disputed, escalated) for reporting and for the next scheduling cycle. Nothing about the next call's stage or timing is guessed, it comes from this log.

This closes the loop: the system does not just place calls, it learns from the outcome of each one what to do next for that specific account, which is what separates a working collections system from a script that dials a list once and stops.