Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.
Context
A mid-tier revenue-cycle and debt-recovery business operating on behalf of healthcare providers. Its entire operation — data ingestion, account handling, agent workflow, client reporting — ran inside a legacy collections application suite.
The software worked, in the narrow sense that it did not fall over. The problem was that it had stopped being able to express how the business now wanted to work.
The problem
- Ingestion, account handling and reporting had each been adapted to the constraints of the legacy product rather than to the business, and those adaptations had gone unrevised for over a decade.
- There was no practical way to change a workflow without going back to the vendor.
- Data movement in and out was file-based and rigid; there were no APIs to build on.
- Reporting was static, and anything outside the shipped set meant a request to a central team.
- Client-sensitive data made hosted AI tooling a non-starter, so the obvious modern options were closed off.
What we built
A tailored enterprise platform
Covering the operational core — account handling, work allocation, client and vendor interfaces, and reporting — designed around the process the business wanted rather than the one it had inherited.
Multi-tenancy with real isolation
Each client's data is separated at the platform level rather than by convention.
API-based data flows
Replacing the file-drop model, which is what made the later integration work in this portfolio possible at all.
Prompt-based reporting on an on-premises language model
Trained and deployed on the client's own server, with voice support — so natural-language querying became available without any data leaving the network. This is covered in its own right in Natural-Language Access to Business Data.
How we delivered it
- 1
Process mapping before configuration
With the people doing the work, separating genuine requirements from habits the legacy product had imposed.
- 2
Foundation
Environments, security model, tenancy structure, deployment pipelines.
- 3
Functional area by functional area
Each demonstrated to real users and signed off before the next began.
- 4
Parallel operation
The legacy suite stayed available while each area moved.
- 5
Stabilisation and hand-over
Documentation, role-based guides, and a backlog of what was deliberately deferred.
How it was phased
Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.
What the client keeps
- The platform and its source
- The tenancy and security model, documented
- API specifications
- The process maps and decision log from discovery
- Role-based user guides