# Event ticket discount code: setup and checkout-test matrix

Copy this English worksheet for each offer. Keep customer details in your ticketing system, not here. Confirm what your provider actually supports; a similarly named limit may count orders, tickets or something else.

## 1. Define the offer before creating the code

| Decision | Record the approved setting |
|---|---|
| Event and ticket sale | [ ] |
| Offer purpose and intended audience | [ ] |
| Buyer-facing code (or internal reference) | [ ] |
| Included ticket types | [ ] |
| Excluded ticket types and products | [ ] |
| Discount: fixed amount or percentage | [ ] |
| Price component affected; fee and tax display checked | [ ] |
| Starts / ends: date, time and time zone | [ ] |
| Use limit: value **and provider-defined unit** | [ ] |
| Is applying a test code counted against that limit? | [ ] |
| Is this a price reduction, hidden-ticket access, or both? | [ ] |
| Owner role, approver role and approval date | [ ] |

Write the exact public promise in one sentence: “Enter [code] for [discount] on [ticket types] until [end condition].” Remove any part that the checkout test cannot confirm.

## 2. Test as a buyer

Test in a controlled environment or with an approved disposable code where possible. Stop before a real payment unless the test transaction is authorized. Record the displayed item prices, total and any message. A setting visible to an organizer is not a buyer result.

| Case | Expected result | Observed item price / total / message | Pass, fix or not safe to test |
|---|---|---|---|
| One included ticket + code | Intended reduction only | [ ] | [ ] |
| Two included tickets + code | Verify whether both change | [ ] | [ ] |
| Excluded ticket + code | No unintended reduction or access | [ ] | [ ] |
| Mixed basket + code | Only intended items change; total agrees | [ ] | [ ] |
| Valid ticket without code | Ordinary price and access | [ ] | [ ] |
| Mistyped code | Clear rejection; no unintended reduction | [ ] | [ ] |
| Before start / after end | Code unavailable at intended boundary | [ ] | [ ] |
| At use limit | Provider-defined limit respected | [ ] | [ ] |
| Hidden ticket, if relevant | Visibility matches the published offer | [ ] | [ ] |

If a boundary or limit case cannot be tested safely, mark it **not safe to test** and record the provider setting or support confirmation that will be checked at launch. Do not consume a scarce public code merely to complete the table.

## 3. Release and follow-up

- [ ] Compare the public wording, ticket types, end condition and code-entry instruction with the observed checkout.
- [ ] Verify any share link opens the intended event and applies the intended code.
- [ ] Record the test date, platform, sale state, test owner and approval reference: [ ].
- [ ] Assign support ownership for a code that fails or changes the wrong item: [ ].
- [ ] After launch, review remaining uses in the **provider's actual unit**, and reconcile customer reports with current settings.
- [ ] At offer end, confirm the code no longer applies; retain final settings and closure owner: [ ].

Provider examples, not universal rules: [Ticket Tailor](https://help.tickettailor.com/en/articles/950985-how-to-create-discount-codes) documents an order-redemption limit and says applying a code to a basket counts a redemption. [Eventbrite](https://www.eventbrite.com/help/en-us/articles/362532/how-to-set-up-discount-codes-for-one-or-multiple-events/) documents a ticket limit and a buyer-side code test.