How collection agencies can use AI to rank call priorities

The morning list

At the agency, you begin the morning with more accounts asking for a call than your team can handle. The useful question is not which accounts look promising in the abstract. It is which call deserves one of the available places today, and which account can receive the cheaper treatment instead. The demo book makes that pressure concrete: 20,000 accounts produce 6,000 requested calls each day, while the available team can make only 1,500.

That pressure turns segmentation into a call priority score. The score can read whether a promise to pay is falling due, when the account holder is paid, and whether the team has reached the right party. Those details matter because the score is answering a treatment question: where does a call add enough expected value over the cheaper treatment to use scarce agent time?

The spare-call problem is not a rounding issue in this book. At six minutes per call, 25 agents working six calling hours can make 1,500 calls against the 6,000 the accounts are asking for, leaving 4,500 for another treatment each day. The team would need 100 agents to make every call. A priority score therefore has to decide whom to call and whom to leave to SMS or another treatment.

Call timing

The first change in the order is timing. In group B, whose pay date is within three days and where the right party was reached before, the same €9 agent call is worth €21.80 per account today and €39.40 on the pay date. Its cure rate is 14.0% today and 22.0% on the pay date. Those are inputs for this demo book, not a general collections result. They give the team a timing test: compare the treatment on the day it is actually available, rather than treating the account’s payment cycle as background detail.

Call value

The treatment beside the call changes the order too. In group A, where a promise to pay is falling due, an agent call adds €4.10 per account over an SMS reminder. Group C, where there has been no right-party contact yet, points to a different choice: an agent call today is worth €4.50 less than SMS, while skip trace then call adds €2.50 over SMS. An account with no right-party contact raises a different question from an account nearing its pay date: whether finding the right person should come before spending agent time.

Those margins put group B on the pay date first, group A next, and group C after the right party has been found. The calculator selects an agent call for A, an agent call on the pay date for B, and skip trace then call for C. On the available counts, none of the three selected treatments is clearly ahead of its runner-up.

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

Start free See pricing

Learning the order

A priority score needs outcome history attached to each call decision, not just a list of accounts and their eventual results. The comparison measures what a treatment adds only when accounts in a group are sent to each treatment at random, as in the fork’s random split, and the demo’s treated and cured counts are read that way. In this call book, the outcome is the cure: the account paid or kept to a payment plan. Record it against the call decision, with the horizon in the outcome name, because a pool in which half the accounts have not matured will pull any rate towards zero. From that labelled history, rule mining can propose groups like the three in the demo, using one- or two-condition rules joined with AND. Roughly seven rows in ten train the candidates and the rest validate them, so the validated rate is the one to trust. The support floor is 30 rows by default. When the cure rate is low, that floor needs to rise because a rule can otherwise rest on only a handful of accounts that did not cure. “No rule survived validation on this pool” is a useful result. Widen the window before lowering the floor.

Policy mining can fit the call priority score a person can read from facts such as whether a promise to pay is falling due, whether the pay date is within three days, and whether the right party was reached before. Each predictor is cut into bins, and the bins receive points that combine into one score.

The bins are checked from top to bottom, with the first match winning, and a missing-value bin catches empty or missing information, such as an account with no promise on record. The scorecard must be measured on rows it never saw as well as on the rows used to fit it, so the priority order does not merely look right on last quarter's calls.

A large gap says that the fit learned the training book too closely. An out-of-time split then measures early rows against later ones, which is the more honest test for a priority order used on the next batch, and identifies characteristics whose behaviour did not hold across periods.

That comparison can include a challenger fitted on the same rows, such as gradient boosting or MARS, and the challenger and scorecard can be compared on the same validation rows. The comparison does not change the policy by itself.

A mined rule becomes a proposed revision of a rule set, its backtest is queued, and nothing is deployed until someone releases it. “Ask AI to review” examines the scorecard’s bin boundaries and returns a proposal for a person to approve before the refit, with any override recorded as that person’s.

The tempting ranking

The three selected treatments are not clearly ahead of their runners-up, so the operating order should remain open to checking.

A sensible shortcut available to you is to rank people by how likely they are to pay within 30 days of falling behind. The site’s call-order trial tested that shortcut against the old order, using 3,000 borrowers run twice with the same luck. It produced 3,995 promises against 3,502, but collected 14,277 against 14,525 and the balance over 90 days was 384 against 102. More promises did not produce more collected cash in that trial. The score had sent calls towards people likely to pay anyway, while harder accounts aged. The useful ranking is the value the call adds over the cheaper treatment, not the likelihood that payment will happen without that call.

The next batch

On the next batch, put the treatment comparison into a released decision flow before the call list is made. Batch processing runs every record through that flow and returns the updated dataset, so the priority order has a repeatable place in the operation instead of being rebuilt by hand. The calculator’s treatment table can be copied into a decision table with the account group as the condition and the treatment as the result.

Keep that check honest by sending a known share of the records to a challenger branch and comparing its later outcomes with those from the primary score. A fork can send a random number below 0.5 to one branch and every other value to another, with a final branch ready to take any value.

The person responsible releases the revised rule set or scorecard into the fork, with the score on one branch and the challenger on the other. The branches are compared on the cures that later come in. The one habit to adopt is simple: compare the order you are using with an alternative on the same batch before changing what the agents see.

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

Start free See pricing