Skip to content
TixFin

Lotteries

When demand beats supply, draw fairly

Configure lottery groups and rules, run and re-run the draw with full history, and let a FIFO waitlist pick up every place that frees up afterwards.

In short

How does the ticket lottery work?

For events where demand exceeds capacity, TixFin can allocate tickets by lottery instead of first-come-first-served. Lotteries are configured per event with groups and rules, executed manually or on a schedule, re-run as versioned draws and reviewed through run histories. Applicants enter publicly with verification and status mechanics, winners and non-winners are notified automatically, and a public status page lets any applicant check where their application stands and what the last draw produced.

  • Lottery groups and rules per event

  • Versioned runs with a full history

  • Public application and status page

How it works

Running a lottery

  1. 01

    Define groups and rules

    Set up the lottery for the event, including the groups and the rules that govern who is drawn against what.

  2. 02

    Collect applications

    Applicants apply publicly and verify themselves; status is visible to them throughout.

  3. 03

    Run the draw

    Execute the lottery, review the result and re-run as a new version if the configuration needs a correction.

  4. 04

    Release the remainder

    Notify winners and non-winners, then let the waitlist hand out every place that opens up afterwards.

Capabilities

Allocation you can defend

  • 01

    Lottery configuration

    Build the draw with groups and rule definitions per event, so different audiences or ticket categories can be allocated on their own terms.

  • 02

    Controlled execution

    Lotteries are run manually or on a schedule, can be re-run as a new version, and every run stays in the history.

  • 03

    Public applications

    Applicants sign up through a public flow with verification and status mechanics, without needing a full account first.

  • 04

    Automatic notifications

    Winner and non-winner messages go out automatically, so nobody is left guessing after the draw.

  • 05

    Applicant status page

    A public page shows the state of an application and the result of the most recent draw.

  • 06

    FIFO waitlists

    Sold-out ticket types run a waitlist with double opt-in; cancellations, refunds, expired reservations and capacity increases trigger the next allocation automatically.

Lotteries

Nothing goes to waste after the draw

Waitlist offers carry a configurable purchase window, for example fifteen minutes. A minute-by-minute scheduler expires stale offers, resets the entry and starts the next allocation, while every join, confirmation, offer, purchase and removal is written to an immutable event log.

Specifications

Key facts

Lottery scope
Configured per event, with groups and rule definitions
Run model
Manual or scheduled execution, versioned re-runs, full run history
Applicant access
Public application with verification and a public status page
Waitlist model
FIFO with double opt-in confirmation
Offer expiry
Configurable purchase window with a minute-based expiry scheduler

Use cases

Built for

FAQ

Lottery questions

Ask the team
  • Yes. Lotteries can be executed manually and re-run as a new version, and every run is kept in the run history so the sequence of draws remains traceable.
  • Winner and non-winner notifications are sent automatically, and a public status page lets an applicant check their application state and the outcome of the most recent draw.
  • A FIFO waitlist with double opt-in picks them up. Cancellations, refunds, expired reservations and manual capacity increases all trigger the next allocation automatically.
  • The purchase window is configurable, for example fifteen minutes. A scheduler running every minute expires unused offers, resets the entry and passes the place to the next person in line.

Allocate high-demand tickets fairly

Set up a lottery for your next on-sale and keep a waitlist running underneath it.