Two different permissions get confused every night in every venue. One is permission to come in. The other is permission to be contacted afterwards. A guest list carries the first and almost never the second, and the distance between them is exactly one field wide.
Key takeaways
- Adding your name to get in is not an affirmative act of consent to marketing.
- The field that separates the two is a stored choice, with a timestamp and the wording shown.
- Plus-ones and names added by a third party never consented to anything at all.
The moment where the two get merged
The door list closes at midnight. Four hundred and twelve names, most with an email address because that is how the invite worked. The next morning someone exports it, pastes it into the mailing tool, and the venue has a bigger audience.
Nothing in that sequence feels wrong, which is why it happens. But go back to what each of those four hundred and twelve people actually did. They typed their name to get through a door on a specific night. The act had a purpose and the purpose was completed when they walked in.
Recital 32 of the GDPR puts it in plain terms: consent has to be a clear affirmative act, freely given, for a specified purpose. Getting on a list is an affirmative act. It is just an affirmative act about something else.
What each list actually is
| Guest list | Contact list | |
|---|---|---|
| What the person did | Asked to come in, once | Agreed to hear from you, ongoing |
| What it is valid for | One night, one door | Until they say otherwise |
| What proves it | The door log | A stored choice, with time and wording |
| Who else can be on it | Plus-ones, names added by a promoter | Only people who acted themselves |
| What it is worth in March | Nothing you can send to | Everything |
| What it costs to get wrong | Complaints, spam reports, a poisoned domain | Nothing, if the record exists |
Read the fourth row twice. The guest list is the one document in your business that is routinely populated by people who are not the person. A promoter adds twelve names. Someone brings two friends. None of those fourteen ever saw a form, let alone a consent line.
The one field, and what it must contain
Not a checkbox. A record.
Three things have to sit on the person: the choice they made, the moment they made it, and the exact wording they were shown when they made it. The last one is the part everyone skips and the only one that helps you two years later, when somebody asks why they are receiving this. "They ticked a box" is an assertion. "On 17 September at 21:14 they ticked a box that said this sentence" is a record.
It also has to be separable. Consent to hear about future nights at this venue is not consent to hear from the three other promoters who used the same door tool. If those cannot be told apart in the data, they are the same thing legally and the weakest one governs.
The good news, which is that the door is a great place to ask
Everything above sounds like a restriction. In practice it is the opposite, because the door is the single highest intent moment you will ever have with these people. They are standing in your venue, on a night they chose, having already said yes to being there.
Asking one question at that moment converts far better than asking the same question in a feed three weeks later. It only needs to be one question, it needs to be optional, and it needs to say what will actually happen: we run about one night a month, we will tell you about them, that is all.
Do that and the four hundred and twelve names become a smaller number, maybe two hundred and forty, which is worth far more than four hundred and twelve because every one of them can be reached in March without a complaint.
Where the mechanism lives
This is why the RSVP surface and the fanbase have to be the same system rather than two exports that meet in a spreadsheet. In HIIPE the RSVP page collects the entry, the consent and the source in one action, and the person lands in the fanbase already carrying all three, so the segment "said yes to hearing from us, at this event" exists without anyone building it.
The door is now part of the same object rather than the place where the record stops. The RSVP issues a personal QR pass, and the entrance scans it from a web reader opened with a per-event PIN: nothing for the guest to install, no account for the person working the door. That detail is not a convenience, it is what keeps the record whole. A scanner that lives outside the system produces a second file, and a second file is exactly how entry and contact end up merged by hand a month later. Here the scan writes back to the same profile, so attendance and permission stay two separate fields on one person instead of two lists somebody has to reconcile. How the pieces connect is the part that matters.
The rule, in one line
Entry is one permission. Contact is another. Never let an export merge them.
If you already have a pile of old guest lists, do not delete them and do not mail them. Treat them as attendance history, which is genuinely useful for understanding who comes to what, and start the consent record from the next event forward. The full argument for why the last event should be feeding the next one is in filling your next event from the last one, and what that record needs to look like is in what a fan CRM is.
Read next : Fill your next event from the last one · What an event CRM should do between two events