Chapter 11 — Suites: Real Seats Sold as One Block
Attend onboarding guide · ~7 min read · ↑ Back to contents
Welcome to Part 3. Parts 1 and 2 gave you the business and the raw machinery — what Attend sells, and how a single seat gets described, priced, and sold. Part 3 is the layer in between: how a team configures an actual Flex or Premium program on top of those primitives, all from Cortex.
We start with the trickiest piece to wrap your head around — the suite — because it reuses a trick you already met in Chapter 6.
A suite isn't a thing the ticketing system knows about
Recall the first surprise from Chapter 6: the ticketing system only understands section / row / seat. There is no "suite" object in the manifest. A suite is a front-end concept only — it lives in Attend (and in the fan's head), never in the vendor's inventory.
So how do you sell a private box that holds 40 people if the system can't represent one?
A suite is real seats sold as one block
The seats in a suite are real seats — the same section/row/seat from Chapter 6. What the team invents is the suite itself: a grouping of those seats plus a rule that they're bought all together. (Sometimes they sit in a section created just for this; sometimes an ordinary section is simply sold as a block.)
- The capacity of the suite is just how many seats are in the group.
- Attend stores the mapping: "Suite 1 = these 40 seats."
💡 Most suites sell whole, but partial sale exists. A suite can set
allowPartialSalewithpartialSaleMode = 'count_based'— the fan buys N seats and the app/vendor decides which ones; leftover seats can spill via overflow mapping. (The admin API accepts onlycount_basedtoday.) Full detail and thetbl_suite_partial_*/tbl_suite_overflow_seat_mappingtables live in Suite & Section Mapping.
💡 "Dummy seats" — the team's term, and what it actually means. You'll hear these called dummy seats (often in dummy sections), and that's fair shorthand: the seat records are real and sellable in the ticketing system, but they're placeholders — they don't have to map to a physical stadium seat. What's not true is that they're fake or nonexistent: the cart holds a real, sellable record. For a normal section you can buy any 2 of 20 seats; for a suite the team adds the rule that you take all of them. Only the suite grouping is constructed.
A team can also map several sections to one suite (st1a + st1b = Suite 1) — their choice. Either
way, Attend just remembers which seats add up to which suite.
Example: the Warriors want a courtside suite that seats 40. Their ops team groups 2 rows × 20 real seats (section
st1) and Attend records "Warriors Courtside Suite = those 40 seats." To the ticketing system they're 40 ordinary seats; the only difference is that Attend sells them as one block.
Pricing a suite
Each seat carries exactly one price code and one ticket type code (the access/price tags from Chapter 7). Inside a suite, every seat usually shares the same price code and ticket type code, and suites have no discounts — no adult/child split, no packs — so one ticket type code is enough.
The price the fan sees is just the math:
seat price × seat count. A 40-seat suite at $100/seat shows as a $4,000 suite.
One subtle difference: Flex vs Premium pricing
This is where the two products diverge. Both sell suites, but they set prices at different levels of detail:
| Product | Pricing level | What the team configures |
|---|---|---|
| Flex | Per event | For each event, one price code + ticket type code — applied to all seats in that event |
| Premium | Per event, per suite | For each event-and-suite pair, its own price code + ticket type code |
Premium's extra level of detail is exactly why its admin needs a bulk-edit grid: picture 80 events down one side and 50 suites across the top — 4,000 boxes a team might want to price one by one.
Suites aren't tied to events — on purpose
You might expect a team to link each suite to each event. They don't. A suite is defined once and then assumed available for every event.
- When Attend builds inventory for an event, if a suite's seats show up in the vendor data → the suite appears; if they don't → it doesn't.
- This avoids forcing teams to wire up 50 suites × 80 events = 4,000 links by hand.
- It's also dynamic: a team can add seats to a suite's inventory in the ticketing system, and they auto-appear on Attend's next build.
How a suite gets built in Cortex
The flow a team follows is short:
- Create the suite — give it a name and a seat count.
- Map its inventory — point it at the section/row/seat (the real seats) it represents.
- Done. Attend pulls those seats from the ticketing system using the suite's class name (e.g.
season-shareorsuites) and builds the suite's inventory automatically.
Suite Types (Premium — in progress)
Premium is gaining one more layer above suites: a Suite Type — a category like "Mezzanine Level Suites," "Club Level Suites," or "Away Suites." Each suite is assigned to a type, and images cascade down: the type's images copy onto its suites on assignment (still editable afterward), so a team launching dozens of suites doesn't re-upload art for each one.
Example: the Warriors define three suite types — Courtside, Club Level, and Mezzanine — set the hero image once per type, and every suite underneath inherits it.
Recap
- A suite is a front-end concept — the ticketing system only knows section/row/seat.
- A suite is real seats sold as one block; capacity = the seats in the group, and Attend stores the suite→seats mapping.
- Suites have no discounts → one price code + ticket type code per seat; price = seat price × count.
- Flex prices per event; Premium prices per event × suite (hence the bulk-edit grid).
- Suites are global (not linked to events) and inventory is dynamic.
- Suite Types (Premium) group suites and cascade images.
Next → Chapter 12 — The Flex Program: BYO, Game Packs & Tiers