# Multi-event season pass — inclusion, capacity and admission-test matrix

Use one copy per proposed pass product. This sheet stores event references and test results, not attendee names, live ticket codes, account credentials or payment details. A pass for several separate events differs from a multi-day pass within one event. Renewal is a separate decision.

## 1. Product and delivery model

| Pass reference | Season start/end | Product owner | Provider model observed: one pass scan / issued event tickets / other | What the buyer receives | Gate record to inspect | Change owner |
| --- | --- | --- | --- | --- | --- | --- |
| __________ | __________ | __________ | __________ | __________ | __________ | __________ |

- [ ] Confirm that the platform can represent the exact event set and any event-specific ticket types or areas.
- [ ] Confirm whether a separate reservation, seat assignment or eligibility check is still required at any event.
- [ ] Write the buyer-facing inclusion rule from the verified event list, not from an assumed platform feature.

## 2. Event-by-event inclusion and capacity

Add a row for every included, excluded or not-yet-decided event. Do not silently treat a later event as included.

| Event reference, date and venue | Included / excluded / undecided | Ticket type or area covered | Event admission source | Event inventory owner |
| --- | --- | --- | --- | --- |
| __________ | __________ | __________ | __________ | __________ |
| __________ | __________ | __________ | __________ | __________ |
| __________ | __________ | __________ | __________ | __________ |

For each **included** row, inspect the actual provider record before and after a safe sample purchase. Different systems may count passes, issued event tickets, holds or seats differently.

| Event reference | Approved capacity | Existing single-event commitments | Planned pass allocation | Provider count before | Provider count after | Reconciled? / owner |
| --- | --- | --- | --- | --- | --- | --- |
| __________ | __________ | __________ | __________ | __________ | __________ | __________ |
| __________ | __________ | __________ | __________ | __________ | __________ | __________ |

- [ ] Check the stock or seat record of **each** included event; do not use only the series-product total.
- [ ] Confirm that a pass purchase does not double-count or omit an entitlement in any event.
- [ ] Hold publication for a negative, unexplained or conflicting available count.

## 3. Buyer and admission rehearsal

Use an authorized test environment or reversible samples. Record the observed scanner response **and** the authoritative event-level attendance/access record. Do not infer admission solely from a confirmation email or pass image.

| Scenario | Expected event entitlement | Scanner observed | Event-level record observed | Capacity/entitlement count observed | Pass / hold / owner |
| --- | --- | --- | --- | --- | --- |
| First included event | __________ | __________ | __________ | __________ | __________ |
| Second included event | __________ | __________ | __________ | __________ | __________ |
| Excluded event | __________ | __________ | __________ | __________ | __________ |
| Wrong date, area or ticket type | __________ | __________ | __________ | __________ | __________ |
| Repeat scan at the same event | __________ | __________ | __________ | __________ | __________ |
| Legitimate scan at another included event after the first | __________ | __________ | __________ | __________ | __________ |

- [ ] Compare pass page, confirmation and delivered credential with the inclusion table.
- [ ] Verify that staff can resolve an unexpected result from the authoritative ticket or membership record.
- [ ] Pause the sale if an excluded event is admitted, a valid included event is rejected or any event count cannot be explained.

## 4. Change and renewal handoff

| Change or next season | Inclusion decision owner | Inventory review owner | Buyer update owner | Gate retest owner | Completion evidence |
| --- | --- | --- | --- | --- | --- |
| __________ | __________ | __________ | __________ | __________ | __________ |

- [ ] Update the product description, event associations, issued credentials and per-event ledger in an agreed order when a date changes.
- [ ] Retest the buyer view and admission path after each affected event is added, removed or moved.
- [ ] Treat renewal as a new entitlement check; do not assume the old pass continues to admit.

Provider examples only: [TicketCo](https://ticketco.io/en/support/setting-up-season-tickets) documents one season-pass code scannable once at each associated event and a capacity reduction in every associated event on purchase. [Showpass](https://help.showpass.com/hc/en-us/articles/39131538553111-Organizer-guide-Overview-of-memberships-and-season-passes) describes a membership model with scan access or issued ticket batches and optional season renewal. Verify the model and record in your own provider before selling.