Ticket modes
Named or transferable - the choice that decides which machinery your event runs, how it's pre-selected, and when it locks.
Before you plan anything, one question matters: whose name is on the ticket?
- Named tickets - the seller checks the attendee against details captured when the ticket was bought, so a spare can't simply be handed to a mate (where re-homing exists at all, it tends to cost). The plan has to be right before the sale: small groups, each buyer purchasing for specific people. Glastonbury is the classic case.
- Transferable tickets - the ticket itself is the entry pass, whoever holds it. Over-buying is recoverable and helping is easy, so the coordination problem is afterwards: matching spares to people still short. Most gig and club tickets work this way.
(The app states its own one-line definitions when you pick - this page is the longer story.) The mode decides which machinery your event runs - the walkthroughs live at named events and transferable events.
What changes in the app
| Named | Transferable | |
|---|---|---|
| Workspace tabs | Brief · My data · Groups · Sale day | Brief · My data · Tickets |
| The core surface | Buying groups + static sale-day boards | The held/spare/needed board |
| Data collection | Full - details buyers need at checkout | Reduced by default - a field review hides what's not needed, and the coordinator keeps or adds whatever the event really requires |
| Group size setting | Yes - drives buying-group shape | Hidden - the board replaces groups |
| Multiple-group fallback | Can arm (Closed events) | Never |
(Known events add Guide and Reviews tabs in either mode.)
Pre-selected from checked ticket rules
When you create an event from a known event whose ticket rules we've checked, the form starts on the matching mode with the reason shown - a per-ticket name-change fee, say. You can always override, but expect pushback when you contradict the data: picking Transferable for an event that sells named tickets gets a blocking "are you sure?", because tickets bought on spec at a named sale may not be usable by anyone else. (Without checked rules the form simply starts on Named; linking a known event to an existing squad later doesn't touch the mode at all.)
Changing your mind - and when it locks
You can switch modes in event settings until someone records a ticket - a confirmed purchase, a held ticket on the board, or a group outcome locks it. Remove those records and it unlocks again.
Switching is designed to be non-destructive: going to transferable hides the buying groups and sale-day board (nothing is deleted; switching back restores them) and runs a quick review of which data fields still matter - unticked fields are hidden, not deleted. One special case: if the only ticket evidence is members saying "I have my ticket", you can switch a locked named event to transferable and carry those records onto the board as one held ticket each - provided everyone who confirmed is still an active member who'd appear on the board (no one opted out or deleted their account), because a held ticket nobody can see is a held ticket nobody can clear. That specific conversion can't be undone.
Required means something different per mode
On a named event, required fields are what a buyer needs at checkout - registration number, postcode. On a transferable event, required means what a buyer needs to buy for you - seated or standing, which night - not ID details. The field editor says exactly this when you're setting questions up.