How to Create Domain-Specific Intents for Collections (2026)

TL;DR

Domain-specific intents for collections workflows are NLU labels purpose-built for repayment conversations. Unlike generic customer-service intents, they classify precise borrower signals (promise-to-pay, hardship, disputes, wrong-party contact, opt-out requests) and map each one to a governed recovery action. This guide covers what collections intents are, provides a practical taxonomy of 25+ intent types, walks through a ten-step creation process, and explains how to test and govern them in regulated Indian BFSI environments.

What Are Domain-Specific Intents for Collections Workflows?

A domain-specific intent for collections is a collections-ready NLU label that turns borrower language into a governed recovery action. It captures not only what the borrower says, but what the lender should do next: collect a payment, log a promise, schedule a follow-up, suppress further calls, escalate a dispute, switch language, or hand off to a human.

Generic bots use broad labels like make_payment, ask_question, or talk_to_agent. That granularity is useless in collections. A borrower saying “I already paid” needs payment verification. A borrower saying “I’ll pay Friday” needs PTP logging, a payment link, and a reminder. A borrower saying “wrong number” needs the contact record flagged and future calls suppressed. These are different operational paths, and they need different intents.

Understanding how to create domain-specific intents for collections workflows is foundational for any voice AI or chatbot deployment in debt recovery. Without the right intent design, the system understands words but fails to trigger the right action. A promise-to-pay intent without a PTP date, amount, and follow-up event is just a transcript annotation.

Explore building an AI-assisted collections pilot →

Why Collections Needs Domain-Specific Intents

Generic customer-service intents break in collections for three reasons.

Collections conversations are action-heavy. Every borrower response should trigger a specific workflow event: a PTP entry, a payment link, a dispute ticket, a callback schedule, a suppression rule, or an escalation. If the intent is too broad (like a single payment_issue label covering twelve different borrower situations), the system cannot choose the right action.

Collections conversations are regulated. RBI guidelines prohibit intimidation, harassment, calls before 8 a.m. or after 7 p.m., privacy intrusion on family members, and threatening or anonymous calls during overdue loan recovery. A misclassified intent can create compliance risk. If the system treats a wrong-party contact as a payment refusal, it may continue calling a number it should have flagged.

Collections conversations happen over voice. Voice adds ASR errors, background noise, accents, interruptions, and code-switching. Hamming AI reports that voice agents have 3 to 10x higher intent error rates than text because ASR errors cascade into NLU errors. A collections model can pass clean-text tests and still fail on live calls.

One developer on Reddit described building a payment-reminder voice agent for collections as “brutal” because borrowers are already on edge about money and have almost zero tolerance for broken-feeling automation. That observation is worth internalizing: in collections, a wrong classification is not just poor CX. It can create borrower distress, repeated unnecessary calls, formal complaints, or regulatory action.

Practitioners on LinkedIn have started arguing that voice AI alone fails collections when it is not connected to payment plans, PTP tracking, dispute routing, and compliance controls. The shift is from “voice bot” to “workflow infrastructure.” Domain-specific intents for collections workflows are the mechanism that makes that shift possible.

For a deeper look at how NLU works in financial contexts, see this guide on domain-specific financial NLU.

Intent vs Utterance vs Entity vs Disposition

Before creating collections-specific intents, it helps to clarify the related terms that often get confused.

One call may contain several intents but only one or two final dispositions. A borrower might disclose hardship, then offer a partial payment, then ask for a callback. That is three intents, but the disposition might simply read “partial PTP captured.”

Rasa’s documentation describes NLU training data as utterances grouped by intent, with optional entity annotations, synonyms, regexes, and lookup tables. That structure applies directly to collections intent design, but the collections layer adds something Rasa’s generic framework does not: every intent must connect to a policy-approved downstream action.

An intent should not automatically equal an action. The system should check policy and context first. A detected settlement_request requires checking the DPD bucket, outstanding amount, eligibility rules, and prior settlement offers before the system can respond. Microsoft’s Customer Intent Agent documentation supports this separation by allowing intents to have instructions and escalation boundaries mapped to specific business rules.

A Practical Taxonomy of Collections Intents

This is the core information most existing content misses. Below are the intent categories that collections workflows actually need, with example utterances and the downstream actions each should trigger. This taxonomy is the main output of any effort to create domain-specific intents for collections workflows.

Payment Readiness Intents

These capture whether the borrower is willing and able to pay.

Collections KPIs depend directly on these intents. Industry benchmarks define PTP rate as promises to pay divided by right-party contacts, and kept PTP as fulfilled promises divided by PTPs. If the system cannot reliably capture promise_to_pay with accurate date and amount slots, these metrics become unreliable.

A LinkedIn practitioner checklist for collections agencies made a strong point: voice AI should not just increase call volume, it should decide when not to call. Accounts with a recent PTP, active payment plan, unresolved dispute, or cease-contact request should be suppressed. A well-captured promise_to_pay intent is what makes that suppression possible. For teams building automated payment reminders, these payment readiness intents are the starting point.

Hardship and Constraint Intents

These distinguish willingness from ability. They are among the most important intents to get right in any domain-specific collections intent design.

Practitioners on LinkedIn have repeatedly stressed that “I cannot pay” can mean a dozen different things: temporary cash crunch, strategic delay, misunderstanding, job loss, medical expense, or simple disorganization. The next action depends entirely on the reason. Lumping all of these into one cannot_pay intent is an operating model failure, not just an NLU gap.

A Haptik collections demo showed a voice AI handling an overdue personal-loan scenario by discussing partial payment, communicating remaining balance and interest, capturing a future PTP date, and sending a WhatsApp payment link. User comments praised that it balanced compliance and dignity without threatening or guilt-tripping. That balance is only possible when the system correctly distinguishes hardship_disclosure from refusal_to_pay and responds with the right tone and action for each. For more on compliant language during AI debt collection calls, see the linked guide.

Dispute and Exception Intents

These are high-risk. They should usually trigger human review or a governed dispute workflow, not an automated payment push.

Do not merge disputes into cannot_pay. A dispute is not a repayment objection. It is a risk and compliance event. Treating already_paid as an objection and continuing payment pressure is exactly the kind of mistake that generates complaints and regulatory attention.

Identity and Contactability Intents

Wrong-party contact and do-not-contact are not edge cases. They are compliance-critical intents. RBI guidance explicitly prohibits intrusion on the privacy of debtors’ family members, referees, and friends. A system that cannot detect wrong_party_contact reliably risks violating that rule at scale.

Communication Preference Intents

Fallback and Safety Intents

Hamming specifically warns against executing low-confidence intents in critical domains like banking. The recommendation: route mid-confidence to confirmation (“Just to confirm, you want to pay on Friday?”) and route low-confidence to fallback or human handoff.

How to Create Domain-Specific Intents for Collections Workflows: Ten Steps

Knowing what intents exist is only half the problem. The harder part is building them well. Here is a step-by-step process for creating domain-specific intents for collections workflows that actually work in production.

Step 1: Start With One Narrow Collections Journey

Do not begin with “all collections.” Pick one measurable journey: pre-due EMI reminders, DPD 1 to 7 payment follow-ups, broken PTP callbacks, or dispute triage. FinoLabs recommends that lenders start with narrow, measurable journeys instead of trying to automate every repayment scenario at once.

For an early DPD reminder flow, 12 to 20 well-defined intents is better than 80 overlapping labels. Expand later. A confused model cannot be fixed by adding more intents.

Step 2: Gather Real Borrower Language

Source data should include historical call transcripts, call recordings, human-agent notes, disposition codes, payment outcomes, WhatsApp and SMS replies, broken PTP records, dispute tickets, and complaint reasons.

Scripts show what the lender says. Intent data must show what borrowers actually say. Microsoft’s documentation describes using historical interactions to discover intents and create an intent library. That approach applies directly here, but collections language is messier, more emotional, and more multilingual than typical customer-service data.

Step 3: Cluster Conversations Into Canonical Labels

Use ops, compliance, and NLU teams together. For every intent, define the intent name, its plain-language meaning, in-scope utterances, out-of-scope utterances, required entities and slots, allowed system actions, prohibited system actions, escalation rules, and disposition mapping.

The distinction between in-scope and out-of-scope is critical. “I’ll pay tomorrow” is a clear promise_to_pay. But “I’ll try” is not. “Maybe next month” is not. These need a separate needs_clarification label because the system should not log a PTP when the borrower has not actually committed.

Step 4: Build an Intent Hierarchy

A flat list becomes impossible to govern as the system grows. Use parent-child grouping:

Collections
├── Identity and contactability
│   ├── right_party_confirmed
│   ├── wrong_party_contact
│   ├── borrower_unavailable
│   └── deceased_or_sensitive_status
├── Payment readiness
│   ├── pay_now
│   ├── promise_to_pay
│   ├── partial_payment_offer
│   └── settlement_request
├── Hardship and constraint
│   ├── temporary_cashflow_issue
│   ├── income_loss
│   └── medical_emergency
├── Dispute and complaint
│   ├── already_paid
│   ├── amount_dispute
│   └── fraud_or_not_mine
├── Communication preference
│   ├── language_switch
│   ├── callback_request
│   └── do_not_contact
└── Fallback and safety
    ├── low_confidence
    ├── out_of_scope
    └── high_distress

This hierarchy helps in two ways. It organizes governance (different teams own different branches), and it reduces NLU confusion within groups.

Step 5: Define Entities, Slots, and Normalization Rules

Collections workflows depend on slot accuracy. The system must extract the right value, not just the right intent. Critical slots include PTP date, PTP amount, payment channel, hardship type, dispute reason, callback time, preferred language, consent status, and wrong-party indicator.

For Indian collections, normalization is especially important. The amount “₹5,000” can appear as “5k,” “paanch hazaar,” “five thousand,” or “5000 rupees.” The date “tomorrow” can appear as “kal,” “agle din,” or “next day.” Without synonyms, regexes, and lookup tables, slot extraction breaks on real borrower speech.

These extracted entities need to flow into the CRM or loan management system. For more on that integration, see this guide on voice AI and CRM integration.

Step 6: Add Multilingual and Code-Switched Variants

For India, do not create only English training examples. Borrowers code-switch constantly. A single utterance might start in English and end in Hindi. Research on Indian ASR shows that clean, scripted benchmarks are inadequate. The Voice of India benchmark, built from unscripted telephonic conversations across 15 Indian languages and 139 regional clusters, explicitly notes that existing Indic ASR benchmarks rely on clean speech that does not reflect production conditions.

Reddit builders working on Indian voice AI confirm this gap. One thread described testing angry Hinglish callers under G.711 compression, packet loss, and call-center noise, noting that mixed-language sentences trip up many speech-to-text models. In Indian collections, code-switching is production data, not test data. For a deeper look, see this code-switching voice AI guide.

Step 7: Map Every Intent to Policy-Approved Actions

This is where a domain-specific intent becomes valuable. Every intent needs two lists: what the system should do, and what it should not do.

If the intent is not connected to a workflow, the system has only understood the borrower. It has not helped collections.

Learn how to integrate voice AI with collections systems →

Step 8: Design Low-Confidence Handling Before Launch

Collections is a critical domain. The model should not guess.

Step 9: Test With ASR Output, Not Clean Text

Text NLU tests are necessary but not sufficient. Voice adds ASR errors, background noise, accents, interruptions, latency, and partial utterances. Hamming recommends testing at scale with 100+ utterances per intent and 10,000+ total utterances to catch rare but critical confusion patterns.

Practitioners on Reddit repeatedly mention that production voice agents fail when users interrupt, ramble, change intent mid-sentence, or combine multiple intents in one utterance. Collections calls often contain multiple signals in one breath: anger plus hardship plus partial payment plus callback request. Build test cases that reflect that reality, not clean single-intent sentences.

Step 10: Monitor Outcomes and Iterate

Do not stop at classification accuracy. The real test is whether the intent system improves recovery outcomes. FinoLabs recommends tying iteration to promise-to-pay quality and actual repayment follow-through, not raw talk time or connection rate.

A Reusable Intent Template

For every intent in the collections taxonomy, fill out this template:

Intent name:
Business definition:
In-scope utterances:
Out-of-scope utterances:
Required entities:
Optional entities:
Allowed system actions:
Prohibited system actions:
Escalation trigger:
Disposition mapping:
Success metric:
Compliance notes:
Languages and variants:
Owner:
Version:

This template forces the team to think through every layer before writing training data. Without it, intent design drifts into a phrase-matching exercise that misses the operational and compliance requirements that make collections intent design different from generic NLU work.

Common Mistakes in Collections Intent Design

Creating one giant payment_issue intent. Twelve different borrower situations cannot share one label.

Treating hardship, dispute, and refusal as the same thing. A dispute is a compliance event. Hardship needs empathy and escalation. Refusal needs a different follow-up path. Merging them guarantees wrong actions.

Using clean English training data for Indian voice calls. If borrowers speak Hinglish, Marathi-English, or Tamil-English, the training data must include those patterns. For more on compliant and effective collections language in India, see the linked guide.

Ignoring wrong-party and do-not-contact signals. These are not edge cases. They are regulatory requirements.

Letting low-confidence intents trigger payment or legal language. In banking and collections, executing uncertain intents creates real financial and regulatory risk.

Measuring talk time instead of PTP quality. The right metric is whether promises convert to actual repayments, not how long the call lasted.

Not connecting intents to CMS, CRM, or LMS actions. An intent that produces a conversational reply but does not update the collections system has no operating value.

Calling accounts with active PTPs, disputes, or cease-contact requests. Good systems decide who should not be called, not just who to call next.

How to Measure Intent Performance Against Business Outcomes

Measuring domain-specific intents for collections workflows requires two scorecards.

Intent Quality Scorecard

Track intent classification accuracy, intent confusion rate (which intents get mixed up), first-turn intent accuracy, out-of-scope detection rate, slot filling accuracy, fallback rate, and human escalation precision.

Collections Outcome Scorecard

Track right-party contact rate, PTP capture rate, kept PTP rate, same-day payment rate, partial payment rate, recovery rate, broken PTP rate, dispute rate, wrong-party suppression accuracy, complaint rate, and cost per recovered account.

A LinkedIn practitioner argued that many contact centers lack “intent economics,” meaning they do not measure cost per intent. After launch, track cost and outcome by intent. A balance_clarification should not cost the same to handle as a fraud_dispute or hardship_escalation. That insight changes how teams allocate NLU improvement effort and automation budget.

India-Specific Considerations

Creating domain-specific intents for collections workflows in India requires attention to three additional dimensions.

Multilingual and Vernacular Support

India’s borrower base speaks dozens of languages and routinely code-switches within a single sentence. A collections intent library for India should treat code-switching as normal input, not an exception. Training data should include examples in Hindi, Hinglish, Tamil-English, Telugu-English, Kannada-English, Marathi-English, Bengali-English, regional expressions, formal and informal registers, and low-literacy phrasing.

RBI Recovery-Agent Conduct Rules

RBI guidelines make regulated entities responsible for their recovery agents (including AI agents) and prohibit intimidation, harassment, privacy intrusion, threatening or anonymous calls, persistent calling, and calls before 8 a.m. or after 7 p.m. Intents like wrong_party_contact, do_not_contact, service_complaint, and deceased_or_sensitive_status are not optional. They are required for regulatory compliance.

Data Protection Under DPDP

India’s Digital Personal Data Protection Act creates a consent-based framework for digital personal data processing. Collections calls and follow-ups process personal data. Intent systems should log detected intent, action taken, disclosure given, payment link sent, escalation reason, and call outcome in auditable form. The system should not generate uncontrolled threats, legal claims, or credit-bureau consequences.

Review the enterprise security and compliance checklist →

Frequently Asked Questions

What is a domain-specific intent?

A domain-specific intent is an intent label designed for a particular business process rather than a generic customer-service category. In collections, it classifies borrower meaning (like a promise to pay, a dispute, or a hardship disclosure) and triggers a specific recovery action.

What are examples of collections intents?

Common examples include promise_to_pay, pay_now, partial_payment_offer, already_paid, amount_dispute, wrong_party_contact, hardship_disclosure, callback_request, language_switch, settlement_request, do_not_contact, and human_agent_request.

How is a collections intent different from a disposition?

An intent is detected during the conversation and can change multiple times as the borrower speaks. A disposition is the final outcome logged after the conversation ends. One call may contain several intents but typically results in one or two dispositions.

Why do collections workflows need domain-specific intents instead of generic ones?

Because repayment conversations involve regulated actions, sensitive borrower situations, and downstream system updates. A generic intent may recognize the words but fail to trigger the right recovery action, creating compliance risk and poor outcomes.

How many intents should a collections workflow start with?

Start with one narrow journey and 12 to 20 well-defined intents. For an early DPD reminder flow, that is usually enough to cover payment readiness, basic hardship, wrong-party contact, callback, dispute, language switch, and fallback scenarios. Expand only after the initial set works reliably.

How do you test collections intents for voice?

Test with real or realistic ASR output, not clean text. Include noisy calls, accents, code-switching, multiple intents per utterance, interrupted speech, and low-confidence examples. Track confusion between similar intents like promise_to_pay and temporary_cashflow_issue. Aim for 100+ utterances per intent at minimum.

What happens when the system is not confident about the detected intent?

High-confidence intents can execute if slots are filled and policy allows. Medium-confidence intents should be confirmed with the borrower. Low-confidence intents should fall back to options or human handoff. Never execute uncertain intents that trigger payment demands or legal language.

Can the same borrower utterance contain multiple intents?

Yes. A borrower might say “Hospital expense chal raha hai, ₹2,000 abhi de sakta hoon, baaki next week.” That utterance contains a hardship disclosure, a partial payment offer, and an implicit PTP. The system needs to handle multi-intent utterances, typically by prioritizing the most operationally significant intent and capturing all relevant entities.

To create domain-specific intents for collections workflows, start from the recovery journey, collect real borrower language, define precise labels, attach required slots, map each intent to policy-approved actions, test under real voice conditions, and improve using repayment outcomes. The best intent libraries are built from what borrowers actually say, not only from approved scripts.

Explore Awaaz AI voice agents for BFSI collections →