You drafted an ESI protocol during the Rule 26(f) conference. The court approved it. Both parties signed off. Then, six months into discovery, you're facing a motion to compel because your protocol didn't account for the 47,000 Slack messages your opposing counsel now insists are responsive documents.
This scenario repeats across litigation teams because ESI protocols often look defensible on paper but collapse under the reality of modern data environments. The mistakes aren't random. They follow predictable patterns rooted in outdated assumptions about where enterprise data lives and how discovery actually unfolds.
Why These Mistakes Keep Happening
ESI protocols fail because legal teams negotiate them before fully understanding the data landscape they're committing to search. You're drafting preservation and production rules while IT is still mapping custodians. You're agreeing to search terms before anyone has scoped the collaboration platforms where half your relevant communications actually live.
The Federal Rule of Civil Procedure 34 framework assumes you know what electronically stored information exists and where to find it. But most organizations don't maintain current data maps. The protocol gets finalized, becomes a court order, and only then does the team discover that "email and shared drives" covers about 30% of the actual responsive data.
Mistake 1: Treating Collaboration Platforms as Edge Cases
Why it happens: Your protocol lists "email, file servers, and other electronic repositories" as data sources. That phrase feels comprehensive. It's not.
The consequence: When opposing counsel requests Slack threads, Teams chats, or Asana project comments, you're forced back to court to amend the protocol or argue that collaboration data isn't discoverable under the original agreement. Neither position is strong. The court will likely order production and question why you didn't identify these sources during meet-and-confer.
The fix: During protocol negotiation, require IT to provide a written inventory of every platform where business communications occur. Don't accept categories. Get specific system names: which chat tools, which project management platforms, which shared workspaces. Then explicitly list them in the protocol's data source section, even if you believe they contain minimal responsive material.
Mistake 2: Defining "Custodian" Too Narrowly
Why it happens: You identify custodians as individuals with direct knowledge of the disputed facts. That's correct for depositions. It's incomplete for ESI.
The consequence: Relevant communications live in shared channels, group chats, and collaborative documents that don't belong to any single custodian. Your protocol obligates you to preserve and search "custodial data," but the most important threads are non-custodial by design. When you produce incomplete records, you're not hiding evidence. You're following a protocol that didn't anticipate how your organization actually communicates.
The fix: Distinguish between testimonial custodians and data custodians in your protocol. Testimonial custodians are the people you'll depose. Data custodians include shared workspaces, departmental channels, and collaborative repositories. Define preservation obligations for both categories separately.
Mistake 3: Locking In Search Terms Before You Understand the Data
Why it happens: The court wants the protocol finalized. Opposing counsel is pushing for specific search terms. You agree to a list of keywords that seem reasonable based on the pleadings.
The consequence: Six weeks later, your review team reports that the agreed terms are returning 80% irrelevant hits in Slack because people use those words casually in channels. Or the terms miss critical conversations because your organization uses internal shorthand that didn't appear in the complaint. You're contractually bound to review thousands of false positives or you're failing to capture responsive material, depending on which direction the terms skew.
The fix: Negotiate a two-phase search methodology in your protocol. Phase one: run a sample search across a representative data set to test term effectiveness. Phase two: refine terms based on precision and recall metrics before full collection. Build in a meet-and-confer checkpoint between phases where both parties can adjust the approach without court intervention.
Mistake 4: Specifying Production Format Without Testing Feasibility
Why it happens: Federal Rule of Civil Procedure 34 says you can request ESI in a specific format. Opposing counsel requests native files with full metadata. You agree because it sounds defensible.
The consequence: Your collaboration platforms don't export native formats that preserve threading, reactions, and edit history in a reviewable structure. You're committed to a production format your systems can't generate without expensive third-party processing. The alternative is producing PDFs, which opposing counsel will argue violates the protocol.
The fix: Before agreeing to any production format, verify that your preservation tools can actually export data in that format while maintaining required metadata fields. If native production isn't feasible for certain platforms, propose format-specific provisions: native for email, structured exports for chat platforms, and define exactly which metadata fields must be preserved for each source type.
Mistake 5: Ignoring How AI Review Fits Into Defensibility
Why it happens: Your protocol addresses search terms and production formats but says nothing about review methodology. That seems fine because review happens after production, so it's outside the protocol's scope.
The consequence: When you use AI to prioritize review or identify patterns in collected data, opposing counsel questions whether your review was thorough. Without protocol language establishing how AI-assisted review supports defensible decision-making, you're defending your methodology in motion practice instead of citing an agreed framework.
The fix: If you plan to use AI in your review workflow, address it in the protocol. Specify that both parties may use technology-assisted review, define what constitutes a defensible sample for validation, and establish that AI tools support but don't replace attorney review. This creates a record that your approach was transparent and agreed upon, not a post-collection shortcut.
Prevention Checklist
Before you finalize your next ESI protocol, verify:
- IT has provided a written inventory of all platforms where business communications occur
- The protocol distinguishes between testimonial custodians and data custodians
- Search methodology includes a testing phase before full collection
- You've confirmed your tools can export data in the agreed production format
- Platform-specific metadata requirements are explicitly defined
- The protocol addresses how technology-assisted review may be used
- A meet-and-confer checkpoint is built in for methodology adjustments
- Preservation obligations account for dynamic content in collaboration tools
- The scope section lists specific systems, not just categories of data
An ESI protocol is a court order, not a planning document. Once it's finalized, you're bound by its terms even when they turn out to be incomplete. The time to identify gaps is during negotiation, when you can still build in flexibility for the data environment you're actually working in.
