/collections/strategies Beta
A strategy (dunning ladder) is the recovery policy expressed as an ordered list of steps. It is
what makes collections repeatable: the same debt, at the same age, in the same band, gets the same
treatment regardless of which officer picks it up.
Anatomy of a strategy
A strategy is org-scoped, named, and versioned by activation — you activate a new version rather than editing history under in-flight cases. Each step carries:Action types
Strategy-level guards
Default ladder (built-in)
Until someone authors a strategy, the engine is not idle — it falls back to a built-in ladder, so a new organisation gets sensible shadow-mode recommendations from day one with no setup. The Strategies page shows it read-only, along with whether your organisation is running it today.
Guards: max 2 contacts per week, no band restrictions, no approval steps.
It is deliberately conservative — reminders and one human task, nothing else. There is no demand
letter, no penalty and no IoT enforcement step in the fallback: those only ever fire from a
strategy an administrator authored and activated. You cannot edit the default ladder; create a
strategy and assign it at the scope you want, and it takes over from the fallback there.
Case policy snapshots apply to the fallback too — a case opened under the default ladder carries
these steps on its snapshot, so a later product change to the built-in ladder never rewrites
in-flight cases.
Choosing the ladder by band
Bands are the reason a strategy is not one-size-fits-all. The engine scores every case 0–100 on arrears age, debt-to-rent, payment recency and regularity, kept vs. broken promises, contact responsiveness and trend, then files it in a band. Bands are computed and refreshed as the case moves — there is nowhere to create one by hand, and a case with no history starts at C.
In short:
- A / B (likely to pay) — light touch. A reminder and an offer to arrange payment. Escalating a reliable payer over a one-month slip costs you the relationship and gains nothing.
- C — the standard ladder.
- D / E (unlikely to pay) — escalate faster and further: demand letter, enforcement link, handover. These cases also float to the top of the worklist because priority weights low scores heavily.
Which strategy applies where
Strategies are structured records, but which strategy applies to a given lease is a setting, resolved through the standard scope chain:Policy snapshots
When a case opens, the resolved strategy and thresholds are copied onto the case. Changing a strategy therefore affects new cases and does not retroactively rewrite what an in-flight case was promised. If you genuinely want an open case moved onto the new policy, use the explicit re-baseline action — it is audited.Building a strategy
1
Write the ladder down first
On paper: what happens on day 5, day 15, day 30, day 60. Ladders built directly in the UI tend
to acquire steps nobody can justify.
2
Create the strategy
Strategies → Add. Name it for the population it serves (“Residential — standard”, “SME
commercial”), not for the current month.
3
Add steps in order
Set the trigger delay, action, template and band range for each. Mark severe steps as requiring
approval.
4
Set the guards
Contact cap and permitted channels. This is the control that stops a tenant receiving four
messages in a day from three different steps.
5
Attach templates
Every reminder and letter step needs a published template. See
Templates & broadcasts.
6
Assign it by scope
Set the strategy setting at the scope you want it to apply to.
7
Run in shadow and read the staged actions
For at least one full cycle, review what the engine would have sent before you let anything
go out.