SportsFirst

Season pass price change scenario simulator

Data & reportingMicro-tool2 week prototypeTest or simulatePrototype-ready

Problem

A season pass price increase is usually decided in a single meeting between the head of ticketing, finance and sometimes a sales manager, based on last year's uptake and what feels defensible to members. Nobody in the room can say what a five per cent rise on the lower tier would do to renewal counts in that section versus the upper tier, because the only model that exists is a spreadsheet finance rebuilds once a year and keeps on its own machine. By the time the new price is printed on renewal notices and announced to the base, the assumption behind it has never been tested against the account-level data sitting in the ticketing platform. If renewals fall short, the shortfall is discovered weeks later in the chase spreadsheet, not in the meeting where the number was set.

Product idea

A scenario tool built around the season pass base rather than a general pricing model. Upload or paste the current account list by section and price tier, each with its current price and renewal status. Set a small number of levers: a proposed price change per tier, and an assumed renewal sensitivity, how many members are expected to lapse for a given rise. The tool runs the levers against the actual base and shows projected renewal count, revenue and lapse count per section, side by side with the current state. It deliberately does not predict renewal behaviour on its own. Every projection is stated as a consequence of the assumptions entered, so the number in the board pack is traceable to a stated assumption rather than a feeling in the room.

Who it is for

Heads of ticketing, membership managers and sales managers who set season pass pricing, and the finance or commercial lead who signs off the renewal notice before it goes to print.

Possible first version

A web app that accepts a CSV export of season pass accounts by section, tier, current price and renewal status. Staff enter a proposed price change and an assumed sensitivity per tier, and the tool outputs a comparison table and chart of projected renewals, lapses and revenue against the current baseline, exportable as PDF or CSV. Multiple scenarios can be saved and compared side by side. Version one has no connection to the ticketing platform, the CSV upload is the integration, and there is no automated elasticity model. The sensitivity figure is entered by the user, not calculated.

Build classification
Micro-tool
Rough effort
2 week prototype
Roles involved
Head of ticketing, Membership manager, Sales manager
Relevant to
Professional club, Women's league, Venue & stadium operator, League office
Systems in play
Ticketing platforms, Spreadsheets, CRM
Product framing
Test or simulate

Questions we get asked

What data do we actually need to have ready before we can run a scenario?

A CSV with one row per season pass account showing section, price tier, current price and whether that account renewed last cycle. Most ticketing platforms can export something close to that already. There is no need to wait for a perfect export: a sample of one or two sections is enough to see whether the output is useful before pulling the full base.

Finance already builds a pricing model in Excel every year. Why would we need this as well?

It might sit alongside that model rather than replace it. The spreadsheet is usually built once, by one person, at a whole-club level. This is meant for the meeting itself: testing a different rise on one section in front of the room, in minutes, rather than asking finance to rerun their model and come back next week. Whether that is worth having depends on how often the pricing conversation actually needs that speed.

Does this actually predict how our members will respond to a price change?

No, and it should not be treated as though it does. It shows the arithmetic consequence of an assumption someone enters, not a forecast of real behaviour. The renewal sensitivity figure is a judgement call by the person running the scenario. Where a club has enough renewal history to estimate that sensitivity properly, that work happens outside this tool and feeds into it as an input.

Once this exists, who is responsible for keeping it current?

Whoever owns the pricing decision, usually the head of ticketing, needs to refresh the account export each renewal cycle and revisit the sensitivity assumptions rather than reusing last year's guess. The tool does not maintain itself, and a scenario run on a stale export is worse than no scenario at all, because it looks more authoritative than it is.

Is this your workflow?

Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.

Tell us about it

More in Ticketing, memberships & season passes