The claimant system that runs your group action

A team of paralegals works in one site and one claimant list for the life of the action.

A typical business running one of these has a group action team of 15 to 60 paralegals and case handlers across one or two offices, with between 5,000 and 50,000 claimants on the books, arriving in the hundreds a day while a claim is advertised and in ones and twos for years after, and a shared inbox taking hundreds of claimant emails a day. Whichever generation built it, for an action in 2010 or one in 2021, the job is the same.

In the case handler's words, it takes the enquiry from the website or the call centre, runs the questionnaire that decides whether the person fits the cohort, sends the retainer for signature, collects the ID check and the evidence, moves each claimant through the stages the court's order sets, produces the schedule of claimants for the court, sends the bulk letters and emails, and at the end records the settlement, works out the deductions and pays out. Two pieces matter more than the rest: the stored procedure that decides who is on the schedule, and the duplicate check.

The rules it holds are the ones a product would not know:

• A claimant is not on the schedule until the retainer is signed, the ID check has a dated result and at least one piece of evidence of the kind this action requires is on file.
• The questionnaire scores answers in a way settled with counsel, and a claimant who fails it may answer again once, after a call, and never a third time.
• Two enquiries sharing a date of birth and a postcode are held as a possible duplicate until a person clears them, because the court's schedule cannot carry anyone twice.
• Deductions from a settlement follow the order the retainer sets out, each capped as the retainer says, and the cap depends on when the claimant signed.

None of it is written down anywhere but the site.

Built for the firm's first big action, somewhere between 2008 and 2015, by a contractor or a small agency, so the whole team could work in one place and claimants could sign up online. An ASP.NET Web Forms site on the .NET Framework over SQL Server, with the nightly jobs as SQL Agent steps and a few console programs, and the exports as scheduled queries writing spreadsheets to a share. It runs on a Windows server in the firm's own server room, or in a rack at a local hosting company.

The contractor's people scattered once the first action closed, and the folder of SQL scripts now belongs to one person who learned them by running them. Each action since has bolted on a questionnaire, a rule or a schedule format the court ordered, usually in the week before a deadline, with no design to fit it into. Every addition leaves the site a little stiffer to change.

The same system built between 2016 and 2022 for a newer action, by an agency or a freelancer, as a claimant portal and case screens in React, Angular or Node, PHP or .NET Core, or run as a claimant tracker in Power Apps put together by someone in the operations team. From the claimant team's desks it looked finished: sign-up on a phone, a portal where claimants upload their evidence, a dashboard with the counts on it.

A new action finds its limits first. The portal was shaped around one cohort's questionnaire and one court's schedule, so the next cohort brings questions and columns it has no place for, and the agency that could add them has moved on to other work. When one eligibility question went in against a deadline, a batch of claimants landed at the wrong stage, and the code has been left alone ever since. The hosting, meanwhile, sits in the name of someone who has left the firm. Since 2023 a few have been started in an AI app builder to catch a fast-moving action, then stalled before the schedule export worked. For all its newer look, it is as stuck as the site it followed.

A cohort in the tens of thousands carried through one process by a team that could never do it on paper.

The site is what lets a firm take on tens of thousands of claimants against a court timetable and know, on any day, how many have enquired, signed, been verified and made the schedule. Every stage writes to the same claimant record, so the schedule the court receives is the list the firm has, and the phone team can say in seconds whether a caller is a claimant and where they are up to.

The funder's numbers come from the same place, each month, without a week of counting. And when the action settles, the payment goes out to thousands of people with the deductions the retainer sets and an audit trail on each one.

Every action since the first has run on it, and the rules from each are still in there.

Systems like this do not stop. They strain, and the strain lands on the deadline.

Built for one action, now carrying ten. A claimant screen written for a few thousand people holds tens of thousands, the nightly job that rebuilds the status counts runs into the working day, and the schedule export times out, so it is run in pieces. The team knows which hours to avoid.

No Web Forms on modern .NET, and a server with a date. The site runs on the .NET Framework, which has no path forward for Web Forms, on a Windows Server 2016 that goes out of support in January 2027. The developers who know it are few, and the one who knows this site is booked by the day.

The court orders a format the site cannot produce. Each new order asks for the schedule or the disclosure in a different shape: a column never stored, a date stored as text, a grouping the export cannot do. Neither generation can change an export without a developer, so the deliverable is built by hand in a spreadsheet against a date that will not move.

Sign-up still ends on paper. The website takes the enquiry, but the retainer goes out as a PDF, comes back scanned and is matched to the claimant by a paralegal, and the ID check happens in another service whose result is typed back in. At a few hundred sign-ups a day, the matching queue is where claimants get lost.

The same claimant record, with the schedule coming out of a button and sign-up finishing on a phone.

The schedule as a button. The court's schedule and the disclosure export produced from the claimant record in the shape the current order asks for, with that shape kept in settings rather than in a spreadsheet built at midnight. The next order changes a setting, not a weekend.

Sign-up finished on the phone. Questionnaire, retainer signature and the ID check in one flow the claimant completes on their phone, writing straight into the existing database. The matching queue empties.

A database that keeps up. The claimant tables indexed for the queries the team runs, and the nightly rebuild replaced by counts kept as each record changes, so the status screen is right first thing and the export runs whole.

Off Windows Server 2016. The site and the database on versions that are supported, with tens of thousands of people's personal data held the way the regulator expects.

Every claimant told, and the reply on the record. Bulk email and text to a cohort from the system, with the bounce, the reply and the call on the claimant's record: the proof someone asks for later.

The funder's own view. A login for the funder and the insurer with the numbers they ask for each month, from the same data, without a paralegal counting.

The old site is not switched off for any of this. Each piece is added beside it, on the same data.

Reading and cross-checking at volume, with a person confirming every result.

AI helps where the claimant numbers meet the paperwork, and stays out of the decisions.

Evidence read into the claimant record. A claimant uploads a payslip, a statement or a photograph, and a paralegal types the employer, the dates and the amounts into the record. AI fills those fields from the upload and marks any it could not read, so the paralegal confirms rather than keys. At a few hundred sign-ups a day, most with more than one upload, that typically gives each paralegal on the evidence queue a couple of hours back.

Claimant emails sorted onto the right record. The hundreds a day ask the same few things: has my form arrived, what stage am I at, when will I be paid. AI matches each email to its claimant, files it, and drafts the reply from the record for a case handler to read and send. A case handler's morning in the inbox typically shrinks to half an hour on the ones it could not place.

Sign-ups that may be one person twice, or no one at all. Beyond the date of birth and postcode rule, AI looks for the same phone number, address or bank details under supposedly different claimants, or questionnaire answers pasted word for word, and queues each match for a person to clear or refer. That typically turns a sweep of the whole list before each schedule into a few minutes each morning.

Not worth doing: letting AI decide a claimant's eligibility, strike out a suspect sign-up, or answer a question about the merits of a claim. The scoring was settled with counsel and a person applies it, advice on a claim is a lawyer's to give, and a model doing any of that would need explaining to the court.

Each of these writes to the record the schedule is built from, so none starts before the first stage makes that record safe to change. The assessment shows where it would pay back on the site as it runs today.

Safe to change first, then the piece the next deadline depends on, then the rest, and the old site stays as the fallback until the end.

1. Stabilise. The Web Forms source found and matched to the running site, the nightly jobs and the scripts collected and read, the database on a version still supported, a backup restored on purpose, and a test copy that treats the claimant data as the personal data it is. This goes first because the next court deadline will land on this system, and nothing gets changed under a deadline without a copy to try it on.
2. The schedule and the exports. The piece a deadline depends on comes first: the schedule and the disclosure produced beside the site from the existing database, in the shape the current order asks for. The site does not change.
3. Sign-up on a phone. Questionnaire, signature and ID check in one flow, writing into the same claimant record. The paper retainer stays for anyone who wants it.
4. The claimant and cohort screens in a browser, bulk communication, the funder's view. Each a stage, each priced on its own.
5. Retire the Web Forms site when nothing still depends on it; with the server date handled in the first stage, that can wait. Expect the settlement screen to go last, because accounts trust it.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a claimant system that means a few days with the case handlers, the person who runs the scripts and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: ASP.NET Web Forms, the .NET Framework and SQL Server, and for the newer generation React, Angular and Node, old PHP and .NET Core.