# One-ticket change in a multi-ticket order: before/after card

This worksheet is in English. Copy it for **one approved ticket change**. Keep names, contact details, payment credentials and private notes in the authorized ticketing system, not on this card. A decision about the event's policy and payment outcome must already be approved before anyone changes a ticket.

## 1. Identify the exact scope

| Event / occurrence | Order reference | Provider | Decision owner | Operator / time zone |
|---|---|---|---|---|
| [ ] | [ ] | [ ] | [ ] | [ ] |

| Ticket reference (use placeholders in training) | Type / seat or slot, if relevant | Before: admission status | Approved after-state | Actual after-state |
|---|---|---|---|---|
| T-001 | [ ] | [ ] | **Keep** / [ ] | [ ] |
| T-002 | [ ] | [ ] | **Change** / [ ] | [ ] |
| T-003 | [ ] | [ ] | **Keep** / [ ] | [ ] |

Add or remove rows to match the real order. Confirm the target **ticket reference**, not only the buyer's order reference. If the platform offers only a whole-order action, stop and use an approved, documented alternative.

## 2. Separate the decisions

| Check | Approved or expected | Actual result / owner |
|---|---|---|
| Ticket-level control selected; whole-order control avoided | [ ] | [ ] |
| Target ticket admission validity after action | [ ] | [ ] |
| Remaining ticket validity and count | [ ] | [ ] |
| Payment or credit outcome decided by policy owner | [ ] | [ ] |
| Payment system reflects that outcome | [ ] | [ ] |
| Buyer notice required; channel and wording approved | [ ] | [ ] |
| Notice sent or queued; evidence checked | [ ] | [ ] |
| Saleable stock / seat / waitlist effect checked | [ ] | [ ] |
| Check-in team received final ticket status | [ ] | [ ] |

**Hold point:** A refund is not proof that a ticket is invalid, and a voided ticket is not proof that money was returned. Verify both in the systems that own those states. Do not promise that cancelling restores inventory, a seat or an earlier ticket state.

## 3. Close the case

- [ ] Reopened the order and compared **every** ticket with the before-state table.
- [ ] Confirmed the target ticket's final admission state.
- [ ] Confirmed all other tickets retain their intended admission state.
- [ ] Recorded any discrepancy, owner and next review: [ ].
- [ ] Recorded the approved payment outcome separately: [ ].
- [ ] Recorded the actual buyer-notice result: [ ].
- [ ] Updated the authorized check-in handoff: [ ].

Provider examples, **not universal behavior**: [Eventbrite](https://support.eventbrite.com/hc/en-us/articles/34864873103890-Cancel-or-delete-a-free-order) distinguishes ticket- from order-level actions for free orders and documents different notifications for cancel versus delete. [Ticket Tailor](https://help.tickettailor.com/en/articles/6179125-how-to-refund-one-ticket-in-an-order) separates refund from the optional void action; [its void guide](https://help.tickettailor.com/en/articles/2116551-how-to-void-individual-tickets-in-an-order) says voiding alone has no payment effect. [Eventcube](https://help.eventcube.io/en/articles/6648808-how-to-revoke-an-individual-ticket-from-a-single-or-multi-ticket-order-on-eventcube) documents per-ticket revocation with exclusions. [Peatix](https://help-organizer.peatix.com/en/support/solutions/articles/44001821755) says partial cancellation can depend on payment method. Check the current help for the provider and payment path actually used.