What to do when a live event underperforms mid-flight

An event is running and it is not working. Participation is low, or spending is well below forecast, or players are ignoring it.

There is time left, and the instinct is to fix it. That instinct is right for some interventions and quite wrong for others, and the distinction is about what players have already done.

The interventions that are safe

Anything that adds without changing what already happened is safe.

Extending the event gives everyone more time and takes nothing from anyone. Players who already participated are unaffected; players who have not now have room to.

Adding rewards on top of the existing structure is safe. Nobody is worse off, and players who already earned get the addition too as long as it is applied retroactively.

Increasing visibility is safe and is frequently the actual fix. A meaningful share of underperforming events are underperforming because players did not notice them, and that is a communication problem rather than a design one. Checking whether participants who know about the event are engaging normally, before changing anything, distinguishes the two.

Adding an entry point — a way in for players who are past the point where the event was reachable — is safe and often reaches a population that was excluded by structure rather than by choice.

The interventions that are not

Anything that changes the value of what players have already earned is where the damage comes from.

Increasing rewards mid-event without applying the increase retroactively means early participants got less for the same effort. Those are the players who engaged first — usually your most committed — and they are being penalised for enthusiasm. This generates a specific and justified reaction.

Reducing costs mid-event has the same shape. Players who paid the higher cost earlier have been overcharged relative to those who waited, and they know it.

Changing the structure — the tiers, the goals, the requirements — invalidates the plan players made. Someone who was working toward a specific goal at a specific pace now finds the target moved, and whether it moved favourably or not, their agency was removed.

The rule that covers all of these: if the change would make an early participant worse off than a late one, it needs to be applied retroactively or not at all.

Diagnosing before intervening

The three-day mark is early enough that some of what looks like underperformance is not.

Event participation is rarely uniform across the run. Many events see most engagement in the final days, as deadlines approach. A day-three read against a forecast built on the full run will look bad for an event that will finish normally.

Comparing to the same point in previous comparable events is the check. If day three is proportionally normal relative to previous events' day three, nothing is wrong. If it is genuinely below, something is.

The second diagnostic is whether the problem is reach or conversion. Low participation among players who saw the event is a design problem. Low participation because few players saw it is a visibility problem. These need entirely different responses and the numbers are usually available.

See how we monitor events while they run →

Letting it finish

The option that gets undervalued is doing nothing.

An event that underperforms and runs to completion produces a clean result you can learn from. An event that was modified mid-flight produces a result that describes neither the original design nor the modification, and the lesson is unavailable.

Given that most events are repeated in some form, the information from a clean failure is worth a real amount. Rescuing a single week's numbers at the cost of not knowing why it failed is frequently a bad trade, particularly for an event structure you intend to run again.

The exception is when the event is actively causing harm — a bug, an exploit, an unintended payout — where stopping is obviously correct and the learning is secondary.

For ordinary underperformance, the useful discipline is to write down the diagnosis, add anything additive that is safe, let it complete, and fix the design for next time. That produces both a slightly better week and a genuinely better next event, which the mid-flight rescue does not.

A final point on the diagnosis itself: record it while the event is running, not afterwards. Reconstructing why an event underperformed a week later reliably produces a tidier and less accurate story than the one available at the time, because the ambiguity gets resolved in hindsight toward whatever explanation the team settled on. A few notes written on day three, while the answer is genuinely unclear, are worth more than a confident post-mortem written once the result is known.

The other habit worth having is deciding in advance what would trigger an intervention, before the event runs. A threshold agreed while nobody is under pressure is a much better decision than one made on day three while watching a disappointing chart. It also removes the ambiguity about whether a given number is bad, which is where most mid-flight arguments actually sit — the disagreement is rarely about what to do and usually about whether the situation warrants doing anything.

Talk to us about event operations →