We keep seeing the same assumption in campaign planning: scale means more traffic, more entries, more reach. Teams build for that. They stress-test the checkout flow, the entry form, the servers behind the promo mechanic.
Then the claims start coming in, and the part of the system nobody stress-tested is the part that decides.
Support follows the same curve. A promotion that runs clean at 5,000 entries can generate a support ticket for every twentieth claimant once it hits 220,000 — different customers, same ratio, wildly different absolute load. Nobody plans headcount around a ratio. They plan it around last year's campaign, which was smaller.
Reporting is the quiet one. It looks fine until someone asks a specific question — how many claims were rejected and why, how many payments are still pending, what the exception rate looks like by channel. A system that can produce a dashboard can't always produce an answer. Those are different capabilities, and volume is what exposes the gap between them.
We've noticed the campaigns that survive high volume aren't the ones with the biggest budgets. They're the ones where someone asked, before launch, what happens at ten times the expected entries. Not as a hypothetical. As a design question.
Where does the tenth validator sit? What's the escalation path when a claim doesn't match cleanly? Who signs off on a batch exception when there are 4,000 of them, not four?
To be clear — not every campaign needs this. A regional promotion expecting 3,000 entries doesn't need enterprise claims infrastructure. That's a different build, for a different volume. The trade-off is real: building for scale you don't need is its own kind of waste. But the campaigns that get surprised are the ones that guessed wrong on which side of that line they were on — and found out from the queue, not from the plan.
220,000 claims will tell you exactly where your operating model was designed and where it was assumed. The gap between those two things is usually invisible until volume forces it into view.