The deadline is six weeks out. You have 140,000 documents, four reviewers, and a partner asking daily for a completion forecast. Fact: most e-discovery project managers answer that question with a gut feeling dressed up in a spreadsheet. There's a better way.
Review velocity is the number that tells you whether the matter is on track. Not the number of documents coded total, but the rate per reviewer per hour, measured against the remaining document population and the recall target you've committed to. In our tracking across high-volume matters, we see teams fail deadlines not because reviewers work slowly, but because nobody caught the pace risk until the final two weeks.
This article covers how e-discovery project managers can build a working velocity model, what to do when pace deviates from forecast, and how matter-level metric separation keeps multi-matter shops from fooling themselves with blended averages.
Baseline Velocity: What 60-80 Docs/Hour Actually Means
The industry baseline for a first-pass linear review sits at 60 to 80 documents per hour. That number is a starting point, not a contract. Document complexity, issue density, and language variation all push it around. In our experience, a collection heavy with financial spreadsheets and embedded images often runs 40 to 55 docs/hour. Straightforward email threads from a focused date range? Some reviewers hit 90.
What matters is establishing your baseline on this collection, not borrowing an industry average. The first coding batch tells you a lot. After the first 5,000 documents, you should have a per-reviewer velocity number that's meaningful. Before that, you're estimating.
Here's the thing: velocity is not one number per matter. It's one number per reviewer. Blending a 45 doc/hour junior associate with an 85 doc/hour senior lit support specialist and reporting a single 65 doc/hour average hides your actual throughput risk. When the senior reviewer is pulled for a deposition prep, that average falls off a cliff and you won't see it coming if you've been watching the blended figure.
Track individually. Report individually. Aggregate only when you're briefing up the chain and need a single headline number.
Connecting Velocity to Recall: The Real Forecast Input
Velocity without a recall target is just counting. The question that matters is: how many documents does the reviewer population need to code before active learning reaches 90% recall at the current depth?
Discovarc surfaces projected total hours to 90% recall as a standing dashboard metric, updated after each coding batch. That number changes. Early in review, active learning models improve rapidly, sometimes cutting projected hours by 15 to 20% after a single productive batch of 2,000 codes. Later in review, the model is more mature and gains are smaller. Forecasts made in week one are inherently rougher than forecasts made after 30,000 documents.
The dashboard update cycle matters more than most teams realize. If your velocity metrics refresh once a day at midnight, you're operating on stale data for the first 12 hours of every working day. For matters with tight deadlines and multiple reviewers, batch-level updates, triggered each time a reviewer submits a completed coding queue, give you a materially better forecast. Twelve hours of stale pace data is two to three reviewer-hours of undetected drift.
What does a usable forecast look like? Something like this:
| Metric | Current Value | Pace Risk |
|---|---|---|
| Remaining docs to 90% recall | 28,400 | Baseline |
| Active reviewer team velocity | 312 docs/hour | Low |
| Projected hours to completion | 91 hours | Low |
| Available reviewer hours (5 weeks) | 110 hours | Low |
| Buffer | 19 hours (21%) | Acceptable |
That 21% buffer looks comfortable today. But a single reviewer leaving for a week cuts available hours by roughly 22 hours. Buffer gone. This is why pace risk identification has to happen before the deadline, not the week before production.
Identifying Pace Risk Early
In our experience, pace risk shows up in three predictable patterns. Knowing which pattern you're in shapes the response.
Pattern 1: Steady underperformance. A reviewer is consistently coding 20 to 25% below the established baseline. Not one bad day, a sustained trend over five to seven sessions. This usually means the reviewer is struggling with issue identification, not work ethic. The fix is targeted QC feedback, not more hours.
Pattern 2: Velocity cliff. A reviewer drops from 75 docs/hour to 35 docs/hour mid-matter. Sudden drops are almost always collection-related: a new document set with different characteristics entered the queue. Custodian-level document profiles help here. If you know this custodian's files run 60% attachments with embedded spreadsheets, budget accordingly.
Pattern 3: Recall plateau. Velocity is fine, but the active learning recall rate stops climbing at 82% and stalls. More coding isn't moving the needle. This signals that the seeded training set is not representative enough of the remaining population. The right response is targeted sampling from the stalled document clusters, not generic random sampling. Honestly, this is the pace risk pattern most teams catch too late.
Each pattern requires a different intervention. A project manager who only watches total documents coded sees none of them until the matter is already in trouble.
Matter-Level Metric Separation
If your shop is running five matters simultaneously with shared reviewer resources, blended metrics will consistently mislead you. We've found this is one of the most common root causes of missed production dates in multi-matter environments.
The correct approach is separate recall tracking and separate velocity tracking per matter, with shared-reviewer utilization logged across matters. A reviewer who codes 4 hours on Matter A and 3 hours on Matter B appears in both matter dashboards with their actual hours allocated, not as a fractional average.
Why does this matter? Because cost-per-document vs. matter budget is a per-matter number. If Matter A is running $0.38/document against a budget built at $0.30/document, you need to know that before the billing cycle closes, not after. Cross-matter averaging hides over-budget matters behind on-budget ones.
The reporting structure Discovarc uses separates the matter dashboard completely: recall curve per matter, velocity per reviewer per matter, projected completion per matter, budget burn per matter. The aggregate view exists for portfolio reporting. The matter view is what the PM uses to run the engagement.
When the Forecast Changes, Say So Immediately
Real talk: the hardest part of velocity management is not the math. It's delivering an updated forecast to a partner who built their deposition schedule around your original completion date.
The right approach is early, specific, and options-oriented. Not "we're behind" but "at current pace, production slips five days. We have three options: add one reviewer for two weeks (adds $4,200), reduce scope to Tier 1 documents only (reduces recall to an estimated 84%), or extend production to the revised date. Your call."
That conversation is only possible if your velocity data is accurate, current, and tied to a specific recall forecast. Which is why the dashboard that updates after each coding batch, not once a day, is not a nice-to-have. It's the operational foundation of the whole matter.
Six weeks. 140,000 documents. Four reviewers. With per-reviewer velocity tracking, batch-level dashboard updates, and matter-level metric separation, that's a manageable matter. Without them, it's a guessing game until week five.
