Overselling & Capacity

An event oversells when more tickets are sold for a date than that date has capacity for. This page covers how Voxel Events prevents that, the one setting that matters most, and what happens on the rare occasions it still occurs.

Capacity is per date and ticket type

Capacity is not a single number for the event. It is tracked separately for each combination of date (time slot) + ticket type, so a Friday General Admission selling out has no effect on Friday VIP or on Saturday. Everything on this page applies at that level.

How capacity is enforced

There are three checkpoints between a customer choosing tickets and the tickets being issued.

Checkpoint	What happens
Adding to cart	Remaining capacity is checked. If there aren't enough left, the item is refused.
While in the cart	If Reservation Duration is set, the seats are held for that customer and counted as unavailable to everyone else.
Order completion	Capacity is checked once more before inventory is reduced and ticket codes are issued.

Since 1.1.3, the checks that commit inventory run inside a database lock keyed on the event, date and ticket type. That is what stops two customers who click at the same instant from both being sold the last seat — without it, both could read "1 remaining" before either had written a sale.

Which checkpoints are locked depends on the reservation setting:

• Order completion is always locked, on every site.
• Adding to cart takes the lock as part of writing the hold, so it is locked only when Reservation Duration is set. With reservations disabled, the add-to-cart check is a read with nothing holding the result afterwards.

A capacity of 0 means unlimited, so those events can never oversell. A ticket type marked sold out for a date is unavailable regardless of capacity.

The setting that matters most

Event Tickets → Settings → Cart Reservation → Reservation Duration decides whether a seat is held between adding to the cart and completing payment.

With Reservation Duration disabled, nothing holds a seat during checkout

Disabled is the default. With it disabled, the last capacity check before completion happens when the item goes into the cart. Two customers can therefore both add the last seat, both proceed to the payment page, and both pay — no simultaneous clicking required, just two people checking out at the same time.

If you sell events with limited capacity, set this to 15 minutes.

Setting a duration does not remove the completion-time check; it narrows the window in which a conflict can arise from minutes to milliseconds. Held seats are released when the hold expires, when the customer removes the item from their cart, or when the order completes.

See Settings → Cart Reservation for the available durations.

When an event does oversell

If the completion-time check finds that a paid order takes a date past its capacity, the tickets are still issued. The customer has already paid, and refusing to deliver a ticket that has been paid for is the worse outcome.

What happens instead:

1. The order is fulfilled normally — ticket codes are generated and the confirmation email is sent.
2. The oversell is recorded, with the date, ticket type, quantity ordered and how many were beyond capacity.
3. The event author and site admin are notified, so somebody knows before the guests arrive.

This is a record to act on, not a queue to process

There is nothing to approve or reject. The sale has gone through. The record exists so you can decide whether to add capacity, move the customer to another date, or contact them — and so an oversell can never again pass unnoticed.

The Oversold screen

Event Tickets → Oversold lists every order that completed beyond capacity.

Column	Contents
Event	The event, linking to its editor
Tickets Affected	Each date and ticket type that went over, with quantity ordered and how many were over
Over By	Total tickets beyond capacity for that order
Customer	Name and email captured at checkout
Order	Link through to the originating order
When	When the order completed

Site administrators see every event on the site. Event authors see only conflicts on events they own, which makes the screen safe to leave available on a multi-venue site.

Filter by event when more than one has oversold, and the summary line above the table gives the running totals for whatever is currently filtered.

The notification

Overselling raises a Tickets Oversold app event, which notifies the event author and the site admin in-app and by email.

• Whether it is sent at all — Event Tickets → Settings → Capacity Conflicts
• Who receives it, on which channel, and the wording — Voxel → App Events → Tickets Oversold, alongside every other Voxel notification

Turning the notification off leaves the record on the Oversold screen; it only stops the message being sent.

For developers

The voxel_events_tickets_oversold action fires on the same event, after the record is written:

add_action( 'voxel_events_tickets_oversold', function( $oversold, $item, $order ) {
    // $oversold: rows of slot_id, ticket_type_id, ticket_type_name,
    //            slot_label, quantity, shortfall
}, 10, 3 );

Use it to push the conflict into your own systems. The rows carry the resolved ticket type name and date label as of 1.2.0, not only internal IDs.

Coming in a later release

A hold and flag option is in development, for venues that would rather a conflicted order waited for a human decision than be fulfilled automatically. Under it, an order that arrives paid for a seat that is no longer there will be held in a capacity-conflict state — no ticket codes, no confirmation email — with the organiser able to accept the booking anyway or reject and refund it.

That will be a setting, not a change in behaviour: the current fulfil-and-notify handling described above stays the default.