mass tort intake metricsMeasure File Readiness
A technical metric dictionary for completion, evidence gaps, corrections, duplicates, exceptions, remediation, and attorney-review readiness.
Mass tort intake metrics should show whether each claimant record is complete enough, supported enough, and clearly enough owned for an attorney to review. Form submissions alone measure arrival volume. A useful scorecard defines the record population, required evidence, workflow events, exception states, and review boundary before it calculates a rate.
Measure fitness for review
Mass tort programs receive many records through forms, calls, referrals, imports, and document uploads. Counting each event can describe traffic, yet it cannot show whether the resulting files can support a decision. Ten submissions may represent ten people, repeated attempts by one person, imported duplicates, or records that lack the evidence the firm's review policy requires.
The operational purpose of measurement is therefore specific: show how reliably the mass tort intake operating model turns received information into a traceable file at the attorney-review boundary. The measures below also assume a defined mass tort intake process. A dashboard cannot repair a workflow whose stages, owners, and exit rules are undefined.
The U.S. Government Accountability Office's data reliability guide treats reliability as a question of accuracy, completeness, and suitability for an intended purpose. NIST's Research Data Framework likewise describes quality assessment in relation to planned use and identifies accuracy, completeness, consistency, and timeliness as useful dimensions. Applied to intake, the intended use is a review packet that an authorized reviewer can understand without reconstructing the record from scattered systems.
Track the Real Conversion Numbers that Drive Mass Tort ROI
Measuring cost per lead is misleading if only a fraction sign retainers. Cost per review-ready file shows what each marketing campaign produces.
Establish the measurement contract first
Every metric needs a short contract stored beside the dashboard definition. The contract should name its purpose, numerator, denominator, unit, cohort, exclusions, source events, owner, refresh time, and version. Without that contract, two teams can publish the same label while counting different work.
Define the population before choosing a denominator. A received record is a unique intake record created when the system accepts an inquiry. A person is a deduplicated identity that may be linked to more than one received record. A review packet is a versioned assembly submitted to a defined review queue. These units are not interchangeable.
Also decide whether a report follows a submission cohort or a process event. A submission cohort groups records by received_at and follows their later outcomes. An event report counts work that occurred during a period, even when the underlying record arrived earlier. Cohorts show what happened to a set of arrivals. Event reports show current workload. A useful operations view labels both.
NIST's Data Governance and Management Profile concept paper connects governance objectives with roles, policies, metadata, lineage, and accountability. The federal Data Strategy practices similarly call for assigned governance roles, maintained documentation, provenance, standards, and data quality aligned with intended use. Those principles support a practical rule: the metric definition, the events that feed it, and the person accountable for investigating it all need named ownership.
Use explicit event boundaries
A status label describes the record now. An event records what happened at a point in time. Metrics should derive from immutable or append-only events wherever possible so a later status change does not erase earlier work.
At minimum, define these boundaries:
| Event | Boundary | Required properties |
|---|---|---|
intake_received |
The system accepts the first source submission and creates a record ID | record ID, source, received time |
intake_stage_entered |
A record first becomes eligible for work in the named collection stage | stage, requirement-set version, entry time |
intake_stage_completed |
All requirements for the named collection stage are answered, explicitly unknown, not applicable, or waived under firm policy | stage, requirement-set version, completion time |
evidence_requirement_opened |
A configured evidence requirement becomes applicable | evidence type, rule version, opened time |
evidence_received |
A source file is attached and classified against that requirement | source ID, classification, received time |
correction_recorded |
A material field value changes after initial capture | old value reference, new value, source, actor, reason, time |
duplicate_confirmed |
An authorized workflow confirms two records represent the same person or inquiry | retained ID, linked ID, reviewer, time |
exception_opened |
A record cannot follow the ordinary next step | exception type, owner, opened time |
exception_resolved |
The blocking condition is addressed or dispositioned | resolution, actor, resolved time |
review_packet_submitted |
A versioned packet enters the attorney-review queue | packet version, requirement-set version, gate-result snapshot, submitted time |
review_packet_returned |
The reviewer sends the packet back for intake remediation | reason code, reviewer, returned time |
review_packet_reviewed |
An authorized reviewer records the first response to a submitted packet version | response type, reviewer, reviewed time |
Keep each received fact intact and record changes beside it. The National Archives' electronic recordkeeping guidance calls for audit trails of additions, updates, deletions, retrievals, and other record activity. An intake correction history serves the same operational need. It lets a reviewer distinguish what arrived, what changed, who changed it, and which source supported the change.
Benchmark Your Document Verification Ratios
Compare your firm's document retrieval speed and qualification rates against industry benchmarks to uncover hidden revenue leakage.
Metric dictionary for file readiness
The table gives implementable definitions. Each firm must set its own review policy, evidence requirements, reporting window, and alert thresholds.
| Measure | Formula | Denominator and boundary | Primary owner | Caveat |
|---|---|---|---|---|
| Stage completion rate | Unique records with intake_stage_completed / unique records that entered the stage |
Cohort by first stage-entry event | Intake operations | Completion means the configured stage rules were satisfied, and claim qualification is a separate decision for a lawyer. |
| Missing-evidence rate | Unique submitted packets with at least one open required-evidence item / unique packets submitted for review | First review_packet_submitted per record and requirement-set version |
Evidence operations | Separate unavailable evidence from evidence never requested. Requirements can change by campaign and version. |
| Correction rate | Unique reviewed records with at least one material correction_recorded / unique records reviewed |
Review event for the same cohort and field dictionary version | Data steward | Count records for the rate and retain event count as a diagnostic. A correction can reflect good review. |
| Duplicate rate | Records confirmed as duplicates / candidate records created | duplicate_confirmed events tied to the creation cohort |
Intake operations | A stronger identity check can increase the observed rate while improving record quality. Exclude system tests and documented spam by rule. |
| Open exception age | Report time minus exception_opened for unresolved exceptions |
Each unresolved exception at the report cutoff | Queue owner | Report age by exception type and owner. One combined average can hide an old tail. |
| Remediation rate | First-submission packets returned for intake remediation / first-submission packets reviewed | First review_packet_submitted and its first reviewer response |
Review operations | Count a legal judgment request separately from intake remediation, and use controlled return reasons. |
| Attorney-review readiness rate | Packets that satisfy all configured operational gates at submission / packets submitted to attorney review | Submitted packet version under the active requirement-set version | Program operations | Readiness is an operational state, and merit, conflicts, engagement, and filing stay with lawyers. |
For duration measures, publish the median and a tail percentile chosen in the metric contract, along with the record count. Count unresolved exceptions as well as resolved ones so open work stays visible. A backlog view should include every unresolved item as of the report cutoff. A flow view should show items opened and resolved during the same period.
Preserve unknown, unanswered, and unavailable states
An unanswered question means the workflow has no recorded response. An unknown answer means the claimant was asked and could not provide the fact. An unavailable document means the requirement was evaluated and the document cannot currently be supplied. These states require different next actions and must not collapse into a blank value.
Stage completion may permit an explicit unknown when the firm's rule says the interview step is complete. Review readiness may still block if that unknown concerns a required operational fact. Missing-evidence reporting should count each applicable open requirement and ignore empty upload slots that no rule requires. A mass tort intake checklist should state which conditions allow completion, create an exception, or require human review.
Unknown is a separate answer from no. If a record asks whether a person has a particular source document, unknown, not yet requested, requested, received, unavailable, and not applicable should remain distinct allowed states. That state model makes the numerator reproducible and tells the queue owner what to do next.
Assign ownership and review the causes
The intake operations leader owns stage definitions and queue performance. The data steward owns field definitions, allowed values, correction lineage, and metric logic. Evidence operations owns document requirements and classifications. Review operations owns return reasons and the boundary between remediation and legal review. Engineering or analytics owns event integrity, joins, refreshes, and versioned queries. Privacy and security staff approve access and retention controls.
Lawyers or other authorized firm staff retain decisions about conflicts, legal merit, engagement, filing, and legal advice. Software tests whether configured operational requirements are met. Qualification and engagement decisions stay with lawyers.
Review a metric by campaign, requirement-set version, source, intake stage, exception type, and owner where the sample supports a responsible comparison. Investigate the workflow behind a change. A rising correction rate might show an unclear question, a new reviewer practice, improved source checking, or a changed field definition. A rising duplicate rate might indicate repeated acquisition records or better matching.
Do Not Get Scammed Twice: Statutory Fee-Shifting vs. Upfront Retainers
High-volume intake metrics dashboards often conceal harmful conversion patterns, such as third-party marketing brokers funneling consumer claimants into costly upfront retainer commitments.
In consumer arbitration, PAGA wage actions, and federal mass tort litigation, statutory fee-shifting rules require corporate defendants to cover reasonable attorney fees upon prevailing. Law firms must ensure intake pipelines evaluate fee-shifting viability automatically so eligible claimants never pay upfront retainers.
OBE gives plaintiff litigation firms review-ready case files with source-linked evidence and flags on statutory fee eligibility for attorney review.
Build the scorecard from a governed record
Start with the general legal intake model, then document the event dictionary, field dictionary, requirement versions, and packet versions used by the mass tort program. Run the formulas against a small known set and reconcile every numerator to its source records. Test late documents, reopened exceptions, merged duplicates, corrected answers, changed requirements, and packets submitted more than once.
Publish a metric only when an operator can trace it from the dashboard to the event, record, source, and rule version that produced it. That traceability turns intake reporting into a control for file readiness. It also keeps the scorecard honest about what it can measure: the condition of the operational record before legal judgment begins.
Find the Right Intake Software and Developers for Your Firm
Ready to get clear visibility into your firm's intake economics?
👉 
Schedule a Consultation with Tim Ottowitz to Review Your Case Type
I will review your intake funnel metrics, audit your attribution tracking, and show you how OBE turns inquiries into review-ready files.