Debt management software fails when it treats a case as a record instead of a lifecycle.
That sounds like a product-design distinction, but it becomes operational very quickly. A person in financial difficulty does not move through a neat sales funnel. They move through assessment, evidence gathering, advice boundaries, creditor contact, affordability work, proposal or plan setup, payments, reviews, changes in circumstances, missed payments, closure and sometimes failure.
Each stage has different risks. Each stage needs different permissions, documents, messages, ownership and audit history.
If the platform flattens all of that into a generic CRM record, the team ends up running the real case in notes, spreadsheets, inboxes and staff memory. The software may have the customer's name, address and balance. It still may not know what state the case is in.
This article is not debt advice. Anyone dealing with debt should use appropriate free, impartial or regulated advice routes. This is a practical view of the operational lifecycle that debt management and IVA/DMP platforms have to respect.
DMP and IVA cases are not the same journey
The first thing a platform has to respect is that different debt solutions have different operating models.
GOV.UK describes a Debt Management Plan as an agreement between a person and their creditors to pay debts, often used where someone can only afford a small amount each month or expects to resume repayments later. That matters operationally because a DMP platform needs to support affordability, creditor contact, payment scheduling and later review without pretending the arrangement is the same as a formal insolvency route.
An Individual Voluntary Arrangement is different. GOV.UK describes an IVA as an agreement with creditors to pay all or part of debts, with regular payments made to an insolvency practitioner who distributes money between creditors. It starts when creditors holding 75% of the debt agree to it, after which it applies to all creditors. Citizens Advice also describes an IVA as a formal and legally binding arrangement.
That means a platform should not pretend DMP and IVA cases are only different product labels. They have different suitability questions, evidence requirements, creditor interactions, failure modes and review patterns.
The lifecycle model has to start before a solution is selected.
The stages that matter
Every business will have its own process, but the core lifecycle usually needs at least these stages.
1. Initial enquiry and triage
At the beginning, the system should capture the enquiry source, customer contact route, consent, urgency, vulnerability indicators and whether immediate signposting is required.
This stage is not just lead capture. It is the first risk boundary. If someone is in urgent difficulty, dealing with priority debts, facing enforcement action or unsure what route applies, the platform needs to support careful triage rather than pushing them into a product-shaped journey.
Breathing Space is a good example of why this matters. GOV.UK explains that eligible people in England and Wales can receive temporary protection from creditors while they get debt advice and make a plan. A debt platform does not need to turn that into advice content, but it should not ignore time-sensitive protection routes when designing case state and signposting.
2. Fact find and evidence
The fact find is where many systems start looking busy but not necessarily useful.
Income, expenditure, assets, debts, creditors, arrears, household circumstances and payment capacity all need to be captured in a structured way. The important point is that evidence should map to decisions. If a payslip, bank statement or creditor balance is uploaded, the system should know what it supports and whether it is complete enough for the next stage.
Free-text notes are not enough. They are useful context, but they are weak workflow state.
3. Assessment and route selection
Before a case moves into a DMP, IVA or other path, the platform needs a controlled assessment stage. That does not mean the software gives advice on its own. It means the workflow makes the human decision visible.
What options were considered? What information was available? What was explained? What was ruled out? What still needs review? If the customer should seek a different route, the case needs a state for that outcome rather than being left as "lost".
The platform should also distinguish between "not enough information to assess" and "assessed but not suitable". Those are operationally different cases.
4. Creditor contact and proposal work
Creditor contact is where case management starts to become coordination work.
For a DMP, creditors may need to be contacted, balances checked, payment offers prepared and responses tracked. GOV.UK notes that creditors do not have to agree to a DMP, and unless an agreement says otherwise they may still ask for full payment later or take action to recover money. The workflow should therefore track creditor response and plan assumptions carefully.
For an IVA, the proposal, creditor voting, insolvency practitioner involvement, fees and legal structure introduce a different set of states. GOV.UK notes that creditors holding 75% of the debts must agree for an IVA to start, after which it applies to all creditors, including those who disagreed.
That is too important to hide in a note field.
5. Plan setup and payment operations
Once a plan is live, the case changes character. It becomes an operational account.
Payments need to be scheduled, received, allocated, reconciled and reported. Missed payments need follow-up. Creditor distributions need records. Fees and customer communications need to be clear. If payment details change, the platform should record who changed them, why, and what the customer was told.
This is where a dashboard can mislead. A dashboard may show the plan as active. The operating loop needs to know whether the latest payment cleared, whether distributions matched expectations, whether a creditor balance changed and whether any support action is due.
6. Reviews and changes in circumstances
Debt cases live in the real world. Income changes. Employment changes. Household costs change. Creditors respond late. Customers miss payments. Vulnerability signals appear later.
Citizens Advice notes that an insolvency practitioner will review a person's situation each year during an IVA and that payments may change if income changes. That illustrates a broader point: review is not an optional admin task. It is part of the lifecycle.
The platform should have states for annual review due, review in progress, customer information requested, payment variation required, creditor update needed and review complete.
7. Failure, closure and aftercare
Cases do not only end cleanly.
Some close because the plan completes. Some fail because repayments are not maintained. Some are transferred. Some are withdrawn. Some need signposting elsewhere. Some require complaints or data requests. Some have outstanding creditor or payment reconciliation issues after the main case appears closed.
Closure should be a controlled workflow, not a status someone sets when they want the record out of the queue.
What good looks like
A good debt management platform can answer simple questions quickly:
- What stage is the case in?
- What evidence supports the current position?
- What options have been considered?
- What is the next action and who owns it?
- Which creditor responses are still outstanding?
- What has the customer been told?
- What payments, distributions or reviews are due?
- Why did the case close or fail?
That is the same operating-loop discipline I wrote about in financial operations need operating loops, not more dashboards. A debt platform does not just need more fields. It needs states, evidence, ownership, safe actions and audit history.
The case lifecycle is the product. The software has to respect it.
