220,000 claims landed on one promotion I watched closely this year. The landing page held up fine.
Nobody talks about the landing page anymore once volume like that arrives — because it was never the thing that was going to break.
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.
At 220,000 claims, decisions are the bottleneck. Every claim needs a validation pass — is the receipt real, is the purchase eligible, does the entry match the terms. At low volume, a person can eyeball exceptions.
At six figures, exceptions stop being edge cases. They're a queue. And queues need rules, escalation paths, and someone accountable for the backlog, not just someone fast at data entry.
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.
None of this is really about scale in the way people mean it when they say “scale.” Scale isn't traffic.
Traffic is the easy part — CDNs and load balancers solved that problem years ago. Scale is whether your validation logic, your exception handling and your reporting were designed to hold decisions, not just hold visitors.
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.
What part of your campaign would fail first if claims doubled tomorrow?
