The Workload Brands Rarely Budget For After Campaign Launch

The budget gets approved before launch. That part everyone knows.

Media spend. Prize pool. Platform build. Agency fees. It's all in there, signed off, locked. The campaign goes live. Participation starts climbing. And then something else starts climbing too, quietly, in the background, with no budget line attached to it.

We keep seeing it. A campaign performs well on the metrics that get reported and generates a volume of operating work that nobody planned for. Customer questions about claim status. Receipts that don't meet the validation rules. Rejection disputes from people who are certain they qualified. Payment delays. Support tickets. Manual reviews. Escalations.

None of that appears in the campaign brief. All of it appears after the first claim comes in.

The budget captures the build. It rarely captures what the build creates.

There's a gap between what a campaign costs to build and what it costs to operate. Those are two different numbers. Most brands only model one of them.

The build cost is visible. It's in the purchase order. Someone approved it.

The operating cost is different. It shows up in headcount hours. Support ticket volume. Manual review queues that expand faster than anyone expected when a promotion drives more entries than the planning assumptions allowed for. It shows up in the reconciliation work at the end, when three systems don't quite agree on what was paid out and to whom.

High participation is still a good result. It is not a free result.

Customer questions don't arrive on a schedule.

Here's what We've noticed about the workload that arrives after launch. It's not linear. It doesn't arrive evenly over the campaign period. It clusters.

You get a wave at the start when people can't figure out how to submit. You get another wave mid-campaign when claim status emails go unanswered. You get a third wave near close when people realise the window is ending and they haven't heard back.

If the team handling that volume was sized for the build phase, not the operation phase, those waves hit wrong. Turnaround times blow out. Customers escalate. Someone senior gets a forwarded email from a frustrated entrant and suddenly the campaign's performance story gets complicated.

The promotion didn't fail. The operating model for it did.

Claim exceptions are where the real workload lives.

Not every claim is clean. Most aren't.

A receipt that's blurry. A product that's technically on the qualifying list but the OCR read it wrong. An entrant who submitted twice. A claimant who disputes the rejection with evidence that looks reasonable but doesn't quite meet the terms. Each one of those is a decision. A manual review. A documented outcome.

Multiply that across a campaign that drove 40,000 entries and you've got a significant volume of human judgment calls that need to be made, recorded, and defensible if challenged.

Who's doing that work? Where is it logged? Who owns the decision if a claimant comes back three weeks later with a complaint?

These aren't edge case questions. They're operational questions that should be in the brief before the campaign goes live. I keep seeing them answered after the fact, by whoever's still close enough to the programme to have context.

Reporting workload is the one everyone forgets.

At the end of a campaign, someone needs to produce a wrap report. That sounds straightforward. It isn't, because the data needed to answer the questions in that report often sits across multiple systems that were never designed to talk to each other.

The platform shows entries. Finance has the payout file. The fulfilment partner has the dispatch records. Customer support has the ticket log. Getting those to reconcile into a single coherent picture of what the campaign actually cost to run — not just what it cost to build — takes hours that no one budgeted.

The result is usually a wrap report that tells you what went right and leaves out the stuff that would make the next campaign better.

The trade-off most brands haven't made explicit.

Here's the belief we keep running into: the campaign cost is the cost that was approved before launch.

That's not wrong. It's incomplete.

The real operating cost of a promotion includes the support load it generates, the manual review hours it requires, the payment processing and failed-payout resolution, and the reconciliation effort at the end. A campaign built cheaply can generate a post-launch operating model that costs more than the build did.

There's nothing wrong with a low-cost build. There's something worth knowing about what that build creates downstream.

The cheapest campaign to build is not always the cheapest campaign to run. That's the trade-off. Most procurement decisions don't include it.

What to look for before the next brief gets signed off.

A few questions worth asking before the campaign goes live:

• Who handles claim exceptions, and at what volume does that process break?

• What's the expected support ticket volume, and who owns it?

• How does payment processing and failed-payout resolution get handled?

• What does the post-campaign reconciliation look like, and which systems need to contribute to it?

• Is the wrap report designed to capture operating cost, or just campaign outcomes?

• None of those are complicated questions.

They're just not the questions that tend to get asked before launch.

Does your campaign budget include the work created after the first claim arrives?