Collection day, and the morning after
Repayments are collected by direct debit or card. Most succeed. The ones that fail appear in the payment provider's report. Someone in ops copies them into the arrears spreadsheet, looks up each customer, and checks whether they have been in arrears before or have an arrangement in place.
Then the contact starts: emails, texts, calls. Notes go into the helpdesk for some customers and the spreadsheet for others. A customer calls to say they have been ill and agree a reduced payment for a few months. That arrangement lives in a note. Next month, the automated retry runs anyway, and the customer gets a message that ignores what they agreed.
Why arrears handling becomes a spreadsheet
Lending products are built around the loan journey: application, decision, payout, repayments. Arrears handling is added later, and usually starts as a spreadsheet because volumes are small.
- Failed payment events are not turned into cases automatically.
- Arrangements agreed with customers are not stored in a form the product can act on.
- Customer contact happens in several tools, so history is fragmented.
- Retries and messages run on fixed schedules that do not know about arrangements.
- Signs that a customer may need extra care are noted inconsistently.
How you treat customers in financial difficulty, what you say and when, is set by your own policy and advisers. We do not write that policy. We make sure it is followed.
Inconsistency is the real cost
A customer who agreed an arrangement and then gets a standard arrears message loses trust and may complain, with good reason. Contact that is too frequent, or missing altogether, causes problems for the customer and for you. Ops spend time reconstructing histories. When a partner or funder asks how arrears are managed, the answer is a spreadsheet.
An arrears queue built around your policy
What we build is an arrears tool that connects repayment events, customer contact and arrangements.
- Failed repayments from your payment provider create or update an arrears case automatically.
- Each case shows the loan, the missed payments, previous arrears, and every contact across email, text, calls and the helpdesk.
- Arrangements are recorded as structured data with amounts and dates, and the product's retry and messaging schedules respect them.
- Contact steps follow the sequence your policy sets, with templated messages you write, and pause automatically when an arrangement or a flag says they should.
- Flags for customers who may need extra care are recorded in a consistent way and change how the case is handled, following your policy.
- Follow-up tasks appear in the queue on the right date.
- Reports show cases by stage and age, arrangements kept or broken, and contact volumes.
| Case state | What the system does | What ops do |
|---|---|---|
| Payment just failed | Opens case, sends first message from your template | Nothing unless flagged |
| No response | Next step in your sequence | Call if your policy says so |
| Arrangement agreed | Stores terms, adjusts retries and messages | Records the arrangement |
| Arrangement missed | Reopens case, alerts ops | Contact the customer |
| Extra care flag set | Pauses automated steps | Handle by your policy |
A queue ops can trust
Ops start the day with a list of cases due for action. Each case tells the full story. Arrangements are honoured automatically, so customers who agreed something are not chased as if they had not. The spreadsheet retires.
Does this match your arrears handling?
- Failed repayments are copied into a spreadsheet.
- Arrangements live in notes.
- Automated retries or messages have ignored an arrangement.
- Contact history is split across tools.
- Nobody can list cases by stage and age.