Skip to main content
Finance → Collections → Worklist → /collections/worklist Beta The worklist is the officer’s day. It is one ranked grid of open cases with quick-view chips over it; the case workspace is where each one is actually worked.

​
The worklist grid

​
Quick views

Chips above the grid apply named filters. They are combinable, clearable, and written into the URL, so a filtered queue can be bookmarked or shared. Other operational queues are filters over the same grid rather than separate screens: my cases, new, broken promises, not yet contacted, unreachable, high value, pending approval, and recently paid (clearing).
Sort by Priority and work top-down. Priority already blends size of debt with likelihood of recovery, so it beats sorting by balance alone.

​
The case workspace

/collections/cases/{uuid} The case header shows the tenant and unit, gross due and wallet, net balance, oldest due date, aging bucket, band with a plain-language explanation of the score, the assignee, the treatment state and the next action.

​
Tabs

​
Actions on a case

​
Logging an interaction

Every contact attempt is recorded so any officer can pick the case up cold.
  • Channel — call, SMS, WhatsApp, email, letter, visit, meeting, or note.
  • Direction — inbound or outbound.
  • Contact person and the number or address actually used.
  • Right party — whether you actually reached the person responsible.
  • Outcome — no answer, unreachable, wrong number, delivered, read, contacted, disputes, requests statement, promises, unable to pay, requests restructure, paid, third party, or follow up.
  • Follow-up date, notes, and attachments.
Outcomes drive the workflow, they are not just a log:
  • promises deep-links into recording a Promise to Pay and pauses the ladder;
  • disputes flips the treatment state and takes the disputed amount out of ladder triggers;
  • follow up puts the case in your follow-ups due queue on that date.
Messages the engine sends automatically log an interaction too, so the timeline is complete without anyone entering the same thing twice.

​
Case lifecycle

  • An active promise pauses ladder steps that are marked to pause on promise.
  • A broken promise resumes the ladder, raises severity and stages a follow-up task.
  • A payment that drops net balance below the exit threshold moves the case to clearing; it closes after a confirmation window, with hysteresis so a case does not flap open and closed on small movements.
  • Reopening creates a new case linked to the previous one, rather than resurrecting the old one — so per-cycle metrics stay honest.

​
Approvals and audit

High-impact actions route to the approvals inbox rather than firing directly: issuing a demand letter, handover, fee waiver, hardship restructure, and closing a case with a write-off. Approval or rejection lands on the case timeline with the decider and their reason. Every console mutation is audited. Hold, skip and score override require a reason before they will save.
1

Read the debt breakdown first

Know whether you are chasing rent, utilities, or a penalty — the conversation differs, and so does what the tenant will accept.
2

Check the wallet figure

If there is unallocated cash, the fix may be an allocation, not a collection call.
3

Check Related

A tenant with three leases should get one conversation, not three.
4

Contact, then log the interaction immediately

The outcome you pick is what schedules your next step.
5

Record any commitment as a promise

A promise in the notes field is invisible to the engine; a recorded promise pauses the ladder and is evaluated automatically.
6

Confirm or skip the staged action

Leave nothing staged and unattended — a stale staged action is the most common reason a case stalls.