Site plans have a checklist. Supplier contracts have a checklist. Insurance, licensing, accreditation and stage schedules all have one. The audience data usually does not, and it is the only part of a festival that genuinely cannot be fixed in the week before the gates open.
Key takeaways
- Consent, source and attendance are written at a moment or not at all.
- Run this before the announcement. After the on-sale, half of it is already impossible.
- If you do one item, do the consent wording, stored with a timestamp per person.
What this list is not
It is not the operations checklist. Nothing here concerns fencing, water, medical cover or noise limits, and those matter more than any of this on the day.
It is the list of things that can only be captured while they are happening. A supplier contract can be renegotiated. A consent record cannot be created in March for a person who signed up in June without it.
Before the announcement
This is the part that is genuinely urgent, because it has to exist before the first person arrives.
| # | Item | Why it expires |
|---|---|---|
| 1 | Agree the consent wording, in each language you sell in | It must be the wording shown at the moment, and stored |
| 2 | Decide the source tags, one per surface | A tag added later is a guess, not a source |
| 3 | Set up the pre-announcement list | It only works before the line-up is known |
| 4 | Export last edition's audience, with source and consent | Before anyone cancels a subscription |
| 5 | Write down who the controller is, and who the processors are | Article 30 of the GDPR asks for this anyway |
Item three is the one with the highest return and the shortest window. A list of people who asked to be told when the line-up lands is the single best predictor of launch week, and it can only be built while the line-up is still unknown.
During the on-sale
| # | Item | Note |
|---|---|---|
| 6 | Every purchase path leaves a contact with a source | Including the ones your partners run |
| 7 | The sold-out page has a waiting list | Not a dead end with a word on it |
| 8 | Partner and sponsor capture is agreed in writing | Who holds it, who can message, for how long |
| 9 | One reminder to the pre-announcement list, on the day | The whole point of building it |
Item eight is the one that causes arguments in February. Agree it while everyone is friendly, in a paragraph, and store the wording shown to the person on both sides.
On site
| # | Item | Note |
|---|---|---|
| 10 | Attendance is recorded per person, not as a headcount | This is the field that makes next year's best segment |
| 11 | Any on-site capture writes its own source tag | The bar, the merch stand, the workshop tent |
| 12 | Staff know the one sentence to say when asking | Consent collected badly is worse than none |
Item ten is worth arguing for internally. A number in a report tells you the edition worked. A record per person tells you who to invite next time, and the gap between those two is a year of marketing budget.
After the gates close
| # | Item | Timing |
|---|---|---|
| 13 | The recap send, within a week | Highest open rate you will get all year |
| 14 | Quarterly export, held outside every vendor account | Twenty minutes, and it survives anything |
| 15 | Two segments built and saved | Attended and did not return; attended two or more editions |
The reason to build the segments in the quiet week rather than next spring is that you will remember what the data means now, and you will not in eight months.
Where the mechanism helps
Most of this is discipline rather than software. The part software should do is enrichment: every action landing on the profile at the moment it happens, so that attendance, opens and purchases accumulate without anyone updating anything. That is what HIIPE does with the fanbase, and it is why items ten and fifteen stop being projects. How it fits together covers the rest.
Who owns each part, and why the list stalls without that
Most of these checklists die because they are written by marketing and depend on production, ticketing and the people on the gate. Naming the owner in advance is the difference between a list and a document.
| The part | Who has to do it | Why it stalls |
|---|---|---|
| Consent wording, in every language sold | Marketing, with a legal read | Waiting for perfect wording instead of shipping a clear one |
| Source tags per surface | Whoever configures the surfaces | Nobody feels ownership of a naming convention |
| Pre-announcement list | Marketing | Competes with the announcement itself for attention |
| Attendance recorded per person | Ticketing and the gate | Reads as an operations burden with no visible payoff |
| The quarterly export | One named person, calendared | Everyone assumes someone else has a copy |
The fourth row is the one that needs a sponsor rather than a request. Recording attendance per person costs the gate team a small amount of friction on the busiest night of the year, and the benefit lands eleven months later in a different department. That trade has to be made by someone senior enough to make it, or it does not get made.
If you are already mid-cycle
The whole list assumes autumn. Most people read something like this in April, with tickets already on sale, and conclude they have missed the window. Two thirds of it is still available.
- Do the consent wording this week. It applies from the next signup onward, and the next signup is today. Nothing here is retroactive, which is exactly why starting late costs you nothing forward.
- Add source tags to the surfaces still to come. The ones already live keep their gap. Partial data is not a reason to skip the rest of the season.
- Do the export now, not in October. The single highest-value item on the list, and it takes twenty minutes at any point in the cycle.
- Skip the pre-announcement list this year. It only works before the line-up is known. Put it in the calendar for the autumn instead of doing a bad version now.
- Record attendance per person at the next event, even if you cannot for the ones already gone. One clean edition is enough to build next year's best segment.
When to review this page
Once a year, in the autumn before the season it applies to. The version you are reading is dated 29 October 2026 and is written for the 2027 season. If you are reading it later than that, the items have not changed but the dates have, and the argument for doing it early is in festival marketing happens in the eleven months without a festival.
Read next : When a festival is cancelled, where does the attendee list go? · A guest list app fills the room. It does not build a contact list