Platform
Chart changes never strand a sold seat.
When a chart edit would affect sold inventory, the server stops and hands you the impact, then you decide each seat's fate: refund, reassign, request a re-select, or honor it.
Sound familiar?
Renovations happen mid-season
A row comes out for a camera platform and 40 sold tickets point at nothing. Ignoring it doesn't make it go away. Resolving it does.
Silent invalidation
The worst version: the chart changes, nobody notices, and buyers discover it at the gate. Here the server refuses until someone decides.
Angry-fan triage by hand
Calling buyers one by one to reseat them is days of work. Per-seat fates with bulk policies turn it into one sitting.
A guard rail where it matters most
01Server-guarded changesA destructive chart edit returns a structured conflict. The change doesn't land until the impact is resolved.
02The full impact listEvery affected sold seat with its order, buyer, gross, and status, the whole blast radius on one panel.
03Four honest fatesRefund, reassign to a target seat, ask the buyer to re-select, or honor the seat unchanged.
04Bulk default policiesSet one default fate for the list, then hand-tune the exceptions.
05Buyer-notifying outcomesRefunds flow through the ledger; re-select requests reach the buyer. Nothing is a silent data fix.
06Audited like everything elseResolutions are workspace writes. They land in the same append-only audit trail.
When the chart must change
- 01Attempt the changeThe server checks it against sold inventory before anything lands.
- 02Read the impactA structured list: which seats, which orders, which buyers, how much money.
- 03Choose the fatesBulk policy first, per-seat exceptions after: refund, reassign, re-select, honor.
- 04Resolve & move onThe chart change lands with every buyer accounted for.
See the resolution flow
The safest chart change in ticketing, in the demo.