Allocate comps to a promoter
Create buckets with hard caps, hand one to a promoter, and watch the utilisation.
Owned by Venue Manager · 10 steps · about 16 minutes
Why this exists
Comps are allocated in buckets, and the bucket is the unit of trust. Rather than granting a promoter the abstract right to add names, you give them a named allotment with a hard total, a tier, and a default plus-one allowance, and then let them fill it themselves. The venue keeps the ceiling; the promoter keeps the list.
The counting rule is the thing people get wrong, so learn it first: allocation counts plus-one ALLOWANCES at the moment the entry is created, not the plus-ones that actually get named. An entry with a two-plus-one allowance consumes three from the bucket immediately, whether or not anyone is ever named. That is what makes the ceiling real — a bucket of ten cannot turn into thirty on the night — and it is why a promoter who hands out generous allowances runs out of names faster than they expect.
The tier on the bucket is not just a price label; it determines the zones the resulting pass opens. A comp issued against the VIP tier gets VIP zones at the door. Putting a promoter's bucket on the VIP tier because it was the first one in the dropdown is how you end up with fifty people in a room built for twenty.
Everything a bucket produces is real: a zero-value ticket on a zero-value paid order, drawing on the same inventory a paying customer draws on, with a genuine door pass. No money moves and no ledger entry is written, but capacity absolutely does — a sold-out tier will refuse a comp with insufficient inventory.
Before you start
- A venue manager or admin session.
- An event with at least one tier — the bucket must point at a tier of that event.
- For the promoter half: a scoped host user on the event. The seed ships promoter@demo.club on demo-event-0001.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| venue_manager | manager@club.test | manager123 | shift lead: implies door_staff, plus intake, sales, guest list, marketing |
| host_promoter | promoter@demo.club | promoter123 | scoped host on demo-event-0001; owns the seeded Promoter X comp bucket |
| admin | admin@club.test | admin123 | the only account that can touch money, identity and contracts |
| door_staff | door@club.test | door123 | door shift account: scanner + guest list, nothing else |
Steps 1–6 — Venue Manager
their manual →-
1Open the guest-list index and pick the event you are allocating for.Expected result Events with their guest-list activity.Watch out for Door staff get a 403 on this index. It is a planning surface, not a door surface.
-
2On the event dashboard, read the existing buckets first: each shows its allocation total, consumed and remaining, and its status.Expected result The seeded Promoter X bucket (10 allocated, one plus-one by default) and Artist Guest List (15, manual issue policy).Watch out for Consumed is recomputed live from the entries, not stored as a counter. If it disagrees with your head, the entries are right.
-
3Use the Create bucket form: give it a name, an owner type (promoter, artist, house, staff or other), the owning host user if it belongs to one, the tier, the allocation total, the default plus-ones and the issue policy.Expected result A new bucket at zero consumed.Watch out for Choose the tier deliberately — it decides the door zones on every pass this bucket ever produces. A tier belonging to a different event is refused with 422 tier_not_of_event.
-
4Choose the issue policy on purpose. On_claim means the guest's ticket is minted when they claim their invite link. Manual means somebody has to press Issue for each one — slower, but nothing is minted until a human has looked at it.Expected result A policy that matches how much you trust the list.Watch out for Manual policy plus a busy promoter equals a queue of unticketed names at the door. That is survivable — the door can Issue and Check In — but only if you told the door that is what is coming.
-
5Adjust an allocation when a promoter asks for more, or freeze a bucket to stop further names without touching what is already issued.Expected result The bucket updates, or freezes.Watch out for Lowering an allocation below what is already consumed is refused with 409 allocation_below_consumed. And freezing is not retroactive — already-issued tickets keep scanning green, because tickets are independent once minted.
-
6Watch utilisation through the event build-up: consumed against remaining per bucket, with the per-status counts.Expected result Live numbers, with expiry and check-in sync swept before the read.Watch out for Remaining is null for the door-override house bucket. That bucket is allocation-exempt on purpose — walk-ins are governed by the override cap instead.
Steps 7–8 — Host / Promoter
their manual →Fills the bucket you allocated, and can only ever see and spend their own.
-
7As the promoter, open the same dashboard. You see only the buckets you own.Expected result Your bucket, your entries, and nothing belonging to another promoter.Watch out for Scoping is on the bucket owner, not on the event. Being a host on the event does not show you the house or artist lists.
-
8Add a guest — invite mode sends them a claim link, direct mode issues to a known member straight away.Expected result An entry, and the bucket's consumed figure rising by one plus the plus-one allowance.Watch out for 409 allocation_exceeded means the allowance arithmetic caught up with you, not that the system miscounted. 409 duplicate_guest means that email or member is already on some bucket for this event — one live entry per guest per event, across all buckets.
Steps 9 — Door Staff
their manual →Turns the names in the bucket into people in the room, and lives with your plus-one decisions.
-
9On the night, search the names the promoter added and check them in.Expected result Entries with their bucket shown, so you know whose list a guest is on.Watch out for The bucket name is worth reading aloud when there is a dispute. 'You are on Artist Guest List with one plus-one' ends most of them.
Steps 10 — Admin
their manual →Is the only role that can delete a bucket outright.
-
10Delete a bucket created in error. Only an admin can, and only when it is empty.Expected result The bucket goes.Watch out for 409 bucket_not_empty is the normal answer. The right move for a bucket with history is to close it, not to try to erase it.