Understand your event's tiers, prices and releases
Read the tier ladder on your own event, and learn who can change what — and why it is not you.
Owned by Host / Promoter · 12 steps · about 20 minutes
Why this exists
Your application's tier estimates became real tiers when the event was converted, and from that point the ladder belongs to the venue. This workflow teaches you to read it fluently, because you will be asked about it all night, and it teaches you who to ask when it needs to change.
Why a host cannot price their own event. Tiers are inventory, and inventory is money: a price change moves revenue, a cap change can oversell the room, and a status change can put unsold stock on the market. Those are venue decisions, so every write here is admin-only and the whole dashboard is read-only for you. What was agreed is written down in the contract; if the ladder needs to change, that conversation goes through the venue, not through the UI.
How a tier ladder actually works. Each tier has a cap, a sold count and a reserved count; available is never stored, it is cap minus sold minus reserved, computed every time. A tier unlocks in one of three ways: on a schedule (it opens at its sale start time), by cascade (it sits locked until the tier before it has sold a set percentage, or is closed, or passes its sale end), or manually. Cascade thresholds count tickets actually sold — holds do not count toward a cascade. The first tier in the ladder can never be a cascade tier, because there is nothing for it to cascade from.
Sold out is automatic and two-sided: the moment sold plus reserved equals the cap the tier flips to sold_out — holds do count here — and it flips back automatically when those holds expire or inventory is returned, unless the sale window has closed. So "sold out" on this platform can un-sell-out, and that is correct behaviour, not a glitch.
Before you start
- A host grant on the event whose dashboard you are reading.
- An admin session for any of the configuration steps.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| host_promoter | host@club.test | host123 | scoped host on demo-event-0001, which ships a fired cascade to look at |
| admin | admin@club.test | admin123 | the only persona that can create, price or open a tier |
| venue_manager | manager@club.test | manager123 | can see every event including drafts, but cannot price or transition them |
| member | member@club.test | member123 | experiences the release schedule from the buyer's side |
Steps 1–3 — Host / Promoter
their manual →-
1Open your event and read the Tiers table properly: number, name, price, status, Sold / Rsv / Cap, the sale window, and the zones each tier opens.Expected result One row per tier in cascade order, with your application's tier names on it.Watch out for There are no action buttons on those rows for you. That is the read-only view, not a rendering bug.
-
2Pull the same picture as the buyer's page computes it, so you can see the fields underneath the table.Expected result Per-tier availability and the server time, with the scheduler run lazily first so the numbers are fresh without a cron job.Watch out for A locked tier reports its availability as null rather than a number — the platform will not leak how much of an unreleased tier exists.
-
3Learn the six tier statuses so you can answer questions on the night: locked (not released yet), scheduled (opens at a set time), on_sale, paused (deliberately stopped by staff), sold_out, closed (the window has ended).Expected result Every tier is in exactly one of those states, and the dashboard shows it.Watch out for Sold out and closed are not the same thing, and the difference matters to a customer: sold out can reopen when holds expire, closed cannot.
Steps 4–8 — Admin
their manual →Owns every write here: creates tiers, sets prices and caps, maps zones and puts the event on sale.
-
4Add a tier: name, price, cap, sort order, unlock mode, and either a sale start (scheduled) or a cascade threshold percentage.Expected result 201 with the new tier, slotted into the ladder at its sort order.Watch out for 422 cascade_needs_predecessor if you try to make the first tier a cascade tier, 422 sale_start_required for a scheduled tier without a start, and 409 sort_order_taken because sort order is unique per event and it is the cascade order.
-
5Adjust a tier: price, cap, max per order, window, or status (open now, pause, resume, close).Expected result The updated tier, with the change reflected immediately in availability.Watch out for 422 cap_below_committed — you can never shrink a cap below what is already sold. 409 invalid_tier_transition for an illegal status move. Deleting a tier that has sales is refused outright with 409 tier_has_sales.
-
6Map the tier to the door zones its ticket should open. This is a full replace, not an add.Expected result The tier's zone set, by code or by id.Watch out for This is what a scanner reads at the door: the zone codes are embedded in the pass when the ticket is issued. Change zones after tickets are issued and the already-issued passes keep the zones they were minted with.
-
7Put the event on sale once the ladder is right.Expected result The event moves to on_sale, the storefront shows it as buyable, and the outbox emits the event so marketing rules can fire.Watch out for Venue manager and admin (capability events.publish). CANCELLING is the exception and still needs admin: it releases every live hold and fans out to refunds, so the route asks for events.cancel separately and answers 403 to a venue manager. Cancelling also needs a reason (422 reason_required).
-
8In a training or demo environment, force the next locked tier open so a room can watch a cascade happen without selling out a real tier.Expected result The next locked tier unlocks and an outbox row is emitted flagged as forced.Watch out for Admin-only debug, and the whole /debug tree 404s when debug endpoints are disabled. In production the scheduler tick and the lazy evaluation on reads do this by themselves.
Steps 9–10 — Venue Manager
their manual →Sees the same dashboard including drafts, but cannot price or transition anything.
-
9For an event the club already voted in, skip the host application entirely: fill the backload form once — name, room, times, tiers — pick the status to land at, and submit. Paste a whole season into the box below it if you have one.Expected result A real event at the status you asked for. Pick on_sale and it is selling when the page reloads; pick completed for a night that already happened.Watch out for It skips the intake workflow, not the rules: an event with no tier cannot go on sale, and a tier ladder over the room's capacity is refused the same way it would be from the manual path. The paste box reports bad lines one by one instead of dropping the batch — preview first. Every backloaded event carries 'backload' as the reason on its status log, which is how you find them later.
-
10As the venue manager, use the events list to see every event including drafts and their sold-versus-cap totals.Expected result All events, with tier counts and totals.Watch out for Since plan 41 this is a working surface for a venue manager, not a window: create, price, zone and publish are all yours (capabilities events.create / update / publish / tiers.manage). Deleting an event and cancelling one are not — those two are admin, because they destroy a record and trigger mass refunds respectively.
Steps 11 — Member
their manual →The buyer the whole release schedule is designed for.
-
11As a buyer, open the public event page and watch the ladder from the outside.Expected result Live availability per tier, countdowns on scheduled tiers, and a headline when a cascade fires along the lines of 'Early Bird Sold Out — General Admission Now Live!'.Watch out for A visible tier can still be locked. Locked, sold out and closed all look like 'you cannot buy this' to a customer and mean three different things to you.
Steps 12 — Host / Promoter
their manual →-
12Come back to your dashboard and read the status log and recent outbox rows to see the release history of your own event.Expected result An append-per-transition log, plus the tier unlock, milestone and sold-out events the platform emitted.Watch out for Those outbox rows are what the marketing automation consumes. If a post went out about your event, this is where the trigger came from.