What a collections flow engine actually does

A recovery strategy is a set of rules about who gets contacted, on which channel, in what order, and what happens next depending on how they respond. Almost every lender has one. Very few have it in a form a machine can execute, which is why the strategy that gets applied on a Tuesday afternoon in a busy month is rarely the strategy that was designed.

The three ways a strategy usually lives

• In a document. Accurate, complete, and applied only as well as the person who last read it remembers.
• In a set of filters and allocation rules. Better, but static: it decides who to call and then stops having an opinion.
• In a flow engine. The strategy runs as a graph, one borrower at a time, and keeps having an opinion after every contact.

The part people underestimate: waiting

Drawing the happy path is easy. Reminder, call, escalate. The difficulty is that collections is mostly waiting, and the waits are the strategy. A run parks after a message goes out and resumes when the delivery receipt arrives, or when it does not. It parks after a field visit is dispatched and resumes on the officer outcome. It parks on a promise and resumes on the due date, taking one branch if the money arrived and another if it did not.

An engine that cannot park is not an engine, it is a batch job. The test is simple: can a single borrower journey stay open for six weeks, survive three restarts of the system, and still take the correct branch when a delivery receipt lands on day forty-one?

Branches are where strategies get honest

A flow forces a decision that documents let you avoid. Every node has to say what happens on every outcome, including the ones nobody likes to plan for: the number is wrong, the borrower disputes the amount, the agent never picked up the queued account, the payment gateway timed out. Drawing the graph surfaces the gaps, because an unhandled branch is visible as a dead end rather than invisible as an assumption.

What the engine has to know that a workflow tool does not

• Contact windows and frequency caps, checked at dispatch rather than at design time.
• Do-not-contact state, honoured across every channel at once rather than per channel.
• Which campaign and which file a borrower currently belongs to, so a strategy change does not double-contact them.
• Language, so the message that goes out is in the one the borrower actually reads.
• Cost, because a flow that escalates everyone to field visits is technically correct and commercially absurd.

How to tell a real one from a diagram

Ask to see a run that is currently parked, and what it is waiting for. Ask what happens if the signal it is waiting for never arrives. Ask to change one branch on a live strategy and watch whether the accounts already mid-journey adopt the change or finish on the old graph, and whether anybody can tell you which of those two happened. A tool that cannot answer those three questions is drawing pictures of a strategy rather than running one.