People who should have shared one view had different ones, because one file had been updated and the other had not. The data function could not publish an indicator without first arguing about which number was right.
A legal claims buyer took its back office out of spreadsheets and email, and the monthly numbers stopped taking three days
BT Credit purchases the rights to pending labor claims and advances the money to the claimant. Its data function was born on top of departmental spreadsheets and email-triggered approvals. Today the processes that had not yet reached its core case system run on a purpose-built system, and the monthly analytics snapshot is ready the moment it is opened.
A legal claims buyer whose margin depends on data being complete, consistent and current.
Each claim has a value, a stage, a counterparty, documents and a decision about whether and how much to advance. Origination, legal analysis, finance and collections all have to look at the same numbers.
Litigation finance
2019Founded, company figure as of 2026
~11,000Claims handled, company figure as of 2026
~120Professionals, company figure as of 2026
2–3 days → 0Monthly analytics snapshot, interviewee account from 2022
2–3 days → 0Monthly analytics snapshotUsed to take two to three days of collecting spreadsheets and clearing inconsistencies, according to the head of the data function. The data is now already in the system when the report is opened. Not timed.
~3h vs 2 moTime to first working versionThe interviewee's own estimate of what the first version would have taken to code with a backend, front end and database, versus the time he says it actually took.
1 dayOf resistanceThe team's reluctance to leave the old way of working dropped as soon as they tried the new flow, per the interview. The published case put it at a single day.
2 → 1Duplicate verifications, now one eachThe contract-approval redesign exposed that two reviewers were checking the same fields. Each now checks only their own.
“When we started building the data function, a lot of very relevant information was scattered across spreadsheets between the areas of the company. Several departments were controlling information that was sometimes the same and sometimes complementary, but always in spreadsheets. We also had the internal system, but not every process was in it yet.”
Bruno PazettiHead of Analytics, BT Credit, in the 2022 published case
BeforeAfter
- One spreadsheet per department, overlapping versionsOne relational database feeding every team the same records
- Monthly snapshot assembled by hand in two to three daysThe snapshot reads from the live database when it is opened
- Contract approval started by email, gaps chased in follow-upsA form that will not submit until required fields are complete and valid
- Two reviewers checking the same fields without knowing itEach reviewer confirms only the fields assigned to them
- Change notices passed by hand, or forgottenEmail fires when a record moves stage; comments live on the record
The company's proprietary case-management system stayed. It already ran the processes that were mature and stable. The new system took the processes that were not yet digitized, and became the place where a process is designed, tested and revised while it is still changing. Once a process has stopped changing, the working model exists and can be moved into the core system directly.
The constraint is operational rather than commercial
BT Credit buys the rights to payouts from pending employment lawsuits and advances part of the expected value to the claimant, and separately advances fees to the claimant's attorney. By the company's own published figures it was founded in 2019, has handled roughly 11 thousand claims and employs about 120 professionals.
The business is a portfolio of legal claims. Each one carries a value, a stage, a counterparty, a set of documents and a decision about whether and how much to advance. Margin depends on pricing that decision well, and pricing depends on the data about each claim being complete, consistent and current across the teams that touch it: origination, legal analysis, finance, collections.
That is why the constraint is operational rather than commercial. When a company like this grows, the number of claims in flight grows faster than the number of people who can manually reconcile them. If the reconciliation lives in spreadsheets and inboxes, the data function ends up spending its time rebuilding the same picture every month instead of improving the pricing.
A core system for part of the operation, and nothing structured for the rest
That is the head of the data function describing the state he found when he joined, about a year before the interview. His first attempt was to build the company's basic indicators by reading those spreadsheets directly. It broke on the second run.
“When we started building the data function, a lot of very relevant information was scattered across spreadsheets between the areas of the company. Several departments were controlling information that was sometimes the same and sometimes complementary, but always in spreadsheets. We also had the internal system, but not every process was in it yet. So part of the information was in the system and part was in spreadsheets across the areas.”
Sitting with two areas to take one "photograph" of the month meant waiting for spreadsheets to arrive, asking about the gaps, finding cells with inconsistent data and going back. The snapshot was late before it was done.
A request arrived by email, often with information missing, and the missing pieces were chased in follow-up messages. The request then passed through a chain of reviewers. Nobody could see the chain end to end, which is how two of those reviewers ended up verifying the same fields without knowing it.
The pattern behind all three is the same. The company had a core system for part of the operation and nothing structured for the rest, and "the rest" was where the data function needed to work. Coding those processes into the core system was possible but slow; leaving them in spreadsheets meant the data would never be trusted.
Item by item, what did each job before and what does it now
| What did this before | What does it now |
|---|---|
| One spreadsheet per department, each holding its own version of overlapping information | One relational database with the tables and their relationships defined once, feeding every team the same records |
| Manual monthly snapshot: collect files, question gaps, clean inconsistent cells | The snapshot reads from the live database; nothing is collected by hand |
| Contract approval requested by email, information completed over several messages | A form with required fields and input masks; a request cannot be submitted incomplete or with an invalid value |
| Sequential review in which each person re-checked what the previous one had checked | Each reviewer sees and confirms only the fields assigned to them, in a Kanban-style pipeline |
| Someone updates a spreadsheet and warns the next person by hand, or forgets | Email notifications fire automatically when a record moves stage |
| Context about a request scattered across email threads | Comments live on the record itself, visible to everyone who touches it as it moves between departments |
What was not replaced. The company's proprietary case-management system stayed. It already ran the processes that were mature and stable. The new system took the processes that were not yet digitized, and became the place where a process is designed, tested and revised while it is still changing. Once a process has stopped changing, the working model exists and can be moved into the core system directly. The interviewee described this as a second reason to keep the system: it is the prototyping ground for what the core system will eventually absorb.
The contract-approval flow, end to end
- 1Request form is filled inPerson
A team member opens the request form and fills in the contract data. Required fields and value masks block submission until the data is complete and valid.
- 2Record enters first reviewAutomated
The record is created in the database and enters the first review stage.
- 3First reviewer checks their fieldsPerson
Notified by email, checks only the fields assigned to that stage, and confirms or comments on the record.
- 4Record advancesAutomated
The record advances to the second review stage and the second reviewer is notified.
- 5Second reviewer checks their fieldsPerson
Checks only their own fields and approves or returns the record with a comment.
- 6Requester is notifiedAutomated
The requester is notified of the outcome.
- 7Data reaches the dashboardsAutomated
Data from approved records is available to the analytics dashboards without any extraction step.
The hard links are steps 1 and 3 to 5. Step 1 is where the old process leaked: an email with missing information cost several round trips before review could start. Steps 3 to 5 are where the duplicate work was hiding, and it was only visible once the chain was drawn as a pipeline rather than a series of forwarded emails. The automations in between are simple. The design decisions around them are what removed the waste.
Every figure, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Monthly analytics snapshot | From two to three days to no time spent collecting | Interviewee's description of the old routine and the current one. Not timed |
| Time to first working version of the internal-process system | About three to four hours, against an estimated one to three months to code | Interviewee's own estimate for both sides; he settled on "three hours against two months". The published case rounded the coded side to three months |
| Team adoption | Resistance dropped as soon as people tried the new flow | Interviewee's account; the published case states "a single day" |
| Contract approval | Two reviewers verifying the same fields, now each verifies only their own | Interviewee's account of the redesign. Hours saved not measured |
"Three hours against two months" is one person's estimate on both sides. The three hours is the interviewee's recollection of building the first version, before later revision rounds. The two months is his estimate of coding the same thing with a backend, front end and database, and he gave it as a range from at least one month to two or three. If two months is read as roughly 40 working days of eight hours, the comparison is about three hours against about 320, but that reading is ours, not his.
"Hundreds of times faster" is not a measured figure. The interviewee opened with it and immediately said he had never done the exact calculation. It appears in this case only as his impression, not as a result.
"Up to three days" measures the old snapshot, not the new report. The three days is how long collecting and cleaning used to take. The new figure is not a shorter time; it is that the collecting step no longer exists, because the data is already in the database when the month closes.
What this case does not measure
Worth naming, because it is usually what gets inflated.
Both time figures come from one interview with the head of the data function. Neither was timed, logged or audited.
The case does not measure cost per claim processed, per contract approved or per report produced, before or after.
The interviewee said the redesign "puts back team hours" and explicitly said he could not measure how many. No hires avoided or roles changed are claimed.
The interview and the original published case date from mid-2022. The company figures (about 11 thousand claims, about 120 professionals) are from the company's own site as of 2026. What the system covers today was not re-verified.
The published 2022 case named him as Head of Analytics. Public sources consulted in 2026 do not confirm whether he still holds that role or is still with the company.
The system covers the processes that were not in the company's core case system. The case does not claim the core system was replaced and does not describe what runs in it.
In 2022 the system was assembled by the client's own data lead. Under the current arrangement the building, configuring and maintaining sit with Jestor; the operational outcome described here is the same, the division of labor is not.
Capital is flowing back into claims, and it favors portfolios
| Indicator | Number | Source |
|---|---|---|
| New capital committed to litigation finance deals, 2025 vs 2024 | Up about 23%, after two consecutive years of contraction | Westfleet Advisors, 2025 Litigation Finance Market Report, published March 2026 |
| Active commercial litigation funders identified in the US market, 2025 | 39, with one new entrant | Westfleet Advisors, same report |
| Average transaction size, 2025 | About $8.1 million overall; single-matter deals about $4.5 million, portfolio deals about $19.6 million | Westfleet Advisors, same report |
| Organizations in which spreadsheets remain integral to financial operations | 90% | AutoRek survey of 500 senior finance managers in the US and UK, October 2024 |
| Organizations still processing and reporting at transaction level, introducing bottlenecks | 64% | AutoRek, same survey |
Westfleet reports that 64% of 2025 commitments went to portfolio deals rather than single matters. A portfolio is priced on the consistency of the data across many claims, which is exactly what departmental spreadsheets cannot guarantee.
Calling it an unreliable measure of annual activity. Market-size numbers for litigation finance that circulate in vendor material are usually extrapolations of a few funders' disclosures. This case uses only the deal-flow figures Westfleet stands behind.
The AutoRek finding is a survey of self-reported practice, not an audit, and it covers finance broadly rather than claims buyers. It is cited here for one reason: it shows the starting point in this case is the norm, not an outlier.
The system is built to order and the responsibility for it stays with us
In 2022 the data lead at BT Credit built the first version himself in an afternoon. The question that matters in year two is different: who changes it when the process changes, when that person moves on, or when the next department asks for its own flow. A custom system nobody is responsible for is a spreadsheet with a better interface, and it drifts back to one within three years.
One builder handles each request from start to finish, with one always in progress.
A new flow, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when origination, legal analysis, finance and the data function all touch the same records.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stay on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The description of the previous process, the two-to-three-day snapshot, the three-hour build against a two-month estimate, the adoption account and the contract-approval redesign come from a recorded interview with the head of the company's data function, cross-checked against the customer story Jestor published in July 2022. None of it was audited. Where the interview and the published story differ (two months versus three months to code; "as soon as they tried it" versus "a single day"), both versions are stated.
Founding year, claims handled and team size come from the company's own published figures as of September 2026. They are self-reported and four years newer than the interview.
Westfleet Advisors, The Westfleet Insider: 2025 Litigation Finance Market Report, published March 2026, as reported on the firm's site and in trade coverage. AutoRek, survey of 500 senior finance managers in the US and UK, October 2024, as published in the firm's press release.
The interviewee's phrase "hundreds of times faster" is quoted as an impression, not used as a result, because he said in the same breath that he had never calculated it. The original published case cited an average lawsuit duration of 998 days; no primary source for that figure was located and it does not appear here. No currency amounts appear because the company's published financial volume is in its local currency and converting it would introduce an assumption the source does not make.