A 'Small' Case With Chat Data Isn't a Small Review Job

The wrong variable is driving too many eDiscovery decisions. Attorneys size up a matter, count the custodians, estimate the volume, and reach for a keyword tool that fits the headcount. What that calculation misses is the composition of the data.

Slack threads, Microsoft Teams channels, and iMessage archives behave differently from email and Office documents in every dimension that matters for review: preservation windows, export format, thread context, and privilege identification. A five-custodian matter with three years of active Slack use can present more review complexity than a forty-custodian email-only case. According to eDiscovery practitioners who track review failure patterns, the mismatch between tool selection and data type is where most small-matter review failures originate, not in the number of documents or the number of custodians.

I developed a data-type test after watching keyword-only workflows break on matters that looked straightforward on paper. Before any tool is chosen, three questions settle the issue: What sources are in scope? Do any require specialized processing? Would keyword search produce a complete, verifiable result on those sources?

Why Is Chat Data Now Present in Most Litigation Matters?

Chat data from Slack, Teams, and iMessage now appears in the majority of litigation matters, not just large, complex ones. The collection job has changed. The tooling habits have not.

According to RelativityOne, 75% of matters entering the platform now have short-message data associated with them. That figure is striking not because it describes a fringe practice but because it describes the center. The majority of important business decisions, the ones that generate the emails lawyers once searched, now live in Slack channels, Teams threads, and iMessage chains instead. An analysis of eDiscovery processing patterns across platforms shows that short-message evidence has become a default feature of modern litigation, not a specialized edge case reserved for securities class actions or large employment disputes, as of September 2026.

I find it useful to apply what I call the data-type test before sizing any matter. The test asks one question at intake: what types of data sources are in scope? Not how many custodians. Not what the case is worth. The answer to that single question tells you more about what the review will require than any other variable at the outset of a matter.

In practice, the data-type test surfaces three distinct categories. The first is traditional: email archives, PDF documents, and Office files. Most review teams have mature processes for these sources. The second is structured collaboration data: Slack channels, Microsoft Teams threads, Zoom meeting transcripts. These require specialized ingestion and cannot be treated as flat text without losing context. The third is mobile and ephemeral data: iMessage, WhatsApp, Signal, and similar platforms where retention settings, encryption methods, and user controls vary by app and create unique collection challenges on each matter. The third category is where the smallest matters most often fail.

A common misconception is that chat data only matters when the case is large enough to justify enterprise tooling. The reality is the opposite. A two-custodian employment dispute in which the entire relationship between the parties lived in a Slack workspace can produce tens of thousands of messages. Keyword search on a flat JSON export of that workspace will miss context, miss threaded replies, and miss the reaction metadata that sometimes proves who saw what and when. The volume is modest. The complexity is not.

In summary: the presence of chat or mobile data in a matter is the variable that determines review complexity, and it is independent of headcount, monetary value, or case scope.

Why Can't Keyword Search Alone Handle a Chat-Data Review?

Keyword search was built for email, where each message is a discrete document with a header, a body, and a date stamp. Chat platforms are architecturally different, and the difference matters to the review.

Consider what a Slack channel export actually produces. The standard export format is JSON: a structured data file that captures message text, timestamps, user IDs, reactions, and threaded reply references, but presents them in a format designed for software to read, not humans to review. Running a keyword search on that raw JSON will surface the term you searched for, but it will strip the thread context that gives the term meaning. A message that reads "confirmed" in isolation tells you nothing. The same message, read as the third reply in a thread where a manager explicitly approved the conduct at issue, tells you everything.

According to Lighthouse Global, most eDiscovery teams have established processes for traditional data types, including PDF scans, Microsoft Office files, and email, but not for newer sources such as Teams and Slack. In practice, that competency gap is exactly where small matters go wrong. The attorney or paralegal assigned to the matter has a mature workflow for the email archive and no tested workflow for the workspace export sitting in the same production set.

The preservation problem is at least as serious as the search problem. According to Lighthouse Global, deleted Apple iMessage entries may be permanently removed after a 30-day window if the device settings have not been configured to preserve messages indefinitely. That window does not pause while you identify custodians, draft a hold notice, and wait for acknowledgment. It runs from the date the adverse event occurred, not from the date the complaint was served. In my experience, that gap between event and hold is precisely where small firms lose data they did not know they needed.

The takeaway here is straightforward: chat data requires a different ingestion pipeline, not a different search term. What this means for the small firm is that the right question at intake is not "what keywords should I search?" but "does my tool reassemble threads and preserve context before I even begin reviewing?"

Tiered product design reinforces the problem. Entry-level eDiscovery tools market themselves for small and medium investigations while reserving advanced data analysis for premium tiers. The division made sense when small investigations reliably involved only email. It no longer maps to how business communication actually works.

In summary: keyword search without thread reassembly is not a methodology gap on a chat-heavy matter. It is a defensibility gap.

How Does AI-Assisted Review Hold Up in Court?

AI-assisted document review now fits within existing discovery frameworks at every matter size, and no special justification from the producing party is required.

According to eDiscovery practitioners who track review failure patterns, the judicial treatment of AI-assisted review has shifted more meaningfully than the technology itself. The Sedona Conference proportionality principles and case outcomes like Schulte v. LinkedIn establish that AI-assisted review fits standard review frameworks. Courts evaluate whether the process was reasonable and the output defensible. The tool used is a secondary question. A firm does not need to justify the technology separately from the underlying review methodology. What the court examines is whether the collection was complete, the threads were reconstructed, and the privilege review was documented before production, not which platform did the work.

How Do You Decide Between eDiscovery Platforms When the Case Looks Small?

Most platform comparisons start with the wrong question. "Relativity or something else?" is a question about brand. The right first question is whether this matter's data composition requires platform-level capabilities at all.

The market has answered this by segmenting on case size. Entry-tier tools target small and medium investigations; enterprise tools serve large and complex ones. That segmentation is rational and has served buyers well in an email-centric world. The problem is that the market has no shared definition of what makes a matter "complex" beyond headcount and document volume. Data type, the variable that actually determines review difficulty, does not appear in most vendor decision guides or feature matrices.

I have watched this create a specific pattern. A firm sizes a matter as small, selects tooling appropriate for a small matter, and only discovers the mismatch after ingestion fails or opposing counsel raises a challenge. The cost of that discovery is not the cost of the right tool from the outset. It is the cost of the right tool, plus the cost of the wrong one, plus the cost of a re-do. That is the actual risk the case-size heuristic creates.

The AI eDiscovery community has moved faster than the buyer guidance has. Panelists at an EDRM-hosted webcast on AI and eDiscovery noted that two years ago, letting AI make final relevance calls would have raised eyebrows in most legal departments, and that the skepticism has largely faded. Over a hundred million documents have been analyzed using AI-assisted review. What this means is that the technology is no longer experimental, but the decision framework for deploying it on a given matter, any matter, has not caught up.

The takeaway is a three-question intake test. First: does this matter include any chat or mobile data source? Second: are any custodians on iOS devices without verified preservation settings? Third: does my current tool ingest the export format these sources produce natively? If the answer to any of these questions is uncertain, the matter is not a small matter in tooling terms, regardless of how small it looks in monetary or custodian terms.

In practice, this test takes less than five minutes. It is the decision framework the market currently lacks, and it is the framework that prevents the expensive mismatch between data reality and tooling choice.

Raw chat exports from Slack and Teams arrive as JSON with no thread context, no rendered sender names, and no timestamps mapped to case timelines. According to court records analyzed in recent eDiscovery scholarship, this format is the point where most lightweight review tools break down irreparably.

// Raw Slack export fragment - what a lightweight tool receives
{
  "type": "message",
  "text": "Let me know when the docs are ready",
  "ts": "1698765432.000100",
  "user": "U04X7ABC"   // no display name, no thread context
}

How Can You Reduce Document Review Costs Without Sacrificing Defensibility?

AI-assisted review runs cents per document. Manual review costs roughly $19,000 per gigabyte. The gap is demonstrable on any matter, small or large, and it is not contingent on case size.

That comparison is the most important number in this conversation, and I want to be precise about what it means. Manual review at roughly $19,000 per gigabyte is not a catastrophic figure on a ten-gigabyte email archive where the firm has been billing a large corporate client for years. It is a catastrophic figure on a two-custodian employment dispute where the "small" data footprint turned out to include a Slack workspace, a shared OneDrive folder, and three years of iMessage threads. The problem is not the rate. The problem is that the rate applies before you know what you have.

The re-do scenario is where small-matter economics truly break down. When a lightweight-tool approach fails, not because the tool was bad but because it was not designed for the data it received, the cost is not the cost of switching tools. It is the cost of re-collecting from the original sources, re-processing the data through a capable platform, re-reviewing the documents with the benefit of proper thread context, and producing again under tighter scrutiny from opposing counsel who now has grounds to challenge the original work product. In my experience, the economics of that scenario dwarf the original tooling cost by an order of magnitude.

The good news is that the economics of defensible review have fundamentally changed. Platforms built to serve solo and small firms on a single messy matter can now deliver the same chain-of-custody spine, privilege gate, and AI-assisted coding that enterprise engagements use, at a price point that makes sense for a single matter rather than a platform subscription. That is a structural shift, not a marketing claim. The segment that Relativity and Everlaw price out of their standard offerings is now a serviceable market precisely because AI-assisted review has separated the cost of careful review from the cost of enterprise overhead.

The takeaway is practical: the question is not whether you can afford defensible tooling on a small matter. It is whether you can afford the re-do if the wrong choice fails. What this means for most solo and small firms is that the break-even analysis runs in the other direction from what intuition suggests.

In summary: the cost of AI-assisted review is measured in cents per document; the cost of a failed small-matter review is measured in multiples of the original budget.

What Does a Defensible Small-Matter Review Actually Require?

A defensible review has four structural requirements that hold regardless of case size: source-linked outputs, an immutable chain of custody, a fail-closed privilege gate, and data isolation that keeps privileged material under your control.

These four requirements are not aspirational. They are the minimum standard a review process must meet before an output can be verified, certified, or defended if opposing counsel requests inspection of your methodology. Enterprise platforms have long supplied the first three through Bates numbering, audit trails, and privilege log automation. What has changed is that the new generation of AI-assisted review tools supplies the fourth requirement in a form that smaller firms can actually operate: cited, source-linked outputs that trace every finding back to the exact exhibit that supports it.

In practice, this means that when a reviewer asks a question about the collection and receives an answer, that answer comes with a pointer to the specific document, message, or thread excerpt that produced it. The reviewer can one-click verify before filing or certifying. That architecture is the direct structural answer to the concern that AI introduces unverifiable reasoning into a process that courts may later scrutinize. The answer is verifiable. It lives in the record.

The second requirement, an immutable chain of custody, means that originals are preserved with content hashing and that the audit trail is append-only. Nothing in the review process can alter the original. Privilege decisions are logged. Production is gated so that nothing reaches the opposing party without a reviewable privilege determination having been made first. If opposing counsel challenges the collection, the audit trail answers the challenge without requiring the attorney to reconstruct what happened from memory.

The third requirement is data isolation. For many small firms, the practical concern is not just defensibility but privilege. Feeding client documents through a shared cloud AI tool, where data may be retained or used for model training, is a posture that privilege doctrine does not protect well. Processing that runs single-tenant, or inside the firm's own cloud account under its own keys, with no vendor retention and no model training on client data, resolves that concern structurally. The privilege question answers itself.

I'd recommend testing any platform against these four criteria on a real collection before committing. Bring a messy collection and a hard question. Watch whether the output cites its source or merely asserts an answer. The test takes an hour and tells you more than any feature matrix will.

What Will eDiscovery Look Like for Small Firms in the Next 12-24 Months?

AI-assisted review will move firmly down-market. Platforms combining chat-data processing with source-linked AI are absorbing capabilities that only enterprise tools offered two years ago.

According to RelativityOne, the majority of matters entering the platform now carry short-message data. That share is growing, not stabilizing. The review teams that adapted first to chat-data workflows are already running at lower per-document cost and higher defensibility than those still relying on keyword-only culling. The direction is clear.

• Short-message evidence becomes the default in civil litigation. Over the next 12-24 months, Slack, Teams, and text archives will be present in most matters that reach serious review, not just the large or complex ones. The weak signal is already visible: enterprise platforms have built native chat-rendering pipelines because they see it in incoming volume. The implication for small firms is that a matter with three or four custodians and active Slack use can no longer be treated as a light job. Source: RelativityOne platform data (C-4).
• AI-assisted review pushes into matters of all sizes. Courts have been fitting AI methodologies into existing discovery frameworks, and cost pressure will extend that pattern to small-firm matters within 24 months. The weak signal is that attorneys are already asking how to run technology-assisted review and how to cut review costs. AI-assisted review at a fraction of the per-document cost of manual review delivers a durable speed and cost advantage. Source: Lighthouse Global industry analysis (C-2).
• The case-size heuristic stops working as a selection criterion. The Microsoft 365 split between eDiscovery Standard and eDiscovery Premium reflects the industry's current assumption that complexity scales with case size. That assumption will erode. Most review teams have mature workflows for email and Office files but not for newer chat sources. Choosing a tool by headcount alone risks under-equipping a data-heavy small matter. Source: Microsoft 365 licensing documentation (C-5).

What most buyers miss is that this transition is already underway. The platforms built for chat-data ubiquity and source-linked AI are not anticipating 2026. They are handling today's cases. The firm that waits for industry consensus to catch up will be explaining a flawed production to opposing counsel before that consensus arrives.

The data-type test is not a theory. Short-message data now appears in the majority of matters that reach serious review, and the variable that decides whether a review job is genuinely hard is whether the collection contains a source that keyword search cannot reliably handle. That variable is no longer rare.

From what I have seen, the failure pattern is consistent. A firm sizes the matter by headcount, selects a keyword tool to match, and does not discover the gap until production is underway. At that point, the cost of the redo is compounded by the cost of explaining to a client why the first approach did not hold. That explanation is never easy.

The moment Slack, Teams, or iMessage appears in scope, the matter has crossed a threshold. The question after that point is not whether to invest in defensible processing. It is which platform clears that bar without requiring enterprise pricing or a dedicated IT team.