Amazon's Batch Sizes Scale Up to 500. Your Admin Stack Wasn't Built for That.

Amazon's new arbitration clause is the most carefully engineered mass arb framework any consumer-facing company has published. It's also an operations test that most plaintiff firms will fail quietly.

Not because the legal analysis is hard. The clause is public. Everyone can read it. The part most firms will get wrong is what happens after they file.

Here's the structure: 25 or more similar claims within six months triggers the mass arbitration designation. At that level, claims proceed in batches of at least 25. Cross 500 total demands, and batches jump to at least 100. Cross 2,500, and you're filing in batches of 500. Each batch has to resolve before the next one moves. There's a 60-day pre-arbitration negotiation window before anything gets filed at all.

That's not a legal problem. That's a claimant-engagement problem. And the firms that treat it like one will be the ones who actually collect.

Three Tiers, Three Different Operational Realities

Most plaintiff firms model mass arb as a single campaign: acquire claimants, file demands, administer the process, settle. Amazon's clause breaks that into stages, and each stage has a different operational profile.

Tier 1 (25 to 499 claims): Batches of 25. Manageable. Your admin stack probably handles this. But even here, the 60-day pre-arbitration window means you need to keep claimants engaged for two months before anything happens at JAMS. That's two months of document requests, status updates, and "when do I get paid?" calls before a single demand is filed.

Tier 2 (500 to 2,499 claims): Batches of 100. Now you have claimants sitting in queue while earlier batches resolve. If each batch takes 90 to 120 days to move through JAMS, claimants in the third or fourth batch are looking at 6 to 12 months of waiting. What's your plan for keeping them responsive?

Tier 3 (2,500+ claims): Batches of 500. This is where most admin stacks break. You're managing a portfolio where thousands of claimants are in various stages of engagement, and the ones who signed six months ago haven't heard anything substantive. They've changed phone numbers. They've forgotten they signed. They've moved. And when their batch finally comes up, you need them to respond to verification requests, sign updated documents, and confirm their claim details.

The math is simple. Every claimant who goes dark between signing and their batch's turn is acquisition spend you've already burned.

The Decay Problem Nobody Models

Here's what I see firms miss consistently: claimant responsiveness is not a fixed number. It decays.

A claimant who signed last week will answer your text in hours. A claimant who signed three months ago and hasn't heard from you will answer in days, maybe. A claimant who signed six months ago and has received nothing but a confirmation email? You're looking at a 30 to 40 percent chance they respond at all without persistent, multi-channel outreach.

Under Amazon's tiered batching, you could easily have 1,500 claimants sitting in queue for 9 to 14 months before their batch is called. If your admin stack's engagement model is "send a notice and wait," you're going to lose a third of those claimants to simple attrition. Not because they withdrew. Because they stopped answering.

That's not a completion rate problem. That's a P&L problem. If your cost per signed claimant was $800 and you lose 500 of 1,500 queued claimants to decay, you just wrote off $400,000 in acquisition spend.

What "Keeping Claimants Warm" Actually Requires

The phrase sounds soft. The infrastructure isn't.

Keeping a claimant engaged across a 12-month queue means:

1. Regular, substantive touchpoints. Not "your claim is being processed" emails. Actual updates on batch progress, timeline expectations, and what they'll need to do when their batch is called. SMS, email, and voice, in that order of effectiveness.
2. Document readiness before the batch opens. If you wait until a batch is called to collect updated IDs, addresses, or signatures, you've added weeks to your timeline and given claimants a reason to disengage.
3. Re-verification at batch activation. Contact information changes. People move. A claimant who signed with one email address eight months ago may have a different one now. Your stack needs to re-verify before, not after, a batch goes live.
4. Automated inquiry handling. When 2,000 claimants are in queue, "when is my turn?" is the most common inbound question. If that question goes to a paralegal's inbox, you're paying $35 an hour for someone to copy-paste the same answer 40 times a day.

This is where owning the stack matters more than it does in any single-batch matter. When your claims administrator licenses its document signing from one vendor, its SMS delivery from another, its email platform from a third, and its caller ID from a fourth, every additional touchpoint is a marginal cost hit across four invoices. The rational economic decision for that admin is to touch claimants less, not more. Their margin improves when your claimants go quiet.

When you own the infrastructure (native document signing, SMS, email, branded caller ID, AI voice), every touchpoint is nearly free at the margin. The incentive flips. More touches cost almost nothing and keep claimants responsive.

The 60-Day Window Is a Feature, Not a Bug

Amazon's 60-day pre-arbitration negotiation requirement is the part most firms will treat as a procedural speed bump. It's actually an operational gift.

Sixty days is enough time to do three things that most firms skip:

• Scrub your claimant roster for duplicates, incomplete documentation, and weak assent records.
• Run a full contact-verification pass so you know which claimants are reachable before you spend filing fees.
• Pre-stage documents so that the moment a batch is called, you can file within days, not weeks.

Firms that use the 60-day window as dead time will enter the batching process with a roster full of ghosts. Firms that use it as an operational sprint will enter with a clean, verified, document-ready portfolio.

This Isn't Just Amazon

PayPal is switching to JAMS with mass arb procedures effective September 2026. Raging Waters has 100-claim batching. Unity has bellwether-plus-global-mediation. The Heisman Trophy's ToS includes staged batching through NAM. This is the new normal.

Every one of these structures creates the same operational challenge: keeping claimants engaged across multi-month, multi-batch timelines. The firms that build (or buy) the infrastructure for that will collect. The firms that don't will acquire claimants they can't convert.

I'm biased. I built a stack specifically for this problem. But the math doesn't care who built it. What matters is whether your admin's economic incentive is to touch claimants more or less over a 14-month queue. If the answer is less, your completion rate under Amazon's clause will tell you exactly how much that cost.