Attorneys · 12 min read
Text Message Evidence Intake Checklist for Law Firms
A repeatable client-intake and review handoff for large message records, participant mapping, source inventory, date scope, privacy, and report delivery.
The short answer
An intake that works gives the review team five things before analysis starts: a defined matter scope, an inventory of source artifacts, a participant map, a date and issue range, and a named set of deliverables. Without them, review time goes on reconstructing the assignment rather than doing it. The part most often skipped is the chain — who collected each file, when, by what method, what changed after collection, and where the client-preserved original is being kept. That information is cheap to capture at intake and expensive to recover later, because it is the first thing asked about when an excerpt is challenged and the hardest thing to reconstruct honestly from memory. Build the intake so the client preserves and hands over rather than edits and hands over: a redacted, converted, or re-exported file arriving as the only copy is a problem discovered far too late to fix. Do not begin with “send every screenshot you have.” Begin with a short source interview. That prevents mixed conversations, unlabeled phone numbers, reversed sender directions, missing date ranges, duplicate exports, and client-created PDFs from entering the workspace as if they were one clean record.
The intake record
Matter and purpose — Matter label, requesting professional, intended review, and deadline. — Unbounded review and reports that answer the wrong question. Record owner — Who controls the device, account, export, or screenshot set. — Confusion between the client, collector, sender, and account holder. Platform and source — iPhone, Android, WhatsApp, Messenger, Instagram, email, PDF, CSV, backup, or screenshots. — Treating every file as the same kind of source. Conversation scope — Thread name, participants, date range, group status, and known gaps. — Merged matters and accidental group-chat collapse. Collection event — Collector, date, method, settings, storage location, and hash. — A missing handling trail between the source and the review copy. Requested output — Searchable timeline, issue index, excerpts, PDF, CSV, manifest, redaction copy, or reviewer queue. — Building a polished packet that the team cannot use.
Interview the source before accepting the file
The client usually knows facts that the file cannot prove by itself: which phone produced the export, whether the contact name changed, whether a conversation continued on another app, why a date range is missing, and whether screenshots were cropped or reordered. Capture those facts as intake notes, not as message content. Keep source facts separate from advocacy. “Exported from the client’s iPhone on July 15” is a collection fact. “This thread proves obstruction” is a case conclusion. The intake form should establish the first without deciding the second. Who owns or controlled the device and account? Who created the export, screenshot set, PDF, or spreadsheet? What exact steps and settings were used? Does the source cover one conversation, several conversations, or a group? Were attachments, reactions, replies, deleted indicators, or call events included? Are there known gaps, earlier exports, replacement phones, changed numbers, or account migrations? Was any file edited, renamed, filtered, merged, converted, or redacted?
Build the source inventory before upload
Assign a neutral label to every artifact before it enters the review workspace. Keep private filenames in the internal inventory and use labels such as Source A or Screenshot Set B in shared reports. Record hashes before conversion when the collection workflow allows it. Overlapping files are not automatically redundant. A full export, a screenshot set, and a PDF may each show a different part of the record. Preserve all three, describe their relationship, and choose one primary source for row-level review only after comparison. Artifact label — Source A — Android XML export Owner-preserved filename — Stored privately in the matter inventory Collected by and date — Client export; received 2026-07-15 File facts — Type, byte size, hash, row count, page count, or image count Coverage — 2024-01-01 through 2026-06-30; one known gap Participants — Raw numbers, emails, handles, display names, and group labels Media — Included, separate folder, unavailable, or not requested Working-copy changes — Converted to CSV; names redacted in sharing copy
Confirm participants before issue review
Participant attribution affects every sender-specific count and timeline. Ask the client to map phone numbers, emails, usernames, contact names, Me/You labels, and changed aliases before the team relies on issue totals. Preserve the raw labels beside the reviewed names. When the system can separate two speakers but cannot tell which one belongs to the client, ask one focused orientation question. If a sender remains unresolved, keep it unresolved. Do not infer identity from tone, pronouns, relationship role, or the content of the message. Record every raw sender identifier found in the source. Ask whether contact names changed during the date range. Separate quoted authors and forwarded content from thread participants. Identify group membership changes and system messages. Confirm which direction belongs to the client only when source evidence or the client can establish it. Hold sender-specific metrics when a material part of the map is unresolved.
Define date scope and issue scope separately
A legal team may need a two-year source record but only a six-week event timeline. Record both. The source range tells the reviewer what was available; the review range tells the analyst what the current assignment covers. Issue scope should use observable questions: repeated contact after a stated boundary, missed exchanges, withheld scheduling details, threats, payment demands, deletion pressure, or contradictory statements. Avoid intake labels that assume the legal conclusion before the source has been read. Source range — What is the earliest and latest record supplied? — Show full available coverage and gaps. Review range — Which dates need focused review now? — Filter the working view while retaining source references. Event anchors — What exchanges, hearings, complaints, payments, or boundaries matter? — Add neutral event markers with supporting documents. Issue questions — What observable conduct should reviewers locate? — Create review lanes without turning them into findings automatically. Output audience — Client, attorney, investigator, mediator, expert, or internal team? — Set redaction, detail, citation, and export choices.
Handle messy collections explicitly
Large client collections often contain the same export twice, screenshots from both parties, partial PDFs, copied notes, reversed timelines, and files with no sender headers. Intake is where those facts should be named. A file should never be promoted to “complete conversation” merely because software can extract rows from it. Create a follow-up queue for password-protected files, unsupported archives, unreadable scans, mixed conversations, group chats, missing participants, ambiguous direction, and excessive unknown senders. The review team can then request the smallest missing fact instead of asking the client to start over.
Set privacy and handling rules before sharing
Message histories can contain addresses, children’s names, medical details, financial records, account identifiers, and third-party conversations. Decide who may access the source, which copy may be shared, what must be redacted, how long the workspace should remain active, and where final exports will be stored. ABA Formal Opinion 477R discusses a lawyer’s duty to make reasonable efforts when transmitting client information. The specific safeguards depend on the information, the risk, available controls, and the legal team’s own professional obligations. Put those decisions into the matter workflow rather than leaving them to an email chain. Use an authenticated collection route instead of ordinary email when the record is sensitive. Restrict source access to the assigned matter team. Keep owner-preserved sources separate from redacted sharing copies. Remove client filenames and private identifiers from public or demonstrative packets. Document retention, deletion, download, and external-sharing decisions. Check analytics and error-reporting fields so message content is not transmitted as telemetry.
Define the handoff before analysis begins
A good intake ends with a written handoff: source artifacts accepted, records rejected or waiting, participant map status, source range, review range, issue questions, redaction classes, requested exports, reviewer, and deadline. That handoff becomes the control sheet for the workspace. For a supported two-person file, Textimony can provide participant confirmation, a searchable run-bound timeline, daily activity charts, review candidates, and reports. The legal team still owns its source inventory, redaction record, final packet, and approval process.
What should a client send first?
Facts before files. Ask first for the platform, the accounts and numbers involved, the date range, and what artifacts exist — then send the files through the firm’s authenticated collection route. Inviting a client to email every screenshot they have produces an unstructured pile with no provenance, usually duplicated, sometimes cropped, and it puts client material through a channel the firm would rather not have used.
Should the firm combine all message files before upload?
No. Merging first destroys the information you need to review: which file each message came from, where two exports overlap or contradict, whether a thread was one-to-one or a group, and how each artifact was produced. Keep the sources separate until those comparisons are done, then create a documented working copy that records what was combined and on what basis.
Who should confirm the participant map?
Start with the structural fields in the export rather than with anyone’s recollection, since those are checkable. Where an alias or the direction of a message stays unresolved, put a focused question to the record owner instead of inferring. Keep both the raw identifiers and the confirmation itself in the audit trail, so a later reader can see which mappings were derived from the file and which came from a person.
What should the final handoff include?
Everything the next person needs to work without re-deriving your decisions. That means the source inventory and participant map, a statement of what the record covers and where it has gaps, the issue questions being asked of it, the redaction plan, and the outputs requested. Add the assigned reviewer, the deadline, and retention instructions, so the file does not sit in an undefined state after the work is done.
Published by
Textimony. Editorial status: Source-linked informational guide. Updated: 2026-07-16.
Sources
Federal Rule of Evidence 901; Federal Rule of Evidence 1006; NIST IR 8387: Digital Evidence Preservation; NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics; ABA Formal Opinion 477R: Securing Communication of Protected Client Information