Building a claims system that hands a law firm a case rather than a phone number
Most lead generation websites stop the moment somebody types in their name and number. Somebody then has to ring them, ask all the real questions, get the paperwork signed, and type it all into a law firm’s system, and by that point the marketing has finished and the work has only just started.
This was built to carry on past that point. It’s a claims intake platform for military hearing loss and tinnitus claims, armedforcesclaims.com, which I built and run for Clear Law, a firm of solicitors and one of Claims Bible’s partner firms. It takes a serving or former member of the forces from a first enquiry through screening, consent, signature and documentation, delivers a structured case straight into the firm’s onboarding system, and then hears back about what happened to it.
One thing worth explaining about the arrangement, because it shapes the whole build. Personal injury claims are covered by rules that stop law firms paying for referrals. So rather than a marketing business collecting enquiries and passing them on, the site itself belongs to the law firm, and I build and operate it on their behalf. It’s their intake, running on their domain, feeding their own case system. That’s the compliant way to do it, and as it happens it’s also the better way to do it, because it removes the handoff between two businesses that’s where most of the information usually gets lost.
I should say that these are people I served alongside, or people like them, and hearing damage is one of the things the forces leaves you with. So I had more reason than usual to want the process to work properly for the person filling it in.
Where it started
The problem with a lead is that it isn’t a case. A name and a phone number give a law firm a sales opportunity and nothing else. Before they can assess or take on the person behind it, they need to know who they are, what their service history was, what’s wrong with their hearing, whether they’ve claimed before, whether they’ve got the right permissions in place, whether the agreement’s been signed, and where the enquiry came from in the first place.
When those answers live across a web form, a spreadsheet, a string of emails and somebody’s memory, the marketing and the operation come apart. The marketing side can tell you how many enquiries came in and not much about what happened to them. The case handlers get a list of contacts and have to rebuild the application from scratch.
So the brief was to build something that carries the enquiry all the way through that journey, into the firm’s own system, instead of leaving the work to begin again after the form’s submitted.
What I built
An intake designed backwards from what the law firm needs. That was the central decision and everything else follows from it. Rather than designing a form to collect contact details, I started with the information the firm’s onboarding team needs to assess a case and worked backwards to the questions that produce it. The applicant answers about their service history and branch, their hearing loss and tinnitus, previous claims, hearing aid use and address history, in one guided journey, and the firm gets a structured starting point rather than a callback request.
Consent and signature inside the journey. Consent is collected with a timestamp and the context it was given in, and the Conditional Fee Agreement is generated and signed as part of the same process. So the consent trail is part of the case package, not something to reconstruct afterwards from an email thread.
A way back in. Not everybody finishes in one sitting. Saved applications can be picked up again, and eligible incomplete journeys can be completed, so that somebody who got interrupted doesn’t have to start from the beginning. I’d expect that to reduce abandonment, but I haven’t measured it separately yet, so I’m not claiming it.
Delivery straight into the firm’s case system. The application is mapped into the format Clear Law’s onboarding expects and sent through their API, with the contact and identity details, the address, the service history, the screening answers, the consent record, the generated agreement, any supporting documents, the source, and a shared case reference. It’s a direct handoff from the firm’s intake site into the firm’s case system, not a notification email asking somebody to copy it all across. It was built for this firm’s workflow and I wouldn’t describe it as a universal connector for any CRM.
Failures that show up. External services don’t always answer first time. Document generation and delivery run in the background after the applicant’s submission is saved, and the system tracks anything that didn’t complete, retries the cases it can, and keeps the failure details for someone to look at. A failed handoff becomes a visible operational problem instead of an assumption that everything got through.
Status coming back the other way. Updates from the firm’s case handlers feed back into the platform, so the marketing side of the firm can follow a case past the point of submission. That closes the gap between “we generated a lead” and “we know what happened to it”, which is the gap most lead generation reporting lives in.
Attribution down to the case. Enquiries introduced by the firm’s affiliate partners carry the partner’s code and direct enquiries are tracked separately, so the firm can see which sources produce applications and how those applications progress. Partners have their own portal to see the progress of what they’ve introduced, which means they aren’t waiting on somebody to assemble an update by hand.
Reporting that reaches the accounts. Batches, payment history and downloadable reports connect the acquisition activity to the firm’s bookkeeping, and historical batch reports stay available after the event, because the practical need to explain a past period to an accountant or a partner doesn’t go away.
The decision I’m most pleased with
Designing it backwards. It’s an unglamorous decision and it’s the one that made the whole thing worth building.
There’s a trade-off in every intake form. Ask too little and the receiving team has to chase everything later, which they resent, and rightly. Ask too much without structure and the applicant gives up half way down. The way through is to know exactly what the downstream team needs and ask for precisely that, in an order that makes sense to the person answering, while doing the document preparation and the technical delivery out of sight.
The objective was never more enquiries. It was more usable enquiries, with a clear route into the firm’s workflow.
What the numbers say
A production data snapshot taken on 8 September 2026, covering claim records created between 14 April and 6 September 2026:
| Claim submissions recorded | 333 |
|---|---|
| Recorded as sent through the law firm’s API | 333 of 333 |
| With a recorded acceptance event | 206, which is 61.9% of submissions |
| Currently carrying accepted status | 202, which is 60.7% |
| Introduced by the firm’s affiliate partners | 234 |
| Direct | 99 |
I want to be careful about what those mean. An acceptance is a processing status at the law firm, not a compensation outcome. The 333 of 333 is the proportion of recorded claims marked as sent through the API, not a claim about uptime or first-attempt delivery. The current accepted total is reported separately from the acceptance events because a case can go backwards after being accepted, and I’d rather show both than pick the better one.
What they do show is that the system is doing more than collecting enquiries. It’s recorded hundreds of submissions, every one in the snapshot was handed over, and more than six in ten progressed to acceptance. What they don’t show is an uplift against whatever came before, or a return on advertising, or a case-win rate, because there’s no baseline for any of those yet and I’m not going to invent one.
How it was built
The front end is React and TypeScript, the back end is Node and Express on PostgreSQL, with separate services for documents, email and the integration into the firm’s case system. I set the requirements with the firm, designed the applicant journey and the intake, specified the attribution, consent and document workflows, worked through the integration with their case handlers, and I still spend time investigating how it behaves in production and refining it. The code was written working alongside Claude, the same way as everything else I build now.
What this looks like for your business
If you generate enquiries for somebody else to act on, whether that’s a law firm, a sales team or a partner, the question worth asking is what arrives at the other end. If the honest answer is a name and a number, then most of the work is still to be done and most of the value is still to be lost.
The approach here works for any business with a handoff in it. Find out what the receiving side actually needs, ask for exactly that and no more, handle the paperwork and the delivery behind the scenes, and make sure you hear back about what happened.
Tell me what’s not working.
I’ll tell you whether I can help and roughly what it would involve.