How do ticketing platforms manage capacity across related events?
Related events can share capacity, sell independently or depend on one another. A ticketing platform must explicitly model that relationship; giving several events the same venue does not automatically prevent them from overselling a shared limit.
When is capacity genuinely shared?
Consider a museum with a building-wide maximum occupancy and separate bookable exhibitions. A customer may buy exhibition entry without needing another full-building place if the same admission already includes it. Similarly, a conference pass may cover sessions with their own room limits. The relevant constraints could be building admission, session seat count or both.
Which capacity models are common?
Two products that reference the same space are not necessarily backed by a shared capacity pool. The implementation must make that relationship explicit and testable.
What needs to happen during purchase?
When a basket combines a parent event and a session, reservation operations must account for both constraints. If the workshop has room but building entry does not, the purchase may still be impossible. If one part fails, the customer should see a clear alternative and should not end up with a misleading partial entitlement.
What about admissions reporting?
A report of ‘tickets sold’ across related events can overstate unique attendees because one person may hold several related entitlements. Operators should distinguish orders, tickets, unique people where known, expected admissions and real-time scanned occupancy. These are different measures.
What should a platform buyer test?
Book a bundle at the last available place, cancel one component and attempt to add a workshop after the fact. Verify the system’s capacity logic, customer communications and staff override permissions. Treat shared capacity as a specific feature requiring evidence, not an assumption from the event hierarchy.