Turning 12,462 accounts into a day of work a collector can act on

Financial Information Systems builds the collections platforms banks run against overdue loans. Meridian is a large retail bank in a high-delinquency consumer-credit market, and it runs collections in-house — a floor of collections officers working a queue by phone all day, on quota, with a handful of seconds per account before they decide whether to dial.

This is the early-stage side of that work: accounts from a first missed payment up to the point where the debt goes out to field agents. Past ninety days it leaves this product entirely and becomes someone else's job — the outdoor collectors carrying the mobile field app. Same bank, same portfolio, a different room.

I was the only designer on it. Twenty weeks, one PM, four engineers, one ML engineer, and a standing group of bank-side stakeholders — their PM, Collections Ops, Risk, Compliance and IT. The bank already had a repayment-probability model in production. My job started where that model's output hit the screen.

That line is the product as the collector met it. Twelve thousand rows, twenty-one columns of equal weight, six hundred and twenty-three pages, seven filters and a sort. The repayment-probability score — the expensive part, the thing the ML team had built — sat in column nineteen, between Risk and Collector, weighted exactly the same as Last Payment Date.

I walked the legacy screen finding by finding. Eight of them, all visible at once:

1. The score is a column, not a signal. Nineteenth of twenty-one.
2. Twenty-one columns, all equal weight. The interface has no opinion about what matters.
3. A database view, not a workload. 12,462 accounts matching criteria. Page 1 of 623.
4. Prioritisation handed back to the user. Seven filters and a sort; the collector constructs priority herself.
5. Nothing on the row answers “why”. The reasoning lives one click away, inside a panel that is itself a wall of data.
6. No action guidance. Three buttons, with Set Payment Plan styled primary on every account.
7. No eligibility state exists. Nothing here can say “do not work this account today”. The only status is Overdue.
8. Recency is invisible. A promise broken yesterday looks identical to one broken in March.

Every row looked like every other row. So collectors worked the list from the top down — and when they didn't trust the order, they re-sorted by days past due or last update and worked that from the top down instead. Three things they told the bank, in their own words:

• “I don't know why this account is first.”
• “A high score doesn't necessarily mean I should call them.”
• “I still have to do the thinking myself.”

Findings about a screen are easy to argue with, so I stopped auditing the interface and audited the decisions instead. A collector makes four in a morning. I wrote down what each one requires, what the system gave her to make it with, what was missing, what she did instead, and what that cost the bank.

That table is what reframed the project for me. The system had automated the ranking — the one part that was already automatic — and left every decision after it manual and unsupported.

Four of them shaped everything, and none were negotiable.

1. Eligibility is law, not preference. An account under an active payment holiday, in restructuring, with an open dispute, or carrying a no-contact request cannot be worked. Calling that customer isn't inefficient — it's a compliance breach. On any given morning around forty-seven of the assigned accounts were in one of those states.
2. The scoring model was out of scope. It was in production, it had been paid for, and phase one was not going to touch it. I had an ML engineer on the team and no permission to change what the model produced — only what happened to the number afterwards.
3. Twenty-one columns, each with a requester. The legacy table was years of stacked requirements. Every column had someone in the bank who had asked for it and would notice its absence. Nothing had ever been removed, only added.
4. The data was better than the screen. The bank already held contactability, best time to reach, and payment-pattern history. None of it reached the interface. Some of the other signals I wanted turned out not to be reliably available at all — which I found out later than I should have.

Before drawing anything I opened five products in the category and read them properly — what they lead with, what they bury, what they sell as the headline feature.

I took three things and deliberately left two. The pattern across all five: they explain the action. None of them explain the ranking. That is an observation about what I could see, not a claim about the whole market — but it lined up exactly with the bank's own logged complaint, “I don't know why this account is first.”

Collections vendors gave me the structure — eligibility, prioritisation, treatment — but they are not where anyone has solved the craft problem of a person reading several hundred rows a day. For that I went outside the category, to the tools people actually live in: project trackers, document workflows, comms apps.

I collected reference screens into three boards, one per problem I had, and annotated each with the specific pattern I wanted rather than the general impression:

• Working space — grouping and bundles instead of a flat list, wide table rows, the total sitting next to the title, a 0 of 3 completion state, a status stroke down the side of a row rather than a badge inside it.
• Details and activity — a timeline-style activity log, a summary rail on the right, caption text that explains why and how next to a value, an explicit “add the missing details” affordance.
• Submitting information — what a call-logging dialog should carry, a recommended action offered after the call rather than before it, and inline hints that sit inside the dialog instead of in a help article.

Almost every decision on the finished row — the side stroke, the tabular figures, the count beside the band title, the completion counter — traces to one of these notes. The banking products told me what the stages were; these told me how a row should behave.

The bank had also raised a shadow-workflow problem: collectors were managing their day outside the platform. So I asked what they were actually using. The answer was a spreadsheet, a sticky note, and a running Word document — and each one was a feature request nobody had written down.

The spreadsheet was a prioritised day's work. The sticky note said call after six, which was contactability data the bank already held and had never put on screen. The Word document was an activity log with nowhere to live. Those three artefacts did more for the design than any workshop did.

Everything then went into one synthesis matrix — the observation, the business cost, the user need, and the thing to build. That matrix is what I argued from in the stakeholder sessions, not the screens. It meant every feature I proposed could be traced back to a specific complaint and a specific number, which is the only way a design argument survives a room with Risk and Compliance in it.

The brief I was given was narrow: surface the repayment-probability score in the queue so collectors can sort by it. Move a column, add a sort control.

Their case, put properly. They had a working model that had already been paid for, and a complaint that collectors were ignoring priority. Read that way, the fix is obvious and cheap — the score is buried in column nineteen, so promote it and let people sort. It ships inside the current release train. It needs no migration, no retraining of several hundred collectors, no rewrite of the QA scripts Collections Ops had built around the existing table, and no new conversation with Compliance. Against a twenty-week window, a two-week change that touches nothing is a genuinely good answer, and I'd have proposed it myself if it had worked.

My case. The audit had already shown me the collectors could sort. They were sorting — by days past due, by last update — precisely because they didn't trust the score. Giving them a better sort control answers a question they had answered for themselves months earlier. Sorting by a number nobody trusts only moves the problem further up the page.

The argument that actually landed wasn't about trust, though. It was compliance. Take two accounts: Customer A scores 91 and ranks first, and is on an active payment holiday — she must not be called. Customer B scores 68 and ranks 340th, broke a promise yesterday, and answers on the first call. Rank-then-filter puts A at the top of the list and asks a human to catch it. Filter-then-rank means A never appears and B is first.

That reframes eligibility from a preference into a gate, and a gate can't be a sort order. Once it was a compliance question rather than a UX question, the argument was no longer mine to win — Risk made it for me. The brief I took was to make the score explainable and actionable: who to call, and what to say when they answer. The column move happened too. It was a consequence of the work, not the work.

The score was being asked to answer three different questions at once: can we contact this account, does it matter most, and what should we do about it. Those have different owners and different rules — the first is compliance, the second is the model, the third is treatment policy — so I split them into three stages and fixed the order.

Eligibility first: hard rules and compliance, accounts removed before ranking rather than after. Prioritisation second: the existing score, plus recency. Next best action third: treatment logic. The collector meets them in that order because that's the order the decision actually gets made.

The rule I held everything to: a hard rule shows as fact, a compliance rule shows as a constraint that can't be overridden, and a prediction is labelled as a prediction every single time it appears. None of this touches the scoring model — that was the phase-one constraint, and the architecture respects it. The triage moves to the system; the judgment stays with the collector.

The clearest way to see the change is the journey. Before, nine steps and seven of them were the collector's: open the account, search through the data, interpret the context, decide the priority, decide the action. The system handed over a score and left her to build the workflow on top of it.

After, nine steps and three are hers — review, execute, log. The bank had a system of record. What it needed was a system of work.

The queue no longer opens on a portfolio. It opens on a day: twenty-eight accounts assigned, grouped into four bands — act today, act this week, scheduled, no action. The portfolio count is still there, in the corner, at the size it deserves.

Three decisions carry this screen:

• Blocked accounts are lifted out of the ranking, not sorted to the bottom of it. Forty-seven held back today, with the reasons named, and a way to review them. Held back is a state, not a low position.
• Every row says why. Two or three reason chips under the name — promise to pay broken yesterday · pays after direct contact · no arrangement in place — drawn from the inputs that would change the action. Not all nine, because nine would recreate the legacy screen.
• “No action” is a band, not an absence. An account that is paying on schedule appears, marked as needing nothing, with a review date. Deciding not to call is a decision, and the system should show that it was made.

There's one interactive element per row. The eye lands on the urgency edge, then the name, then the action — three stops, in the order the decision gets made.

Opening an account used to mean assembling a picture from a balance, a stage, a risk level and a free-text note left by whoever called last. Now the screen leads with why this customer is here — the same reasons from the queue row, expanded into evidence: agreed €500 on 6 August, no payment received; three of her last four payments followed a phone call; nothing currently protects either account from rolling to thirty days.

Restrictions sit above the balance, not beneath it. Contact attempts, promises and payments run as one timeline instead of three tabs. The recommended action is a recommendation with its reasoning shown and an override always available — and “something here is wrong” is a link on the reasoning itself, because a collector disagreeing with the ranking is information the system should capture, not friction it should absorb.

Three actions carry almost all of the volume — call, message, arrange — and each one got a different container, chosen by how much of the screen the collector still needs while it's happening.

A call is a widget, not a screen. While she's talking she needs the reasons, the balances and the indicative plan all still in front of her, so the call docks into the corner and takes nothing away. It carries only what belongs to the call itself: the timer, who's on the line, identity confirmed, mute, keypad, note, end. 3 checks left sits in the header — the identity checks the bank requires before discussing an account, counted down where she can see them rather than buried in a script.

Sending an SMS is a drawer that argues before it sends. This is the screen I'd point at first if someone asked what the whole project was about, because almost none of it is a form:

• It opens by telling her not to bother if she shouldn't — two automated reminders already sent, 5 and 8 August, neither was opened. The system knows that; the legacy tool would have let her send a third.
• The recommendation says why it's a text and not a call — a text is cheaper, and likely enough — against a reason chip on the account reading likely to self-cure: accounts with this pattern paid without contact in 8 of the last 10 cases.
• The default send time is 18:00, and it explains itself: two of his last three replies came after six. That is the sticky note from the research board — call after six — generated from data the bank already held and printed on the control instead of stuck to a monitor.
• The compliance line sits under the message, not in a policy document: registered sender ID, opt-out included, within permitted hours.

The template is filled from the account, and the character and segment count are shown because the bank is billed per message. None of that is clever. It's just the reasoning a good collector already does, done where the decision is made.

The last piece is the part that keeps the queue honest. When a call ends, the outcome gets recorded in the flow of the work — a dialog over the account, not a separate screen — and it names its own consequence before you commit: she returns to the queue as No action until 14 August.

It also draws a line the legacy system never drew. Logging an expected income date is not a promise to pay; it schedules the next contact without creating a commitment the customer can break. The distinction matters to Risk, and it matters to the collector who inherits the account next week.

The outcome feeds the ranking, so the queue isn't frozen overnight. That was the difference between a report and a workspace.

1. A better score wasn't the answer. The model was fine. What was missing was everything around it — the eligibility gate in front, the reasoning beside it, the action after it.
2. Automation has to be explainable or it gets ignored. A collector who can't see why an account is ranked first falls back to the order the list already gives her. Intelligence without explanation doesn't get overruled; it gets bypassed quietly.
3. “No action” is a valuable decision. The legacy system had no way to say “do not work this account today.” The only status was Overdue. Giving the collector a way to decide nothing was needed — and have the system record it — removed more unnecessary contacts than the ranking did.

What I'd do differently. Two things. I'd get in front of collectors earlier — we spent too long at the start trying to understand the legacy score through data, when watching how collectors actually worked would have got us to the same reframe faster and with less argument. And I'd bring data and engineering into discovery sooner: some of the signals I designed around turned out not to be reliably available in the existing system, and I found that out after the screens existed rather than before.

The first group describes the work. The second was measured by the bank's own research team after rollout — those are their figures, not mine.

• 12,462 → 28 — accounts in the portfolio, versus accounts assigned for a day.
• 623 → 4 — pages of queue, versus bands of work.
• 21 → 6 — columns on the legacy row, versus elements on the new one: name, three reasons, two figures, one action.
• 7 → 3 — steps in the nine-step journey that the collector has to carry.
• 20 weeks, one designer, one PM, four engineers, one ML engineer, plus bank-side PM, Collections Ops, Risk, Compliance and IT.
• 5 products read as prior art — three borrowed from, two deliberately not.

• 58% faster time to decision.
• 76% correct action selection.
• +34% accounts processed per day.
• −31% unnecessary contacts.

And what the collectors said afterwards:

• “Now I can see why it's on my list before opening the account.”
• “I can see the next action without opening the whole customer record.”
• “This is closer to how I actually think about my work. What happened? What needs to happen now?”