Collections
Prepare every overdue payment message, then approve them in one pass.
How an agentic application drafts the right follow-up for each overdue account using payment history, agreements and previous conversations, and why sending stays behind approval.
Direct answer
Can software actually do this?
Chasing is slow because each message needs different context, not because writing is hard. An agentic application reads the account, the payment history and the previous conversation, then drafts the appropriate follow-up for each overdue customer. A person reviews the batch and approves. The application sends only what was approved, records it and updates the account.
How it gets asked
The request, in the words people already use.
These are not prompts to be learned. They are the sentences a manager says to a colleague, which is the standard an agentic application should meet.
- “Draft a chase for everyone who is overdue, and let me check them.”
- “Who has been chased already, and what did we say last time?”
- “Do not chase anyone who is on a payment plan or has an open dispute.”
- “Write a firmer follow-up for the accounts we have already reminded twice.”
- “Show me what would be sent before anything goes out.”
Where this comes up
The current situation
The same message to everyone is ignored. A different message to everyone takes a day.
Automated dunning sequences treat a long-standing customer with one late invoice the same as an account that has ignored three reminders. So the sequence gets softened until it does nothing, or people write each message by hand and the chasing happens whenever there is a quiet afternoon. Neither is a system. Both damage either the cash position or the relationship.
- Chasing slips whenever the person who owns it is busy.
- Good customers receive a tone that does not match the relationship.
- Accounts on an agreed plan get chased anyway, which costs trust.
- Nobody can see what was said last time, so the escalation restarts.
- The decision to escalate is made on a balance, without the history.
What the answer depends on
The application has to read all of this, not one system.
The reason this work stays manual is rarely difficulty. It is that the answer lives in several places and only a person currently holds them together.
Overdue position
What is outstanding, since when, and against which invoices, taken from the ledger.
Payment behaviour
Whether this is a first slip or a pattern, and how this account has responded to previous reminders.
Agreements and plans
Payment terms, agreed plans, disputes and anything already settled by conversation.
Previous contact
What was sent, when, by whom and what the customer said in reply.
Policy
The escalation ladder the business has agreed, including tone, timing, thresholds and who may authorise each step.
What the application does
The job, step by step.
Each step is either ordinary application code or a bounded piece of reasoning. Knowing which is which is the difference between a system you can operate and a demonstration.
Select genuinely chaseable accounts
Overdue by the agreed definition, with no open dispute, no agreed plan in good standing and no reminder sent inside the minimum interval.
Establish where each account sits on the ladder
First reminder, second, final notice or escalation, based on what has already been sent rather than on the balance alone.
Read the last conversation
A customer who explained the delay last week needs a different message from one who has not replied at all.
Draft in the voice of the business
Each message is prepared against the approved template and tone for that ladder step, with the specific amounts, invoice numbers and dates filled in from the record.
Flag what should not be sent
Accounts where the agent has low confidence, where records conflict, or where sending would be a mistake are separated for a decision rather than dropped in with the rest.
Present the batch for approval
A person sees every draft with its reason and its evidence, edits what needs editing and approves in one pass.
Send only what was approved
The application sends through the normal channel, from the normal identity, with idempotency so a retry cannot double-send.
Record and close the loop
Every message sent is written back to the account, the ladder position advances and replies are routed to the person who owns the account.
Worked example
What a useful answer actually looks like.
Prepare this week overdue follow-ups for the Northgate site. Nothing goes out until I have seen it.
Invented accounts. This shows how a batch is presented for approval, including the items the application refuses to send on its own.
| Account | Proposed action | Reason |
|---|---|---|
| Bay 31 · Okafor | Second reminder, firm | First reminder sent 27 August, no reply. Promise-to-pay of 30 August passed. £150 outstanding, 9 days. |
| Bay 27 · Nadeem | Explain the short payment, do not chase | Not avoiding payment. The standing order still pays the pre-upgrade rate. The message explains the £18 difference and how to fix it. |
| Bay 63 · Ashworth | No action | On a payment plan agreed 11 August and up to date with it. Chasing would be wrong. |
| Bay 08 · Delaney | Hold for a decision | Overdue, but there is an unresolved complaint about a leak from 22 August. Escalating over money while a service issue is open is a judgement call for a person. |
| Bay 44 · Marsh | First reminder, warm | Eleven months of on-time payment, seven days late once. The tone reflects that. |
| Bay 19 · Cato | Hold, records conflict | The ledger shows the invoice unpaid, the site log records a cash payment on 1 September. Nothing should be sent until that is reconciled. |
Two of the six are not chases at all, and two are held. That is the actual output of good collections, and it is precisely what a fixed dunning sequence cannot produce.
Stays in ordinary software
What must never depend on a model.
- What counts as overdue, and the minimum interval between reminders.
- The escalation ladder, its thresholds and who may authorise each step.
- Suppression rules for disputes, plans, legal holds and closed accounts.
- Idempotent sending, so an approved message goes out exactly once.
- The record of what was sent, to whom, by whose approval and when.
Where reasoning earns its place
What genuinely needs judgement.
- Choosing the right message for this account rather than the next template in a sequence.
- Recognising that a short payment is a billing problem, not a collections problem.
- Reading a previous reply and adjusting what is said next.
- Identifying the accounts where sending anything would be a mistake.
- Explaining the reasoning well enough that a batch can be approved quickly.
Control boundary
What keeps this safe to run.
Autonomy is not a setting. It is the sum of the scope, the tools and the approvals the application has been designed to enforce.
Chasing a customer is external communication about money. It gets a named approver and a recorded decision.
Disputes, plans and holds are checked by the application, not left to the agent to remember.
A defect should be capable of preparing a hundred wrong drafts and incapable of sending them.
Final notices, legal steps and account restrictions require the authority the business already assigns to them.
Every sent message, ladder change and account note is recorded so a mistake can be found and corrected.
Deliberate limits
What it does not do.
- It does not decide to escalate to legal action or restrict access.
- It does not send without approval in an early release, whatever the balance.
- It does not chase an account with an open dispute or an agreed plan.
- It does not charge a card, take a payment or amend a balance.
- It does not resolve the underlying billing error. It surfaces it.
How you know it works
The evidence to require.
- A sample of drafts is reviewed for tone, accuracy and appropriateness before any release.
- Suppression rules are tested with deliberately awkward accounts.
- Approval and edit rates are measured. Heavy editing means the context is wrong.
- Reply and payment outcomes are compared with the previous manual approach.
- Every complaint about an inappropriate chase is treated as a defect and traced.
A sensible first release
Narrow enough to trust, complete enough to be useful.
The first version should be able to fail without costing anything, while still producing an answer somebody would miss if it disappeared.
One site or segment, drafts only, no send capability at all.
The escalation ladder and suppression rules written down and agreed.
A person approves every batch and their edits are captured.
Sending enabled only for the mildest ladder step once edit rates are low.
Higher steps remain manual until there is evidence, and some should stay manual permanently.
Common questions
Questions about collections.
The questions that should be settled before anyone builds this.
Why not just use the dunning feature in our accounting software?
If your accounts behave uniformly, do. Sequenced dunning works well when the only variable is how late the invoice is. It struggles when the right message depends on why the payment is short, what was agreed on the phone last week, or whether an unresolved complaint makes chasing a mistake. That judgement is the part worth building.
Will it send emails to our customers automatically?
Not in a first release, and possibly never for the firmer steps. Chasing money is external, reputational and hard to take back. The sensible pattern is drafts plus one-pass human approval, then automating only the mildest step once there is measured evidence that the drafts are consistently right.
How does it know we already spoke to someone?
Because the previous contact is part of the context it reads: messages sent, call notes recorded, replies received and any commitment logged. If your business keeps that history only in individual inboxes and memory, that gap has to be closed first. It is usually the cheapest part of the project and the most valuable.
What if it drafts something inappropriate?
A person sees it and does not approve it, which is the point of the design. The draft is also a signal: an inappropriate message usually means the application withheld context or the suppression rules missed a case. Both are fixable in ordinary code, and both are cheaper to find in a review queue than in a customer complaint.
Related use cases
How Codemind builds it
Start with the job
Bring the request, the systems and the person who does it today.
You do not need a specification. We will separate what belongs in ordinary software from what genuinely needs reasoning, and describe a first release that can prove itself.