At a glance
- Reminders, standard payment plans, and rule-based holds can run without a person deciding each one, inside a written policy.
- The escalation boundary matrix below covers nine recurring situations: what the system may do alone, what needs a person, a response-time target your institution sets, and the record kept.
- Hardship statements, disputes, legal notices, stop-contact requests, and agency referrals never resolve automatically, no matter how confident the system is.
- Every hand-off needs an owner, a target, and a log entry, or routed cases stall in a queue nobody is watching.
- Review the boundaries each term, not only after something goes wrong.
Why the boundary matters
Collections automation is good at the repetitive middle of the work: sending a reminder on schedule, offering a payment plan that fits terms your office already approved, applying a hold your policy already defines.
It is not good at deciding whether a payment plan should bend for one student, whether a hardship claim changes the approach, or whether an account is ready for an outside agency. Those decisions carry consequences for a student's finances and their standing at the institution, and each one needs a name attached to it, not a log line that reads "system decided."
The NIST AI Risk Management Framework calls for policies and procedures that define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. [1] We recommend writing that boundary down before the outreach sequence goes live, not discovering it the first time a student mentions bankruptcy.
The escalation boundary matrix
The matrix below covers nine recurring situations. For each one it names what the system may do without asking, what needs a person's decision, a response-time target your institution sets, and what the record must show. Copy it, set the targets to match your own policy, and use it as the specification when you configure outreach. The concrete response-time values in the table ("same business day," "next business day," "immediately") are suggested starting points, not fixed defaults or deadlines: replace them with your own policy's targets.
| Situation | System may act on its own | Needs a person's decision | Response-time target (institution sets) | What gets logged |
|---|---|---|---|---|
| Standard reminder | Send the scheduled reminder on the standard cadence, through a channel the student has consented to. | Nothing, unless the student replies. | Follows the standing outreach cadence. | Message sent, channel, template used, timestamp. |
| Payment-plan request | Offer and set up a plan that fits the pre-approved terms the bursar's office has written down. | Any term outside those pre-approved limits. | Same business day. | Terms offered, terms accepted, and the policy version applied. |
| Hardship statement | Recognize the hardship signal and pause every automated contact on the account. | The hardship conversation itself, and any accommodation. | Next business day. | The statement, the pause, and the staff member assigned. |
| Dispute of a charge | Log the dispute and pause contact tied to the disputed amount. | Investigating and resolving the dispute. | Same business day to acknowledge; a separate target to resolve. | The dispute, the pause, the resolution, and who decided it. |
| Bankruptcy or legal notice | Nothing. Flag the account and stop all automated contact. | Every action that follows, on counsel's instruction. | Immediately. | The notice, the date received, and who was notified. |
| Request to stop contact | Apply the stop across every channel it controls, immediately. | Whether any other contact, such as a hold notice, still needs to reach the student a different way. | Immediately. | The request, the channels stopped, and the date. |
| Balance above a set threshold | Continue the standard sequence up to the threshold the bursar sets. | Approval for any plan, discount, or write-off above it. | Institution's target once the threshold is crossed. | The balance, the threshold crossed, and who approved what came next. |
| Student under a hold affecting enrollment | Apply or maintain the hold under written policy, and tell the student how to resolve it. | Any early release, exception, or hold placed outside that policy. | Institution's target for reviewing a release request. | When the hold was applied, why, and every release decision with its approver. |
| Third-party agency referral | Flag accounts that meet the written referral criteria. | The referral decision itself, always. | Institution's target for review before placement. | The account history, the criteria met, and who approved the referral. |
"May act on its own" doesn't mean unsupervised forever: every automated action in the left-hand column still gets logged and is still subject to the review cadence later in this article. The matrix sets where a decision starts, not where oversight ends.
Signals that always go to a person
The situations in the matrix are the ones you can name in advance. In practice, a system spots them from signals in a student's reply or account state, and its job is to recognize the signal and route it, not to judge it. Route on any of the following, every time:
- Hardship language: job loss, a medical event, a request for relief, or anything a reasonable person would read as financial distress.
- An explicit request to speak with a person, however it's phrased.
- Any mention of an attorney, bankruptcy, or a court proceeding.
- A dispute of the amount, the charge, or whether the debt is the student's at all.
- A request to stop contact, on any channel, for any stated reason.
- A reply the system's classifier isn't confident about, including ambiguous or off-topic text.
- Anything that looks like an attempt to manipulate the system into an action outside its rules, such as a message instructing it to waive a balance or ignore its policy.
A model can help here: drafting a suggested reply, or summarizing an account for the person who picks it up. It shouldn't decide the outcome. Nothing sends, waives, or changes terms on the strength of a model's read of a message.
Designing the hand-off so nothing stalls
An escalation that lands in an unmonitored inbox is worse than no automation at all, because the student believes someone is handling it. The hand-off needs the same design attention as the automated sequence.
- Pause automation first
The moment a signal fires, stop every scheduled message on that account before anything else happens.
- Route with context attached
Send the account to the right queue with the balance, history, and the triggering message already attached, so the person doesn't start from zero.
- Set an internal target on arrival
Stamp the case with the response-time target from the matrix the moment it's routed, not when someone opens it.
- Confirm receipt when it matters
For hardship, disputes, and stop-contact requests, send the student a plain acknowledgment that a person has it, separate from the automated sequence.
- Track what's open past target
Report cases still unresolved past their target daily, to a person who can reassign them, not just to a dashboard no one checks.
- Reassign, don't let it sit
A case near or past its target gets a new owner or an escalation to a supervisor, rather than staying with someone who's behind.
What gets logged
The record is what lets a supervisor, an auditor, or a student's own complaint get a straight answer about what happened and why. Log the following for every account, whether the action was automated or a person's decision:
- The channel and timestamp of every contact, and the template or message sent.
- Every system action taken and the rule or policy version that authorized it.
- Every human decision, who made it, and the reason given for any exception to standard terms.
- The account's balance, aging, and hold status at the moment of each action.
- The signal that triggered a route to a person, and when automation was paused.
- The response-time target that applied, and when the case was actually resolved.
- Any agency referral, including the criteria met and who approved it.
Reviewing the boundaries each term
A boundary written once and never revisited drifts out of date: a new payment-plan type gets added, a new agency contract changes the referral criteria, or a hold policy changes for a single term. Set a standing review, not just a reaction to a complaint. The same framework calls for ongoing monitoring and periodic review of the risk management process and its outcomes, with roles and responsibilities and a review frequency clearly defined. [2] We recommend setting that frequency to each term.
- After each add/drop period and each collections cycle, before volume ramps up again.
- Whenever policy changes: new plan terms, a new agency contract, a different hold rule.
- After any near-miss, such as a hardship signal the system missed or a case that stalled past its target.
- At least once a term, even if nothing has visibly gone wrong.
At each review, measure how many cases were routed versus handled automatically, how many students had to escalate a second time because the first route missed the signal, and how often cases missed their response-time target.
When this approach doesn't fit yet
- Your written collections policy doesn't yet cover most of the nine situations. Write the policy first; a matrix can't encode a rule that doesn't exist.
- Volume is low enough that every account already gets individual attention from a small team.
- Contact and consent data is unreliable. Automating outreach on bad data creates escalations faster than it prevents them.
- Bursar, compliance, and the registrar haven't agreed on where a specific line sits, such as which holds count as "affecting enrollment." Resolve the disagreement before it's encoded as a rule.
Frequently asked questions
Which collections actions need human approval?
Anything outside a pre-approved rule: hardship statements, disputes of a charge, bankruptcy or legal notices, requests to stop contact, balances above the threshold the bursar sets, holds placed or released outside written policy, and any referral to an outside collection agency. Standard reminders and payment plans within pre-approved terms can run without a person deciding each one.
Who approves hold release on a payment plan?
A staff member the bursar's office names, not the system. The system can apply or maintain a hold under written policy and tell the student how to resolve it, but releasing a hold early, or outside the written conditions, is a decision reserved for the person your policy assigns to make it.
When should hardship cases escalate?
Routing happens immediately. The moment a message contains a hardship signal, such as a job loss or a medical event, the system pauses automated contact and hands the account to a person, with the message and account history attached, rather than continuing the sequence or judging the hardship itself. The person then responds within the institution's target.
Can AI negotiate payment plans?
Only within pre-approved terms the institution has already written down. A system can offer a standard plan and set it up once a student accepts it. Negotiating outside those terms, such as a longer schedule or a reduced amount, changes what the institution is owed, which makes it a human decision.
What must be logged?
Every contact and decision: the channel and timestamp, the message or template sent, the system action taken and the policy that authorized it, any human decision and who made it, the reason for an exception, and the account's balance or hold status at that moment. A complete log lets a supervisor reconstruct any account's history.
Should holds be placed automatically?
A hold can be applied automatically when written policy sets clear, checkable conditions, such as a balance past a set age. Releasing a hold, applying one outside those conditions, or any hold tied to an open hardship case or dispute, stays with a person to decide, not the system.
Related reading
- Our solution page on higher education collections automation covers the full workflow this matrix sits inside: inputs, integration, and acceptance criteria.
- For the broader principle behind escalation design, see human-in-the-loop AI governance.
- For a supervised-review pattern used outside collections, see document review with human approval.
- If you're scoping the build, AI agent implementation describes how a system like this is designed, tested, and handed over.
Sources
- NIST, AI RMF 1.0 Core (NIST AI 100-1, 2023), GOVERN 3.2 (accessed 2026-09-28)
- NIST, AI RMF 1.0 (NIST AI 100-1, January 2023), Table 1, GOVERN 1.5 (accessed 2026-09-28)
More in Receivables and collections
Claims Scrubbing and Submission: What to Automate vs. What Stays Human-Reviewed
Claims scrubbing and submission: which checks to automate, which stay with a billing specialist, and a matrix to sort your own claim edits by who decides.
Medical Billing and RCM CompaniesAI Agents for Customer Deduction and Chargeback Management in Food & Beverage
Customer deduction chargeback management for food and beverage: a six-step coding and dispute workflow showing what an agent prepares and your analyst decides.
Food and Beverage ManufacturersStandardizing Denial Management Across Clients: An Implementation Guide for Billing Companies
Denial management across clients for billing companies: a five-stage workflow to normalize categories, route work queues and keep appeals with specialists.
Medical Billing and RCM Companies