Mass Tort Leads to Review-Ready Files: The Intake Work Between Them

A mass tort lead is an acquisition event, not a review-ready case file. Intake must resolve identity, preserve source and consent, apply versioned campaign questions, collect and link evidence, expose exceptions, and route the governed record to authorized review. Only then can an accepted intake move into case management without re-keying or lost history.

Why a lead is not a file

A lead can arrive from an advertisement, referral, landing page, phone call, event, or another approved source. At arrival, it may contain little more than a name, a contact method, a campaign label, and a short response. That can be enough to begin contact. It is not enough to support a conflict procedure, campaign-specific review, or a case handoff.

The work between acquisition and review belongs to mass tort intake. It should follow the firm's broader legal intake controls while accounting for campaign criteria, repeated evidence patterns, and higher record volume. The mass tort intake process describes the complete operating sequence. This guide focuses on the point where a mass tort lead becomes a governed prospective-claimant record.

Lead source does not determine file quality. A generated lead, purchased lead, referral, and direct inquiry all need the same firm-approved controls before legal or engagement decisions. The useful question is whether the record can show who submitted the information, what was collected, which campaign rules applied, which evidence supports each material fact, what remains unresolved, and who may decide the next step.

Define maturity by the record, not the label

Terms such as "new," "qualified," and "complete" often hide different standards across systems. Define each state by its required record and its exit authority.

Maturity state	Record required	Control before handoff
Source lead	Original payload, capture time, source, campaign, and notice context	Create or match the prospective-claimant record
Identity resolved	Original and normalized identity attributes, match candidates, and resolution history	Assigned staff resolves or escalates possible duplicates
Intake in collection	Contact permissions, question-set version, answers, answer states, and evidence requests	Required follow-up and exception work has an owner
Review-ready file	Source-linked facts, criteria version, evidence status, open exceptions, and preparation review	Authorized firm reviewer receives the exact record version
Matter handoff	Firm decision, engagement controls where required, accepted record, and open tasks	Receiving case system acknowledges the governed package

"Review-ready" does not mean every answer is favorable or every record exists. It means the decision owner can see the current facts, sources, gaps, conflicts, and history without reconstructing them from notes and uploads.

Resolve identity and possible duplicates first

Create one prospective-claimant record before adding campaign answers. Preserve the values as submitted, then store normalized versions for matching. A duplicate search can compare names, contact methods, addresses, dates, and other firm-approved attributes. A likely match should enter a review queue. It should not trigger an automatic merge based on a shared phone number or similar spelling.

NIST Special Publication 800-63A describes identity resolution as collecting enough evidence and attribute information to distinguish one identity within a defined population. It separates resolution from evidence validation and identity verification. That distinction is useful for intake design, although the NIST guideline applies to digital identity services, not law-firm intake requirements. A firm should set the level of identity checking appropriate to its work, applicable rules, and risk.

Keep the merge decision inspectable. Record the candidate records, attributes compared, reviewer, disposition, time, and any surviving links. If the records belong to different people, retain the decision so the same pair does not return as an unexplained match. If they belong to one person, preserve both sources and their original submission times.

Preserve source, notice, and consent context

A source label such as "Meta" or "referral" is too coarse for a governed handoff. Record the source system, campaign identifier, landing experience or referral path, capture time, original submission, and the notice version shown at collection. Keep attribution fields separate from case facts. Do not send claimant identifiers, injury details, answers, or document information back to an advertising platform as event payloads.

Consent and permission should be separate records with separate purposes. Contact permission does not automatically authorize document access, electronic signature, or representation. Store the notice or request version, the person's action, the channel, the timestamp, and the current status. A revoked or missing permission should stop only the activities governed by that permission and route the record under firm policy.

ABA Model Rule 1.18 addresses information learned from a prospective client even when no client-lawyer relationship follows. Its comment advises limiting an initial consultation to information reasonably necessary to decide whether to undertake the matter. Firm lawyers should translate applicable professional rules and local requirements into the approved notice, collection scope, retention policy, and review path. This guide is an operating model, not legal advice.

Apply the correct campaign criteria version

Every lead should point to a campaign record before case-specific collection begins. The campaign record should identify the active question set, evidence requirements, criteria version, effective date, approving authority, and permitted workflow paths. Store the version used for each answer and evaluation. A later criteria change should create a new version rather than silently rewriting earlier intake history.

Ask only questions approved for the current stage. Conditional logic can open follow-up questions when a prior answer makes them relevant. Preserve the prompt identifier and version so a reviewer can tell what the person was asked.

Answer states need operational meaning:

• Answered records the person's response and its source.
• Unknown means the person was asked and does not know the fact.
• Unanswered means no response was recorded to a presented question.
• Not asked means the workflow did not present the question.
• Conflicting means another answer or source disagrees.

Unknown and unanswered should never collapse into one blank value. An unknown date may call for a record request. An unanswered date may call for an interview task. Neither state authorizes staff or software to guess a value so the record appears complete.

Build evidence and provenance into the file

An upload does not become useful evidence merely because it exists in storage. Link each requested item to the campaign requirement it may satisfy. Record the request, response state, original file, submitter, source channel, receipt time, classification state, and reviewer action. Keep an unreadable file, possible duplicate, or conflicting record visible as an exception.

Every proposed fact should link back to an answer, document location, or named reviewer action. If intake staff correct a date after checking a source, create a new fact revision with the prior value, proposed value, supporting source, reason, reviewer, and time. Do not overwrite the original submission.

The NIST Data Governance and Management Profile concept paper identifies provenance and lineage as data-quality concerns when information comes from several sources or formats. It also connects accountability with documented rationale for decisions about data. In a mass tort file, that means a reviewer should be able to trace a material field through its source, transformation, correction, and approval history.

Route exceptions instead of hiding them

Volume makes exceptions ordinary work. Create named queues for possible duplicates, missing permission, incomplete conflict inputs, unknown answers, unanswered questions, missing evidence, conflicting sources, unreadable uploads, criteria gaps, and failed transfers. Each exception needs a reason, owner, opened time, allowed actions, escalation path, and disposition.

Conflict work belongs behind its own firm-approved boundary. The comment to ABA Model Rule 1.7 says lawyers should adopt reasonable procedures, appropriate to their firm and practice, to identify the people and issues involved. Software can assemble names, aliases, entities, and possible matches. A lawyer or other person authorized under firm policy decides what a match means and whether the intake may advance.

The same human boundary applies to qualification, legal conclusions, engagement, filing, and advice. Automation may identify missing inputs, apply a configured rule, prepare a summary, or route a record. Its output should remain a proposal or workflow state until the authorized reviewer records the decision.

Assemble the authorized review package

The review package should be a versioned view of the governed intake record, not a newly typed summary detached from its sources. Include the prospective-claimant identifier, source history, consent states, parties needed for the firm's conflict procedure, question-set and criteria versions, active facts, evidence links, corrections, open exceptions, and preparation history.

Assign the package to a permitted role and record who opened it, which version they reviewed, their disposition, and the next action. If new information arrives during review, create a new package version or reopen the affected control. The review trail should show that the decision relied on the record available at that time.

A review-ready file makes uncertainty inspectable. It does not turn uncertainty into certainty or transfer a lawyer's decision to the intake system.

Hand the intake record into case management

When the firm accepts a matter and completes its required engagement controls, the intake record should become the starting case record. Transfer stable identifiers, current facts, original sources, evidence objects, permission states, criteria history, corrections, reviews, and open tasks. If the case system requires flattened fields, keep a mapping from each destination value to its source record and handoff package version.

The receiving system should acknowledge the exact package it accepted. A failed transfer should create an exception rather than leave two records that look current. Staff should not have to re-key names, dates, parties, and answers into a second system, then guess which copy contains the latest correction.

Use the mass tort intake data model to define the claimant, campaign, answer, fact, evidence, source, correction, exception, review, and handoff entities. Test the model with fictional records that include a duplicate lead, withdrawn contact permission, unknown answer, unanswered question, criteria change, contradictory document, rejected correction, and transfer failure.

Evaluate the intake work behind mass tort leads

When comparing a lead source, intake service, or internal workflow, inspect the record that reaches the authorized reviewer. Ask whether it preserves the original source, resolves duplicates without erasing history, applies the correct criteria version, links facts to evidence, exposes exceptions, and transfers into case management with traceable mappings.

That assessment keeps acquisition and intake in their proper relationship. Acquisition creates an opportunity to begin a conversation. Governed intake prepares the record on which the firm can make its own decision.

Book a demo →