Sale day

Everything in TicketSquad points at one morning. This page covers the machinery that runs it for named-ticket events - the transferable flow has its own, simpler sale-day story (the live board with its demand tally).

Readiness: the run-up

The event page carries a readiness banner that tells the truth about the last ten percent, in one of four states. Getting set up - people are still joining, filling in required details, or waiting for a group. Ready - every active member's required data is in and everyone has a group. At risk - the sale is inside 48 hours and something still needs fixing, visible early enough to sort calmly, not at midnight. And once any group reports, the banner becomes a post-sale summary. (Members who've opted out of this sale don't count against readiness, and a group being under its size cap is advice on the preview, not a readiness fail.)

The static sale-day board

Before a named-ticket rush starts, TicketSquad generates each buying group a static board: one self-contained page with everything the group's buyer needs at checkout - details, copy buttons, the lot. Static is the point. The file works offline, can be saved or printed, and keeps working if the app, the database, or half the internet is struggling under sale-day load. Boards regenerate automatically as the sale approaches (a day out, then an hour out), and coordinators can preview and regenerate at any time - each group's link stays the same across regenerations, so nobody's saved link goes stale. Two hours before the sale, every active member with a verified email gets that link by email, with the board itself attached as a file that opens without any internet at all.

Two flavours, with a privacy rule between them:

• Per-group boards - every group gets one, in every privacy mode. It's the group's own buying tool.
• All-groups board - one page with every group's data, for Open events only. Closed events never generate one, and it's also held back while any privacy-loosening confirmations are pending.

Anyone with a sale date still marked TBC gets previews, but the real machinery arms only once a sale date is set.

Practice: the dry run

For big sales, a community can rehearse the real thing: a simulated queue and mock checkout that checks the registration number and postcode members actually entered - finding the typo a week early instead of live in the queue. It's a supervised exercise: the TicketSquad team sets a run up with the community (it's not a self-serve coordinator control), members just show up to a practice link with their sale-day board open in another tab. Feedback is deliberately terse - right or wrong per slot, and a name only on a fully-correct entry - and the whole run stays inside the community practising with its own boards.

Outcomes: reporting how it went

Each group reports once - success or failure - from sale day onward. Reporting a success asks who's actually covered (real sales are messy; partial success is normal) and anyone left out stays visible for what comes next. A reporter can undo within five minutes if it was a misclick - until a purchase confirmation lands on the outcome, which locks it. After the five minutes (or a lock), reversing is a coordinator action.

Once your group is covered, you're not done unless you want to be: a buyer who reaches the front again can buy for a group still waiting and report it - the relay that makes the whole model work. In Closed events that hand-off is governed by the multiple-group fallback.

After the sale: the unfulfilled pool

Members marked unfulfilled by a reported failure or partial success - still active in the event, with a working email - form the unfulfilled pool. For resale rounds, the coordinator can form fresh buying groups from exactly those people - and separately prompt them to re-check their details before the resale, so the data's fresh when the second chance comes.